[EPIC] Unit system

[MelReyCG]

Issue general information

What is the requested feature?

• A unit system for GEOS.

Is your request related to a specific problem?

1. Some data structures, as the TableFunction, hold data and does not know its unit, so related reports or error message can be misleading.
2. GEOS users cannot specify which unit they want for the various input & output data.
3. The code could be more self-explaining if variables could be declared as Pressure, Distance or Viscosity type rather than real64.
4. There is a lack of information on the temperature units (Kelvin or Celsius) at different places in the code.

---

• [x] I. Add a simple unit system to GEOS so when we store unqualified data, we can add the wanted unit metadata to it.
• GEOS PR that need this system: #2552
• [x] #3733
• [ ] Attach unit info to inputs (Wrapper)
• [ ] Attach unit info to HDF5 output as a metadata (as a data description)

---

• [ ] II. Add a statically typed unit system.
• We could add or inspire from a library like mp-units.
• We need an extensive, simple and light solution, the goal is not to complexify the code nor to affect the performances.
• We need to be able to statically or dynamically add an unit to a value or a container.

---

• [ ] III. Expose a unit system configuration for GEOS input / output.
• Add a <UnitSystem/> node to <Problem/>
• Add a preset attribute to UnitSystem, which would allow to quickly use a unit system preset as a base. These preset would be documented in the user guide, and would be added by the different teams working on GEOS.
• Add <UnitSystem/> children node for each characteristics. As an exemple : <Time inputFiles="years" stdout="days" outputFiles="s" /> Or, as a more uniform exemple : <Time units="d" />

_Note: I'm not perfectly convinced that the task II. is required for GEOS, input / output conversion may be sufficient.

[rrsettgast]

@MelReyCG Lets pick this back up. As a reference, the way we did units in the old GEOS as to have them be strictly an input/output concept.

• There was a unit block with the default system.
• Any numerical values were allowed to contain a unit at the end of the input string. These would be separated with a space, allowing parsing of the units upon processing of the XML.
• Values with a unit other than the default system would be converted to the default units, values with no unit specified would be assumed to be in the default unit. We generally used SI as the default units.
• The internals of the code had no concept of units.
• outputs could be converted to a output unit system.

I think this is kind of a subset of what you propose, but it is fairly non-intrusive. The problems we have now are the fact that we have other ways to access data (i.e. python interface) but could try to specify values in the non-default units....etc.

[untereiner]

The problems we have now are the fact that we have other ways to access data (i.e. python interface)

That’s a reason we propose to statically type C++ variables: Compute functions can then be overloaded for different unit types and do computation in different ways

[rrsettgast]

Can you give an example of a case where we would want to overload a compute function based on unit type?