Dear yt-users and yt-dev,
My apologies for repeated in-list and cross-list posts!
I'd like to remind everybody that the 2020 John Hunter Excellence in
Plotting Contest submission deadline is on June 01 -- only a few days away. We
welcome and look forward to your submissions!
In memory of John Hunter, we are pleased to announce the John Hunter
Excellence in Plotting Contest for 2020. This open competition aims to
highlight the importance of data visualization to scientific progress and
showcase the capabilities of open source software.
Participants are invited to submit scientific plots to be judged by a
panel. The winning entries will be announced and displayed at SciPy 2020 or
announced in the John Hunter Excellence in Plotting Contest website and
John Hunter’s family are graciously sponsoring cash prizes for the winners
in the following amounts:
1st prize: $1000
2nd prize: $750
3rd prize: $500
Entries must be submitted by June 1st to the form at
Winners will be announced at Scipy 2020 or publicly on the John Hunter
Excellence in Plotting Contest website and youtube channel
Participants do not need to attend the Scipy conference.
Entries may take the definition of “visualization” rather broadly.
Entries may be, for example, a traditional printed plot, an interactive
visualization for the web, a dashboard, or an animation.
Source code for the plot must be provided, in the form of Python code
and/or a Jupyter notebook, along with a rendering of the plot in a widely
used format. The rendering may be, for example, PDF for print, standalone
original data can not be shared for reasons of size or licensing, "fake"
data may be substituted, along with an image of the plot using real data.
Each entry must include a 300-500 word abstract describing the plot and
its importance for a general scientific audience.
Entries will be judged on their clarity, innovation and aesthetics, but
most importantly for their effectiveness in communicating a real-world
problem. Entrants are encouraged to submit plots that were used during the
course of research or work, rather than merely being hypothetical.
SciPy and the John Hunter Excellence in Plotting Contest organizers
reserves the right to display any and all entries, whether prize-winning or
not, at the conference, use in any materials or on its website, with
attribution to the original author(s).
Past entries can be found at https://jhepc.github.io/
Questions regarding the contest can be sent to jhepc.organizers(a)gmail.com
John Hunter Excellence in Plotting Contest Co-Chairs
So I’ve been exploring the possibility of using Black and the likes to start enforcing styling standard throughout the code base.
Since this process involves changing a significant portion of it (several thousands of lines), it was suggested to me to make it into YTEP.
Here it is !
Hope you like it,
Hi everyone !
As per Madicken’s suggestion, I’d like to share with you this newly opened discussion on GitHub regarding the current state and future our CI setup:
I'm creating a new yt frontend for pluto xdmf static grids (finite volume mesh code). I have a grid.out file which has the values of the left and right cell faces in all directions. Can anyone suggest a way to set up the Hierarchy and Grid classes for this? I'm a bit stuck in this part. It would be really helpful.
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
Hi yt dev!
It has been some time since we last did a release of yt. `master` has a lot
of features that are not in any of our releases on pypi and conda forge.
We're also prepping for the yt-4.0 release soon. I propose that we try to
get yt 3.6 out the door soon so we can use our developer time on yt-4.0. We
should leave some time so that people can get issues resolved and minor
features added before we publish the release. Is April 08 a long enough
time out for everybody? If not, what would be better? That's just under two
weeks out, but the release would happen on a Wednesday so we have a couple
of days to put out fires if things go horribly wrong (and we're not working
over a weekend). What do you think? Is this too aggressive? Too slow?
I've added a label to the yt repo called `yt-3.6`. Please use this label
(or comment if you don't have access to the labels) in your open PRs or in
your PRs that you submit before we do the release if you want them to be
included in yt-3.6. For the next while we'll prioritize review of the 3.6
The CI platforms are still not reliably running on master. I'll do my best
to get them working ASAP so we know that the features we're adding aren't
introducing obvious breaking changes.
- I am proposing we release the yt 3.6 on April 08. Do you all agree on
- If you want to have a feature in yt 3.6 or resolve an issue before this
release, please label using the yt-3.6 label or comment in your PRs that
this is a yt 3.6 feature. We will give review priority to those PRs before