Mailman 3 April 2018 - yt-dev

Google Summer of Code students
by Nathan Goldbaum April 23, 2018

April 23, 2018

Hi all, I'm proud to publicly announce that we will have two Google Summer of Code students working on yt development this summer. Ashley Kelly will be working on the "demeshening" project by adding the ability to smooth SPH data onto various kinds of meshes as well as improving the documentation for working with SPH data in the demeshening. https://summerofcode.withgoogle.com/projects/#5101882905722880 Abhishek Singh will be working on improving the yt test suite, with a focus on improving test coverage and the runtime performance of the test suite. https://summerofcode.withgoogle.com/projects/#5325639024902144 With the public announcement of the projects for this year, we are beginning the community bonding period. This is a time for Ashley and Abhishek to check in with the community and start to dive into the codebase. While their official mentors are available to answer their questions one on one, other community members are welcome to jump in and help out in the spirit of the community code of conduct if mentors are unavailable for some reason. If anyone has any questions or concerns about our participating in Google Summer of Code, please let us know by replying here or by contacting me off-list. -Nathan Goldbaum

1 0

Proposal: make ambiguous field accesses raise errors in yt 4.0
by Nathan Goldbaum April 16, 2018

April 16, 2018

Hi all, I'm probably going to expand this into a full YTEP but I wanted to bring this up informally to see if there are any objections to the general idea. One of the big changes in yt 3.0 was that fields names went from bring strings to bring two-element tuples of strings. However, in an attempt to maintain compatibility with scripts written for yt 2.x, Matt added the ability for yt to "guess" a field tuple from a string field name. That's how when you do dd['density'] it gets resolved to dd['gas', 'density']. This is nice both for backward compatibility and also for the sake of ease of use. This is fine until the guessing becomes ambiguous. At that point, the possibility exists for yt to guess wrong. The field guessing machinery also has some hysteresis, so it's possible that sometimes yt will guess correctly based on prior inputs to the field machinery and other times guess incorrectly. On python 3.4 and 3.5 even the same script can sometimes give different results because dictionary iteration order is randomized. I don't think it's possible to improve the field detection such that yt can always guess "correctly" because the correct answer depends on user intent, which we don't really have a hope of analyzing and figuring out. Instead, I'd like to propose a backward incompatible change for yt 4.0: *make field accesses with a string field name that resolve to more than one fields raise an error with a list of the fields that possibly match*. Ultimately, we may want to consider deprecating string field names entirely. In my opinion it would be beneficial if we can get people to use the ds.fields object more. If you're unfamiliar with that, it's currently possible to do: data = dd[ds.fields.gas.density] Here `ds.fields.gas.density` is basically syntax sugar for `ds.field_info['gas, 'density']`. The nice thing about this construction is it forces people to specify the field type. It also allows people to tab complete field names in IPython. What do you all think? If there aren't strong objections I'm going to expand this into a YTEP, ultimately implementing it for yt 4.0. -Nathan

2 3

Face blind code reviews
by Nathan Goldbaum April 12, 2018

April 12, 2018

Hi all, I'm going to be trying an experiment with face blind code reviews using a new extension for Firefox from Mozilla: https://blog.mozilla.org/blog/2018/03/08/gender-bias-code-reviews/ https://addons.mozilla.org/en-US/firefox/addon/blind-reviews/ If my code reviews seem odd or impersonal it's because I can't see who you are. -Nathan

2 1

YT-1300: The Future of yt
by Matthew Turk April 1, 2018

April 1, 2018

Hi everyone, As some of you know, we have discussed and examined numerous methods for sustainability and continued development of yt. The yt team is proud to announce that we have secured consistent future funding through a mutually beneficial partnership with a large, corporate conglomerate. We are proud to announce that today, April 1, 2018, we are announcing the forthcoming release of a special edition of yt, entitled YT-1300, in collaboration with Disney’s LucasFilm. This edition will be released on May 25, 2018. Among the special features that will be included: * All units of parsec (Mpc, kpc, pc) will have their dimensions changed from “(length)” to “(time)”. * At any point during the execution of a script, you can change the underlying process that is doing the execution. Would you rather run in Fortran instead of Python? This can now be done mid-analysis. * All visualizations generated through yt will be watermarked with the “Disney” logo * Sonification routines will be THX certified * All point-masses below an Earth mass will henceforth be identified as “notamoon” * Full support for relativistic coordinate systems will be implemented, enabling disputes over “who did what first” to be definitively resolved * ds.slice has been replaced with ds.laser_sword While we are very excited about this, and what these types of deals may hold for yt in the future, we expect this to be the only release in this series. It will likely remain a solo opportunity at this time. For more information, please consult YTEP-1138 where this is defined in greater detail. Best, yt

1 0