src/offline/cable_output.F90: Update Tmx and Tmn normalisation factor

[SeanBryan51]

This change updates the normalisation factor used to compute the monthly averages for variables Tmx and Tmn to be rounded to the nearest integer, as the normalisation represents the number of records which are averaged in the monthly interval.

This change is required to demonstrate bitwise equivalence with the new parallel I/O output module (#655).

Type of change

• Bug fix

Testing

• Are the changes non bitwise-compatible with the main branch because of a bug fix or a feature being newly implemented or improved? If yes, add the link to the modelevaluation.org analysis versus the main branch or equivalent results below this line.

Site tests show no differences as Tmx and Tmn is not available when outputting at all time steps:

2026-03-13 15:00:05,349 - INFO - benchcab.benchcab.py:380 - Running comparison tasks...
2026-03-13 15:00:05,375 - INFO - benchcab.benchcab.py:381 - tasks: 168 (models: 2, sites: 42, science configurations: 4)
2026-03-13 15:02:48,547 - INFO - benchcab.benchcab.py:391 - 0 failed, 168 passed

Spatial tests show precision level differences in Tmx and Tmn

$ nccmp -df -c 1 runs/spatial/tasks/crujra_access_R*_S0/archive/output000/cable_out.nc
DIFFER : VARIABLE : Tmx : POSITION : [0,0,59] : VALUES : 10.7635 <> 10.7635
DIFFER : VARIABLE : Tmn : POSITION : [0,1,59] : VALUES : 6.41132 <> 6.41132

Variables are equivalent if we allow for an absolute tolerance of 1e-5:

nccmp -d -t 1e-5 runs/spatial/tasks/crujra_access_R*_S0/archive/output000/cable_out.nc
nccmp -d -t 1e-5 runs/spatial/tasks/crujra_access_R*_S1/archive/output000/cable_out.nc
nccmp -d -t 1e-5 runs/spatial/tasks/crujra_access_R*_S2/archive/output000/cable_out.nc
nccmp -d -t 1e-5 runs/spatial/tasks/crujra_access_R*_S3/archive/output000/cable_out.nc

---

📚 Documentation preview 📚: https://cable--711.org.readthedocs.build/en/711/

[Whyborn]

Do we have to cast output%interval * int(dels) to 4 byte reals? Why are we converting dels to INT, and then casting the result to a REAL? Can't we just leave dels as a REAL?

Seems like it should read

out%Tmx = out%Tmx/NINT((output%interval * dels) / 86400)

I think that would give the same result, assuming default 4 byte precision?

[SeanBryan51]

Just confirmed your suggestion gives the same results as expected. Thanks