In going through the yt4-merge pull request, Kacper and I tracked down
some issues related to the changeover in unyt from using reference
values in CGS to using reference values in MKS. Rather than attempt
to reconcile these two things (ok actually we *tried* but it turns out
it's super duper hard, thanks a LOT floating point math) it seems that
the simpler thing to do is to make most of the values compared in the
base unit system of "code" rather than CGS.
I have issued this pull request:
to change over the default for the answer value tests to use
unit_system="code" if the ds is supplied as a string (rather than an
Now, if we are concerned that we do not have adequate test coverage
for verifying that the units are in CGS, or if we have concerns about
this glossing over some CGS conversion factor issues, we should
perhaps supplement these tests.
This PR will be ready once all of the test storage IDs have been
updated, and once I've migrated most/all of the datasets to using
unit_system="code", but I wanted to open this up for possible
discussion here. It's entirely possible this is not an acceptable
solution, and I am hoping that folks may have some feedback. What am
I missing? :)
PS I genuinely think that this might un-clog a whole bunch of issues
in the yt4-merge, and we can focus on just verifying the results for
the SPH datasets. Hooray!
As a heads-up, the yt-4.0 => master merge is now passing the unit
tests on Travis:
(I had to push a quick update after a conflict showed up, so as of
this writing the new results aren't yet finished.)
Note that the travis minimal answer tests are not passing, which is
likely a result of the merge and matching values between branches of
the answer-store subrepo.
I'm not sure yet the best way to proceed with changing to using pytest
for answer tests, but I'm going to try to connect with Jared and see
if we can strategize something to propose here.
We're seeing a bit of churn in the answer-store directory. I'd like
to use git-lfs to manage this so that we can keep going without
bloating the repo *too* much. We're getting a bit of churn right now
and every time it adds a couple megs to the repo -- the latest one I'm
looking at adds 15 megs, and I'm reluctant to do that.
This would keep our repo size down but also not disrupt our
"answer-store" directory contents.
Any objections to trying this out?
Madicken did an *amazing* job with the release (which, I know, hasn't
been big-time announced yet!) this last week.
One of the bigger pain points seems to be the release notes. I'd like
to propose that we enable two specific Github Actions to make this
The first one would be for marking things as bug, docs, tests, new
feature, etc, before merging. The second one would be to add labels
for PRs based on which files they touch. I'd like to propose that we
do this so that we can use a tool like:
to build out a changelog semi-automatically.
The per-files labels would be just for the frontends -- so that we
could have a label for each frontend, and then in the release notes,
collect changes based on which frontend they applied to. This way,
we'd have sections for bugs, major features, and then also a
separation based on specific frontends, to make it easier to see what
I've issued a PR that sets up the config for the first action -- the
second one would need some modification to our current labels.
Neither action has been "enabled" yet.
Hello yt friends!
On behalf of everyone who contributed, the yt community is delighted to
announced that yt 3.6.0 has been released! Version 3.6.0 is our next
release after 3.5.1 which was in February 2019. We anticipate that this
will be the final major release in the 3.x series, and that the next major
release will be 4.0. Additionally, yt 3.6.0 does not support Python 2,
although we have not removed the compatibility layers (such as six).
It includes changes from 184 pull requests, contributed by 39 unique
contributors, 22 of which committed their first time to the project.
We’ve also updated our project governance and contribution guidelines, see
here: https://yt-project.github.io/governance/ ; the yt homepage itself is
at https://yt-project.org/ and the GitHub project page is at
For full release notes, see
Binaries for yt 3.6.0 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 workspace.
Since the last release, support for these *new data formats has been added*:
* AMRVAC – thanks to Clement Robert and Niels Claes for their hard work
supporting this and many associated changes in yt!
*New features and major changes:*
* Angular momentum vector directions have been reversed, which is a
breaking change with past versions.
* CartoPy is now supported as a source of projections and transformations
for appropriate geometries, and plotting geographic and georegistered data
is much simpler and streamlined!
* Cut regions can now be made using the operators beginning with exclude_
and include_, to simplify their creation.
* Field definitions and small arrays are now IPywidget-ized!
* Curvilinear coordinates have many additional plot annotations supported
* Fields can be added to compute “nearest value” with particles.
* Ghost zone generation has had some hotspots optimized for improved
* Regularized grids (covering, arbitrary and smoothed) can be exported to
* Data objects can be exported to AstroPy QTables and pandas dataframes
* The colormap turbo, a CVD-friendly version of jet, is now available
* Wheels, conda packages and the like are available at all the usual places.
Please be advised that PR 2043 introduced a breaking change where the
angular momentum has been reversed. This may modify your results, so please
note these changes if you use angular momentum in your work.
Thanks again to everyone who has contributed to this release! We are
incredible grateful for this community and the contributions supplied by
Please forward this announcement on to any interested parties.
The yt development team