Hey devs,
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.
Thanks, everyone!
Cameron
--
Cameron Hummels
Computational Astrophysicist
California Institute of Technology
http://chummels.org
Hello,
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
Sincerely,
Brandon Esquivias
Hi folks,
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.
Best,
John
Hi yt-folks
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
contribution https://github.com/ikamensh/flynt/pull/72)
- 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)
For instance
https://github.com/yt-project/yt/pull/2823 (merged)
https://github.com/yt-project/yt/pull/2828https://github.com/yt-project/yt/pull/2829
In the same spirit, here are two of mines that propose moving the load_* functions
to a common namespace
https://github.com/yt-project/yt/pull/2831https://github.com/yt-project/yt/pull/2832
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.
https://github.com/yt-project/yt/issues/2788
note that we have a new GitHub label for this kind of contributions: “refactor” !
Stay out of trouble and enjoy the summer
Cheers !
Clément
Hi folks,
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
alright idea.
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,
-Matt
