Naming convention changes for energy and momentum-related fields: may affect your frontend
Hi folks, I’ve written a PR which (among other things) defines some new standards for yt-4.0 in terms of naming fields which represent energy and momentum-related quantities. In short, the issue is this: the various energy fields in yt have an inconsistent naming scheme. For example, the "kinetic_energy" derived field is an energy density (say ergs/cm^3), but "thermal_energy", which usually is aliased from output fields in frontends, is usually a specific energy (erg/g). Also, momentum fields, which they appear in certain frontends, are almost always "momentum density" fields instead. The PR addresses this inconsistency by renaming fields wherever they appear using the following scheme: Energy density fields are named like this: "kinetic_energy" --> "kinetic_energy_density" Specific energy fields are named like this: "thermal_energy" --> "specific_thermal_energy" Momentum density fields are named like this: "momentum_x" --> "momentum_density_x" Eventually, we really ought to have some kind of domain context which handles all this--and this PR should be seen as the prep work for something like that, in addition to a new class which handles different equations of state which I would also like to do. So why should you care? One reason may be that this PR affects field definitions for energy and/or momentum fields in a number of frontends. They are ART ARTIO Athena Athena++ Boxlib Chombo Enzo Enzo-P FLASH GAMER GDF GIZMO SPH Stream If you are a maintainer or a user of one of these frontends, it may be a good idea to check my proposed changes to see if they are in the spirit of what you and other users would be fine with. In any case, the PR is here for your review: https://github.com/yt-project/yt/pull/3059 Comments, suggestions welcome. Best, John
This is excellent and I appreciate the effort you put in to make the transition as painless as possible with a clear deprecation path. Handling equations of states outside of frontends also seem like a nice thing to do, but there should be room for extensions at the frontend level. In AMRVAC we have a handful of EOS and users are even allowed to define their own, which completely unsupported atm in the frontend. Thank you for doing this ! Cheers Clément On Wed, Mar 10, 2021 at 19:57, John ZuHone <jzuhone@gmail.com> wrote:
Hi folks,
I’ve written a PR which (among other things) defines some new standards for yt-4.0 in terms of naming fields which represent energy and momentum-related quantities.
In short, the issue is this: the various energy fields in yt have an inconsistent naming scheme. For example, the "kinetic_energy" derived field is an energy density (say ergs/cm^3), but "thermal_energy", which usually is aliased from output fields in frontends, is usually a specific energy (erg/g). Also, momentum fields, which they appear in certain frontends, are almost always "momentum density" fields instead.
The PR addresses this inconsistency by renaming fields wherever they appear using the following scheme:
- Energy density fields are named like this: "kinetic_energy" --> "kinetic_energy_density" - Specific energy fields are named like this: "thermal_energy" --> "specific_thermal_energy" - Momentum density fields are named like this: "momentum_x" --> "momentum_density_x" Eventually, we really ought to have some kind of domain context which handles all this--and this PR should be seen as the prep work for something like that, in addition to a new class which handles different equations of state which I would also like to do.
So why should you care? One reason may be that this PR affects field definitions for energy and/or momentum fields in a number of frontends. They are
- ART - ARTIO - Athena - Athena++ - Boxlib - Chombo - Enzo - Enzo-P - FLASH - GAMER - GDF - GIZMO - SPH - Stream
If you are a maintainer or a user of one of these frontends, it may be a good idea to check my proposed changes to see if they are in the spirit of what you and other users would be fine with.
In any case, the PR is here for your review:
https://github.com/yt-project/yt/pull/3059
Comments, suggestions welcome.
Best,
John
Hi Clément,
Handling equations of states outside of frontends also seem like a nice thing to do, but there should be room for extensions at the frontend level. In AMRVAC we have a handful of EOS and users are even allowed to define their own, which completely unsupported atm in the frontend.
The idea here is more that there would be a class which could take a few field definitions (do you have density+temperature, or density+internal energy, or something else) and then define the rest of the fields from those. But this wouldn’t be something that is separate from frontends--on the contrary, each frontend would use EOS objects to create field definitions from the fields and other metadata defined on disk. John
participants (2)
-
Clément Robert -
John ZuHone