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
participants (2)
-
Clément Robert
-
John ZuHone