Introduction of Pint for quantities and units

[RollingTechSupport]

Summary

Since PyRolL currently supports all metric units but all of the "physical quantities handling" has to be done by the user, I suggest a filter layer for the import to introduce units.
This would benefit PyRolL since "simple" users don't want to think about to much stuff before doing their first simulation.
Also some model approaches (mostly the empirical ones) work in specific physical quantities.
Therefore the introduction of physical quantities would further protect PyRolL from misuse.

A possibility to introduce units is the python package pint .
This could act as a translation layer, anchored inside a own extension plugin.
First of I would like to discuss it generally.

[axtimhaus]

First, I would definitely not introduce it into the core, since it will have a significant performance overhead and be a major breaking change, breaking basically everything.

As an extension it could be feasible. There we would have the following issues:

• To parse from the input layer all values have to be strings now. It is not possible to use native data types such as integers and floats of respective text file formats or similar. Therefore, maybe the most feasible for a GUI interface, where the input values are strings anyway.
• Using Python scripts as input gets quite cumbersome with always using the unit registry.
• The number format hooks in the report all have to be overridden with respective unit formats. Do it in pyroll.report if pyroll.units is present or the other way round?
• Maybe monkeypatch the repr of PyRolL core objects.
• Output use of units will require a mechanism to remember the unit of each value (or at least the dimensions). For core hooks maybe patch the Hook instances with unit/dimension attributes. Calculation shall be done in SI anyway.

If not providing a distinct extension but as part of a certain UI:

• Stick to pure string input as mentioned above.
• Remembering units in data model of the UI, which is generally independent from the core data structures, but is mapped to those.
• Hide the simulation stuff from the user, which is all done in SI.
• pyroll.core and plugins do not need to know anything about units.
• Converting of quantities to floats and back in an intermediate layer between UI and core resp. plugins.
• Plugin set must be hardcoded in some way. Something like a selected set of plugins supported to choose from. Is a feasible approach for a complex UI anyway.

The latter approach sounds the easiest way for me. The first may get very hacky and error prone.

[RollingTechSupport]

Closed due to inactive.