Hi all,
I'd like to publicly announce that I will be leaving my current position at
NCSA at the beginning of May and starting a 12-week batch at the recurse
center in NYC this summer. If you're curious about the recurse center, take
a look at their website for details (https://recurse.com). While I will
still be around and able to participate in the community at a lower level,
I will need to step down from my current role as primary maintainer of yt
when I leave NCSA so I can focus on new projects and opportunities.
Matt has volunteered to take up some of the slack on code review but I'm
hoping that everyone else can also chip in. We also have two postdocs here
at NCSA (Madicken Munk and Jared Coughlin) who have both expressed interest
in stepping up their contributions to yt and helping out with day-to-day
support and maintenance. I also hope we can have a conversation about
updating yt's governance documents and adding rotating members to the
steering committee at the development workshop next week.
I would like to continue maintaining unyt as part of the yt project going
forward as I expect that will take substantially less time than maintaining
yt as a whole. If people are nervous about yt depending on unyt when I'm
not employed to work on yt development that is fair and I'm happy to talk
about the relationship between unyt and yt in light of all of this.
My plan for the next few weeks is to help get yt-4.0 in a state where we
can do a release. That means merging the yt-4.0 branch into master, helping
out with testing and documentation, and triaging and fixing remaining
issues. I don't know if we'll be able to do a yt 4.0 final release by May
but hopefully we'll at least have a much more solid base to work from.
I'm going to try my best to make this transition as smooth as possible. If
you're aware of places where I could take action now to lead off headaches
down the road it would be great to get reminders about those places.
It's been an amazing experience to have so much of my professional life and
achievements influenced by yt and the yt community over the past 8 years or
so. I'm looking forward to seeing all the cool new things you all will
build in the next few years.
With a heavy heart,
Nathan
The yt community is proud to announce the release of yt 3.5.1. This is a
patch release and includes a number of minor improvements and bugfixes.
yt (https://yt-project.org) is an open source, community developed toolkit
for the analysis and visualization of volumetric data. Development is
hosted on GitHub (https://github.com/yt-project/yt).
See the changelog below for a summary of new features, changes, and
bugfixes.
For more information, including installation instructions, links to
community resources, and information on contributing to yt’s development,
please see the yt homepage at http://yt-project.org and the documentation
for yt 3.5.1 at http://yt-project.org/docs/3.5.1
<http://yt-project.org/docs/3.4.1>.
Binaries for yt 3.5.1 are available via pip and conda. If you installed via
the install script or use conda to manage your python installation, you can
update yt via:
$ conda update -c conda-forge yt
And via pip if you manage your python installation with pip:
$ pip install -U yt
As always, if you have any questions, concerns, or run into any trouble
updating please don’t hesitate to send a message to the mailing list or
stop by our Slack or IRC channel.
yt is the product of a large community of developers and users and we are
extraordinarily grateful for and proud of their contributions. Please
forward this announcement on to any interested parties.
Best,
The yt development team
*Changelog*
- Avoid use of deprecated field names internally, silencing some
user-visible deprecation warnings. See PR 2073
<https://github.com/yt-project/yt/pull/2073>.
- Fix crash using clump.save_as_dataset when field_data is not defined.
See PR 2079 <https://github.com/yt-project/yt/pull/2079/>. Thank you to
Adam McMaster (@adammcmaster) for the fix.
- Fix for ramses RT and group reading under Python3. See PR 2092
<https://github.com/yt-project/yt/pull/2092>.
- The line integral convolution annotation no longer erroneously
includes noise in regions where the vector field under consideration has a
value of zero. See PR 2094 <https://github.com/yt-project/yt/pull/2094>.
- Explicit set language_level to 2 in yt's cython code to avoid breakage
with a future Cython release that changes the default language_level. See PR
2100 <https://github.com/yt-project/yt/pull/2100>.
- Add support for matplotlib 3.0, fixes issue where colorbar values were
sometimes incorrect. See PR 2101
<https://github.com/yt-project/yt/pull/2101>.
- Fix incorrect weighting function used in definition of
mozotta_weighting field. See PR 2102
<https://github.com/yt-project/yt/pull/2102>.
- Fix an issue that caused reading a particle field from a cut_region to
produce a crash. See PR 2106 <https://github.com/yt-project/yt/pull/2106>
.
- Fix unit issues leading to incorrect angular momentum calculations.
See PR 2114 <https://github.com/yt-project/yt/pull/2114>.
- Fix incorrect behavior when creating a covering_grid or arbitrary_grid
with a left_edge or right_edge that has specified units. See PR 2119
<https://github.com/yt-project/yt/pull/2119>.
- Avoid reading big-endian Gadget binary data. See PR 2120
<https://github.com/yt-project/yt/pull/2120>.
- Convert radius to appropriate unit in the sphere plot callback. See PR
2128 <https://github.com/yt-project/yt/pull/2128>.
- Fix issues doing CIC deposition on a chunk containing only one oct.
See PR 2130 <https://github.com/yt-project/yt/pull/2130>.
- Fix FutureWarning generated by NumPy 1.16. See PR 2133
<https://github.com/yt-project/yt/pull/2133>.
- Fix issues reading ARTIO multiresolution N-body particles. See PR 2140
<https://github.com/yt-project/yt/pull/2140>. Thank you to Gillen Brown
(@gillenbrown) for the fix.
- Fix crashes when a plugins file has a function that uses global
variables defined in the file. See PR 2144
<https://github.com/yt-project/yt/pull/2144>.
- Fix several bugs in the Enzo-p frontend. See PR 2150
<https://github.com/yt-project/yt/pull/2150>.
- Fix issues reading ramses data on Windows. See PR 2152
<https://github.com/yt-project/yt/pull/2152>.
Hi all,
I'd like to cut yt 3.5.1 next week. I've issued a PR with some backports
here:
https://github.com/yt-project/yt/pull/2153
If anyone has anything they'd like to see get included or any objections to
cutting a release please let me know here.
-Nathan
Hi everyone,
Something that's come up for me a lot lately is hearing from people who
have datasets that are mostly recognized by yt, but have a few extra fields
that aren't normally present. I think that in some cases, these can be read
in, but are returned as dimensionless. Even then, this produces a number of
cumbersome side-effects for using them in analysis that I won't bother to
get into unless someone is interested.
Unless I'm mistaken, the only current solution to this is to modify the
known_other_fields and known_particle_fields tuples in that frontend's
fields.py file. I think there are a lot of benefits to creating a means for
users to "declare" additional on-disk fields for a dataset.
Here are some of the big ones, for me at least:
1. There are certain simulation codes with a large number of slight
variations. Keeping up with them all is probably unfeasible, especially
when some of these will have relatively short life spans.
2. The current solution requires either someone to maintain a separate fork
(or uncommitted changes!) or intervention by experienced developers plus
the delay time associated with propagating changes upstream.
3. Perhaps such a system could make it easier for long-lasting variants to
ultimately become officially supported by providing the user a simpler way
to debug issues relating to new fields (like units, proper aliases, etc.).
In fairness, some potential cons:
1. This gives people an excuse to not add official support for new variants
and results in a separate ecosystem of frontends only supported through
this method.
2. It could be quite difficult to do for some datasets.
As for how to do this, my impression is that something needs to be provided
at load time before the field_list is assembled, something like handing
yt.load some sort of FieldDeclaration object or a series of dicts/tuples to
pass into the FieldInfoContainer.
Anyway, I think this could be very helpful to a lot of people, but I'm very
interested to hear any thoughts on whether this is a good idea and how we
might do it.
Thanks!
Britton
