I am going to try to schedule a yt team meeting soon. For those who are
unfamiliar, we try to have live discussions online every quarter (or so) to
discuss the state of the project, major development efforts, etc. Most of
the steering committee will attend, but all are welcome.
My aim is to schedule the meeting for the week of October 26-30 when the
US/Europe time gap is an hour shorter than usual.
I will send out a doodle poll to anyone who is interested in attending. If
you'd like to come to the meeting, drop me a line by Monday and I'll make
sure to include you. No need to write me if you're already on the steering
In https://github.com/yt-project/yt/pull/2896 I issued a rewrite for the
interactive volume rendering. There's been some discussion, but basically
the path is diverging:
* Merge in, and review via yt methods
* Split into separate package (likely following a null merge, so that the
history is preserved *somewhere*) and removing the existing interactive
If folks have time, chiming in on it over there would be very helpful.
Congratulations to the team on merging yt-4.0 into the main dev branch of
the repo a couple months ago!
I noticed that the yt-4.0 branch is still hanging around the main yt repo.
Unless there is a good reason that it's sticking around, I propose we
delete it so as to not confuse users who might checkout that branch, when
it's no longer being updated since it was merged with the master branch.
I'm happy to do this, but I didn't want to take unilateral action if there
was a good reason others were keeping it on, and due to the way github
works, I don't think there is a way to PR a branch deletion. One just has
to do it from the web interface (or push a local change).
Is there any reason to keep the yt-4.0 branch around now that it's merged
with the master branch? If not, I'll delete it in the next few days.
California Institute of Technology
I was interested in trying yt as a visualization tool but when installing
on Ubuntu the errors mention:
import matplotlib._png as _png
ModuleNotFoundError: No module named 'matplotlib._png'
I attached the yt_install.log. Please advise
I’d like to get some feedback from you all on a new yt development issue I’ve run into.
So Arepo has passive tracer particles. The way these are handled is that in the snapshot file the tracer particle IDs are stored and the gas Voronoi cell IDs that they are matched to are stored. So if you want any quantity, including position, velocity, density, etc, of the tracer, you’d want to map them from the gas cell ID.
So we need a mapping from PartType0 to PartType3. This seems complicated for a couple of reasons:
1. Since we do things in chunks, how would we get chunks that have the particles of both types that you’d want in the same chunk? Or would this be two chunks at once?
2. Ideally you’d just want to be able to map every gas field to a tracer field, even derived gas fields like angular momentum and entropy, etc. This does not seem like a trivial thing.
Does anyone have any thoughts here? I think this is kind of a new type of issue for us.
Here's quick (but detailed !) update focused on recently proposed changed that affect the
way we interact with yt as developers.
1) Code style (mostly f-strings)
Corentin has been doing some excellent work to enable the use of f-strings throughout
the code base.
This is the most readable (and performant) way to format strings in Python since
version 3.6.0 and was originally defined here https://www.python.org/dev/peps/pep-0498/
flynt (https://github.com/ikamensh/flynt) is a tool that, as black or isort, changes the
code in-place to automate the transition
The reasons we didn’t push for this change in YTEP-0037 were the following:
a) f-strings are not recommended in logger entries
flynt doesn’t have a functionality to filter those. Corentin solved this by detecting and
manually updating all compromised calls to “mylog” (yt’s logger) to use the only
correct string formatting syntax for such calls.
This is the (merged) PR in question https://github.com/yt-project/yt/pull/2820
If you’re curious why this was necessary:
mylog.warning(“my string %s”, msg)
allows for lazy evaluations of strings, and won't compute the resulting string unless
the call is actually used (depending on the current logger’s level).
b) lack of a reliable tool for linting and automated code updates
- flynt didn’t have a dry-mode option until recently (thanks to Corentin’s upstream
- flynt also lacked a pre-commit hook definition that would work for us as isort,
black or flake8 for check (if you missed out on pre-commit hooks, they are
documented here https://yt-project.org/docs/dev/developing/developing.html#pre-commit-hooks)
I just solved this problem upstream (see https://github.com/ikamensh/flynt/pull/73)
2) Refactors (moving stuff around)
Matt has started an effort to relocate some of yt’s functionalities to more appropriate
places in the file tree, or use more sensible coding patterns enabled by most recent
version of Python (taking 3.6.0 as the earliest supported version)
In the same spirit, here are two of mines that propose moving the load_* functions
to a common namespace
On a related topic, I proposed we stop using the yt.units module, which is now
mostly a wrapper around unyt, and enforce importing directly from unyt wherever possible.
Here’s the issue for discussion, a PR where this is enforced can be found therein.
note that we have a new GitHub label for this kind of contributions: “refactor” !
Stay out of trouble and enjoy the summer
Navaneeth (CC'd) has been working on extracting the ewah_bool_utils code,
which was originally written by Meagan Lang (also CC'd) to wrap Daniel
Lemire's EWAH bitmap array code, into its own repo. The code itself is
pretty darn useful beyond yt applications, so I think this is a pretty
I'd like to transfer this to the yt-project organization, and have it be
hosted there. Does anyone object to that? Unless I hear otherwise, we'll
initiate the repo transfer in few days.
Right now, he's begun trying to make a version of yt that depends on it as
an external dependency, but that would be a subsequent discussion, as it's
tricky and we'd need to decide on versioning, etc.
Thanks, and happy Saturday,
I've issued a PR that adds a few chatops-style commands to our pull
There are links in there to the issue:
which itself has a few links. Please feel free to chime in there, but I
think this could make our development workflow a lot nicer -- we could stop
asking people to rebase, for instance, and instead just have it done
almost-automatically by a bot. And same for black, isort, etc. I'll also
add a help command, now that I'm thinking of it...
Please leave feedback -- if I get some buy-in from folks I'll transfer the
slash-command-processor repo to the yt-project org and then we can move
forward with it a bit.
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,
We will have a yt team meeting this Thursday July 16, 2020 at 2:30pm EDT.
All are welcome to attend and bring up items for discussion. As well, we
will be merging a number of code-style pull requests related to YTEP-0037
<https://github.com/yt-project/ytep/pull/14>. I will post a link to the
meeting in the yt slack development channel just before.
Have a good day and see you Thursday.