Resolve type consistency in C-Mod validity range metadata

[nbarbour13]

Problem

TOML uses strong typing as it parses the config.toml files. Disruption-py physics variables write as floats.
Currently, some validity ranges for C-Mod contain no “.” characters in either the lower or upper bound, prompting TOML to interpret the range bounds as integers (C long long). This causes the resulting netCDF metadata headers to have a type mismatch when viewed with ncdump -h. While not strictly a problem, this can be cleaned up with edits to the config.toml.

Example output from current dev branch:

Implementation

Performed a pass over validity ranges for all machines and inserted “.” to prompt type translation to float. Presently, only C-Mod has validity ranges, so all changes were made to disruption_py/machine/cmod/config.toml. I have added "." characters to all ints for consistency, even in cases where an int was paired with a float (e.g. validity = [0.1, 40] becomes validity = [0.1, 40.0]).

Out of Scope

• Adding validity ranges to other machines
• Physics review of validity ranges
• Enforcement of Validity ranges

This PR is intended as a lightweight change in support of FY26 milestones. A full review and functional integration of validity ranges is left for future work.

[gtrevisan]

alright! you definitely need the decimal point, but do you need the following 0 digit?

[nbarbour13]

alright! you definitely need the decimal point, but do you need the following 0 digit?

Surprisingly, yes: https://toml.io/en/v1.0.0#float
TOML floats require at least one digit after the decimal point if it is used.
Fractional floats require the decimal point. Exponent floats do not.
If you would like, I can omit them from exponent floats.
Since they are required for the fractional floats, I thought to use them for consistency.