yt-dev February 2019

yt-dev@python.org

3 participants
4 discussions

Personal news and future plans
by Nathan Goldbaum 03 Mar '19

03 Mar '19

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

4 3

ANN: yt 3.5.1 released
by Nathan Goldbaum 26 Feb '19

26 Feb '19

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>.

1 0

yt 3.5.1
by Nathan Goldbaum 22 Feb '19

22 Feb '19

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

1 0

seeking input: supporting unrecognized fields on disk
by Britton Smith 01 Feb '19

01 Feb '19

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

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev February 2019