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 …
[View More]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
[View Less]
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[…
[View More]'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
[View Less]
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
…
[View More]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
[View Less]