Copying parameters results in additional decimals places

[OFR-IIASA]

When copying parameters from one scenario to another, without modifications, the amount of decimal places increases dramatically. i.e. a parameter which originally had a value of 1.0, will end up as 1.000000234 (or something similar) when being copied from one scenario to another. This can not only result in troubles solving the model but can also result in problems, for example when defining the fractions of sub-annual timesteps.

[khaeru]

@OFR-IIASA thanks for the report.

1.000000234

I think this indicates that, somewhere, floating point numbers are being converted to single-precision (32-bit) format.

The smallest number greater than 1 that can be represented in single-precision is 1 + 2^(−23) ≈ 1.000,000,119,2; any number in between the two must be stored identically to 1 or that value. Here is another example of an unintuitive result caused by using single-precision floats.

To fix this, we should check where along the code path float32 might be used inadvertently.

@zikolach can you comment on which float formats are being used in ixmp_source?

[zikolach]

Quickly searching through the code showed that we use float type:

• returning variable/equation level/marginal (getLevels, getMarginals)
• returning parameter value (getValues)

In all other places we use Double.

[zikolach]

@OFR-IIASA can you please describe what exactly is done?

When copying parameters from one scenario to another, without modifications...

Do you clone scenario?

[OFR-IIASA]

@zikolach An example of what the procedure is: load a scenario e.g. message_ix.Scenario(mp, model_name, scenario_name) retrieve any parameter e.g. df = scen.par('input') checkout scenario add parameter e.g. scen.add_par('input', df) commit change

[zikolach]

It sounds like easy to write a test. There is a change iiasa/ixmp_source#250 which could fix issue with double-to-float conversion.