yt-dev August 2020

yt-dev@python.org

7 participants
5 discussions

yt-4.0
by Cameron Hummels 03 Sep '20

03 Sep '20

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

4 5

problems on installation of yt on Ubuntu 18.04
by Brandon Esquivias Rodriguez 30 Aug '20

30 Aug '20

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

2 1

Some advice on an unusual field case
by John ZuHone 26 Aug '20

26 Aug '20

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

2 3

Updates in recent and upcoming changes
by Clément Robert 11 Aug '20

11 Aug '20

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/2828 https://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/2831 https://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

1 0

ewah_bool_utils repo transfer
by Matthew Turk 05 Aug '20

05 Aug '20

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

3 4

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev August 2020