RIVM-OPS
commented
2 years ago First of all, we'd like to apologise for the late reaction. We'll try to reply more quickly to future issues. Thank you for your suggestion. This has been tested by gjcats in https://github.com/rivm-syso/OPS/issues/6, in those tests no significant differences were found. We agree that it is useful to know more about the effects of precision and plan to conduct our own tests as well. We will update this issue once the results of those tests become available.
monty241
Related to #4.
The current code uses single precision numbers. But even with arbitrary precision numbers, cumulative errors can be introduced when executing many calculation steps and using the output of previous steps as input to next steps. Programmers typically need to take care that numeric errors do lead to outcomes with an accuracy outside of the pre-established required accuracy.
The current code does not ground-up document the rounding errors in terms of precision lost during the process; it may be documented elsewhere.
Also, it seems that during the evolution from the historical code into the current version the scope has been extended to a finer matrix resolution. Maybe the original code was checked for rounding errors, but such a scope change may require additional checks. These might also have been done outside of the code.
A little overly dramatic sample of the past when still studying at EUT was the Patriot software issue as documented on https://hownot2code.com/2016/11/09/r-17-vs-patriot-a-rounding-issue-bugs-in-a-missile-defense-system/.
Suggestion is to extend each method by some documentation assessing the precision loss, allowing top level determination of the accuracy boundaries of the model and whether they fall within the acceptable range.