Repository navigation
Variable standard naming and units #132
Description
Activity
This has ties to #65
Recommand using names define in https://agroportal.lirmm.fr/
We could take inspiration from how Dyad handles those things; and even reuse some of their code if their licence allows it.
Basically the idea would be to require a standard name for variables and some units. The units would be given by the standard, and if the variable is new (i.e. not in the standard), we would require a short description and the units somewhere (next to the inputs/outputs, or in the doc string ?). Then we could provide a check on models and modellist/mapping to see if all units are compatible, including how units in the inputs would propagate in the outputs, and if those computed units are compatible with what is given by the user / the standard.
The standard would be published in the docs of PSE. And people could open a PR to add new variables.
Also, we could hack into documenter (see talk at JuliaCon 2025) to add the variables definitions and units automatically from the reference or user to all models based on the inputs and outputs lists.
Also take a look at https://github.com/Deduction42/FlexUnits.jl
Closing #65 (redundant with this one). Its comment (by VEZY) was :
- A variable should be named using the standard name used in the community.
- It shouldn’t include the variable unit, as it may depend on the unit of the model inputs.
- The unit and description of the variable should be documented in the model structure documentation. If the unit depends on the inputs of the model, state it.
- Variables should be snake case, e.g. leaf_area, unless widely used in the community, e.g. LAI
- Variable names shouldn’t be abbreviated, unless widely used by the community, e.g. leaf area should be named leaf_area, not la. LAI should be fine, but leaf_area_index is better.
- A variable should be named with a generic name, e.g. temperature instead of temperature_leaf, so the same name can be used at different scales. One exception is when a variable integrates the values from other scales; e.g. Rm_plant is fine if it is computed using the sum of all Rm of the organs in the plant.
For units, we could add a new trait based on the variables (inputs/outputs) that would define the units for each variable. That would allow us to validate units only once by activating an option during model run (we would use the units for all variables), and not use them once validated (so simulation performance is not penalized by units)
This is a more general PlantMeteo XPalm PlantBioPhysics and PlantSimEngine issue : what process/validation method to use to define and access variables that have been standardised in literature, so that future modelers can easily make use of them, and expand the list in a consistent manner.