A while back, I brought up an ongoing effort to extract most of the yt
analysis_modules into an external package called yt_astro_analysis. Here
is an update on this.
The yt_astro_analysis repo is at
The documentation has been updated for all modules and includes a new front
page, installation guide, and API reference. This is hosted at
Automated testing is now enabled using Travis for most of the
configurations being tested with yt's travis tests. In the process of
setting this up, I noted that some of the functionality (namely, Rockstar
and running halo finders in parallel) does not work on Python 3. However,
this appears to be the same situation as with the versions in yt, so this
is not a regression as far as I can tell.
The final things will be:
1. upload to pypi
2. perhaps update the yt install script to optionally install this
3. add deprecation warnings to the original modules in yt
4. announce a release
So, is there anything else that I missed? Are there addition things that
need to happen before we can begin the final things? I would also like to
invite anyone interested in this to take a look at the repo, the docs,
testing, etc and offer any comments or suggestions. What does everyone
Dear yt developers,
As part of an NSF software award, we are planning to perform a study on
Software Engineering Practices for Computational Science and Engineering
(CSE) software development. The discipline of software engineering focuses
on developing techniques and tools to assist developers in efficiently
building high-quality and trustworthy software. Code review is one of the
important techniques of software engineering defined as a systematic
examination of computer source code which intends to find and remove
vulnerabilities in the initial development phase and improve software
quality. Our plan is to understand the practices, impacts and barriers of
code review technique in CSE software development. For this study, we are
considering the Einstein Toolkit, yt-project and Brown Dog projects as use
You are invited to participate in this research project because you are a
developer of the yt project. Your participation in this research study is
voluntary. You may choose not to participate. If you decide to participate
in this research survey, you may withdraw at any time. If you decide not to
participate in this study or if you withdraw from participating at any
time, you will not be penalized.
The procedure involves filling an online survey that will take
approximately 20 minutes. Your responses will be kept confidential, and we
do not collect identifying information such as your name, email address, or
IP address. The survey questions will be about how you review code, how
your code is being reviewed, what are the impacts and expectations, if
there are any challenges or barriers, and potential areas of improvement.
We will do our best to keep your information confidential. All data is
stored in an electronic format. To help protect your confidentiality, the
survey will not contain information that will personally identify you. The
results of this study will be used for scholarly purposes only, and may be
shared with related project personnel.
If you have any questions about the research study, please contact
Gabrielle Allen (gdallen(a)illinois.edu), Roland Haas (rhaas(a)illinois.edu),
Nasir Eisty (neisty(a)crimson.ua.edu), Jeffrey Carver (carver(a)cs.ua.edu),
Daniel S. Katz (dskatz(a)illinois.edu).
This research has been reviewed according to University of Illinois at
Urbana-Champaign IRB procedures for research involving human subjects. If
you have any questions about your rights as a participant in this study or
any concerns or complaints, please contact the University of Illinois
Office for the Protection of Research Subjects at 217-333-2670
<(217)%20333-2670> or via email at irb(a)illinois.edu.
*Please click on the Survey Link
begin the survey. Please complete the survey by the end of Sunday, August
Thank you very much!
- - - - - - - - - - - - - - - - - - - - - - - - -
Nasir Uddin Eisty
*Department of Computer Science*
*University of Alabama*
*Tuscaloosa, Alabama, USA*
We (Nathan, Meagan, Kacper and I) wanted to share some good news.
We've recently received a grant from the NSF SI2 program; NCSA put out
a press release here:
(This includes a link to the full proposal, which goes into some detail.)
This is a five year grant, supporting part or all of a couple postdocs
(UIUC, Columbia, Wisconsin), a research scientist, some PI time and a
graduate student (along with some workshops). It has a couple areas
of development that we'll be working on. The strictly technical ones
will be related to improving non-spatial indexing, enabling "path"
queries in a more full way (think advanced streamlines) and an
all-new, symbolic field system. In a sense, these are things we're
already kind of familiar with how to work on -- YTEPs, code reivew,
documentation, testing, etc.
The part that's going to be harder -- from the social perspective --
is that we're going to be working harder to make yt an attractive
analysis and visualization system outside of astronomy, without losing
its attractiveness *within* astronomy.
This cross-domain effort ties into things like Britton's recent work
on splitting out yt_astro_analysis, and the idea of compartmentalizing
things a bit more within the frontends and whatnot.
We've identified an advisory board with folks from geophysics,
weather, oceanography, nuclear engineering, plasma physics and
observational astro, and we're going to spin up a couple new mailing
lists for this purpose:
* yt-advisory: advisory board discussions
* yt-ssi: administrative info for the grant (possibly boring?)
I'm working to get our lists moved to the yt-project.org domain before
doing this, though. All of these will be open, although I suspect not
of broad interest (and thus why we're creating new ones.) It might
turn out that domain-specific discussion ends up overwhelming
discussion on yt-dev or yt-users, in which case we can split it out,
but for now yt-dev seems like the right place to put that.
Anyhow, the main takeaway I want to give from this is: I'm pretty
excited, and I am really, really looking forward to the work we're
going to do with this. We could not have gotten this far without the
amazing community that has grown up around yt. We're going to work on
this project in an open, collaborative way in keeping with the spirit
of what we've done with yt already.
In the proposal itself, we detail the ways in which we will follow the
standard yt community norms (for design, review, upstream, etc) and
before it was submitted, we discussed it with the yt steering
committee to make sure that the language we included did not sideline
or "squeeze out" anyone in the community. Ensuring that this
*supports*, rather than *detracts from*, the community is absolutely
essential to its success, and we will not be doing anything to
jeopardize that success: this means more effort on yt, but it does not
mean that yt will suddenly become a "professionalized" project that
loses sight of how it got here. And, we would welcome feedback --
especially if it seems that we're missing the mark.
We're still figuring out how to most effectively do project management
for it, but it's going to all be above board, and we'd absolutely
*love* to collaborate with interested folks on it.
-Matt & Nathan
tl;dr: I'd like to cut a yt 3.4 release next week and want to know if
anyone has an issue with that.
I was a bit optimistic about what would get done at SciPy and unfortunately
we were not able to fix all the open issues for 3.4 that week. Since then
I've been trying to get the remaining issues squared away so we can cut yt
3.4 ASAP. You can see the issues on the 3.4 milestone here:
Currently all of the open issues have open pull requests to address them
except for #1268. The pull request for #941 has been open a long time and
still needs some work, which I am planning to do this weekend or early next
week. I expect the pull requests for the other issues to be merged within
the next week.
For #1268, I think I'd like to punt on it, since it requires specialized
knowledge about the inline yt interface in Enzo and no one has stepped up
to work on it. I don't think it makes sense to delay the release on getting
that issue fixed.
If all that happens, that will leave us with zero open issues against the
3.4 milestone sometime next week. There are a bunch of new features that
haven't been in a stable release yet along with a number of big fixes that
have come in since yt 3.3.5 and I think we owe it to our contributors to
not delay the release any longer than we absolutely need to.
I'd like to know if anyone has an issue with getting a 3.4 release out as
soon as all of the issues currently marked for 3.4 are merged.
I'll volunteer to be the release manager in case there are issues with our
release process now that we're on github and will update our release
documentation accordingly. If anyone would like to help out that would be
very much appreciated, particularly with writing the release notes.
That's about it, let me know what you think,