rivm-syso / ops Goto Github PK

https://nl.wikipedia.org/wiki/ISO_25010

https://www.nen.nl/NEN-Shop/Norm/NPR-53262019-nl.htm

I suggest adding the topic air-pollution in the About section.

Connect OPS to WFS on BAG dataset....

#tbc

The current release contains change notes with the names of persons no longer involved in developing and/or maintaining the code base.

These are quite hard to remove completely thanks to git but maybe a good start would be to remove them from next release.

Code contains constructs like in ops_cals_stats.f90:
if (somcpri .gt. 0.0) then
Starting with Fortran 90 when I am correct (correct me if wrong), this can be replaced by:

if (somcpri = 0.0) then
which is easier to understand by coders recently graduating. Replacing some other traditional Fortran constructs by more modern constructs might also help adoption.

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.

The code modules all use REAL*4 currently, which is (when I am correct) a single precision 32-bit floating decimal number.

For instance in ops-convec.f90:

• REAL*4 z0
• REAL*4 zi

I consider OPS a weather-related calculation model. As far as I know most of these nowadays use 64-bit double precision numbers for calculations. Especially during a large number of calculation steps, precision may get lost or unacceptable cumulative errors may be introduced.

From the historical perspective on 1989, I can imagine that an array with 100K numbers might have been hard to fit into memory of a HP/DEC workstation or time sharing solution, but nowadays a double precision no longer has to incur extra memory costs.
Back then, a FPU (when present) might have similated double precision using multiple single precision calculations or the main processor might have similated them. Nowadays, double precision is seen more often than single precision both in hardware as software from where I stand.

A related issue is created regarding estimating cumulative errors and to assess whether they do not influence the accuracy of the model as documented on the RIVM website.

When changes are made to the model, there is no unit test to verify and/or assess impact impact. Some pre-defined input and output files with possibly edge cases would ease validation of changes.

1. improve readability
2. improve code quality
3. avoid errors on parameters names
4. ...

#tbc

Voor beter begrip van de context zou het openbaar maken van het openbaarmaken van Aerius en OPS helpen.

Mogelijk is de oorzaak beschreven in https://uitspraken.rechtspraak.nl/inziendocument?id=ECLI:NL:RBDHA:2019:13779, maar mogelijk eerdere of latere besluiten, binnen RIVM, ministeries of rechter, hebben hiertoe geleid. Als buitenstaander is best lastig om de historie te bepalen op basis van nieuwsartikelen zoals https://www.omropfryslan.nl/nl/nieuws/927198/rechter-rivm-moet-rekenmodel-voor-stikstof-vrijgeven.

Daarnaast is er gezien het NRC-artikel https://www.nrc.nl/nieuws/2022/06/11/de-man-achter-het-model-waarmee-den-haag-stikstofberekeningen-doet-a4133158 blijkbaar enige verwarring over de rollen van Aerius en OPS in het berekeningsproces. Mogelijk is het handig om relatie met Aerius beter te belichten in de readme, zoals bijvoorbeeld beschreven in https://nl.wikipedia.org/wiki/AERIUS.

Suggestion is to add a folder structure, such as:

• src for the f90 files
• test for test cases
• doc for documentation
  etc.

Auto DevOps
It will automatically build, test, and deploy your application based on a predefined CI/CD configuration.

check: https://gitlab.com/AERIUS

It's needlessly frustrating and against the principles of OpenSource to not include a Makefile.

Considering the RIVM is aware of the lack of makefile (hence the request to email them in the readme), It seems clear this frustration is on purpose.

Please just include the makefile.

#tbc