Resolve difference between input and update

[mgovers]

It turns out that input data and update data are not treated exactly the same way in power sensors.

When rounding errors caused by this propagate, a difference may occur between single calculations run with measurement data provided in input data, or (batch or single) calculations with power sensor measurements provided in (batch or permanent) update data.

NOTE: similar rounding errors introduced when calculating the inverse update may also propagate to other scenarios, so the result may even differ between different orderings of batch scenarios or threading levels

• power sensor
  • this fix works as is for the input vs update of power sensor
  • but not yet for the inverse update EDIT: as mentioned below: we do not apply the propagation of inverse update calculation in this PR. It may not be as big of an issue as one would expect.
• voltage sensor
  • from a quick investigation, it turns out that the voltage sensor may also be prone to this, but no combination of values that reproduces this bug has been found yet EDIT: a combination of values was found and added to the unit tests.
• other component types
  • it seems that other component types are not prone to this bug, because their input/update values are directly stored without modifications.
  • this suggests that doing so for the sensors as well provides a sustainable solution

[TonyXiang8787]

@mgovers what exactly is the drifting here? We do not have addition/subtraction drift right? Multiple/division usually does not cause large drift.

[mgovers]

@mgovers what exactly is the drifting here? We do not have addition/subtraction drift right? Multiple/division usually does not cause large drift.

• for single run vs batch run:
  • the test case in which we found this apparently is sensitive to initial conditions.
  • the small floating point difference therefore is enlarged
  • as a result, in one case, a single calculation may end up converging while a single-scenario batch calculation diverges, or vice versa
• for the inverse update case:
  • there is also inverse update drift, which indeed is only multiplication and subtraction rounding errors
  • however, they may still accumulate for batch calculations with very many scenarios
  • similarly, accumulation is possible for repeated calculations with the same model instance
  • again, grids that are relatively sensitive to initial conditions may also enlarge these effects

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mgovers]

@TonyXiang8787 I added you as a reviewer because I would like you to be the one to sign off on this change.