You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create classes to represent normalizations in simulation subpackage #808
Numerical simulations of plasma phenomena are frequently normalized to characteristic values so that the corresponding equations and fields become dimensionless. A strategy for keeping track of normalizations is therefore a necessary building block for a simulation framework. At present, there is no standard method keeping track of normalizations.
Moreover, the normalizations for fluid and particle-in-cell simulations are often done differently. For example, time in a particle-in-cell simulation is often normalized to the ion cyclotron timescale and length is often normalized to the ion inertial length. Length and time in a fluid simulation are often normalized to arbitrary values, but typically related such that the Alfvén velocity is one.
It would be helpful to have a standard way of saving normalizations outside of the package. This could be done for example through a YAML, TOML, or HDF5 file, though there should be an open metadata standard for it.
One headache when dealing with normalizations is figuring out the normalizations for things like diffusion coefficients or viscosities, which are derived from the primary normalizations (e.g., magnetic field, etc.). It would be helpful for the normalization class (or classes) to have a method that takes a set of units that is derived from the base units, and then return the normalization for quantities measured in those units. For example, if we want to return a value that is in units of kg * m ** 2 / s ** 2, we would pass in that set of units, and get a Quantity with those units that corresponds to the normalization. We'd have to be careful for this though, and make sure there aren't any extra factors of two that we would be missing. This wouldn't necessarily need to be created in the first pull request, and could instead be raised as its own issue if we decide to go in that direction.
There are some straightforward cases that could be put in analytically, like the typical normalizations for the MHD equations.
Activity
namurphy commentedon May 10, 2020
Cross-reference: #603
namurphy commentedon May 10, 2020
Oh! And then we could also use dunder methods like
__mul__to define operations like...We could do things like this for other dimensionless objects that we create, like...
namurphy commentedon Jan 1, 2021
Re-opening since #859 only creates the abstract base class for normalizations, and not any concrete normalization classes.