Avoid using uninitialised trunk_sumbal

[SeanBryan51]

The trunk_sumbal value is still used in the offline driver when a consistency check file cannot be find. To avoid using a garbage value and potentially causing an exception, this change moves the tolerance calculation and the trunk_sumbal initialisation into a single subroutine so that trunk_sumbal is used only when it is successfully read from the the consistency check file.

Type of change

Please delete options that are not relevant.

• Bug fix

Checklist

• The new content is accessible and located in the appropriate section
• I have checked that links are valid and point to the intended content
• I have checked my code/text and corrected any misspellings

Testing

• Are the changes bitwise-compatible with the main branch? If working on an optional feature, are the results bitwise-compatible when this feature is off? If yes, copy benchcab output showing successful completion of the bitwise compatibility tests or equivalent results below this line.

2025-03-25 11:11:26,592 - INFO - benchcab.benchcab.py:380 - Running comparison tasks...
2025-03-25 11:11:26,627 - INFO - benchcab.benchcab.py:381 - tasks: 168 (models: 2, sites: 42, science configurations: 4)
2025-03-25 11:14:17,701 - INFO - benchcab.benchcab.py:391 - 0 failed, 168 passed

---

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

[Whyborn]

We should probably drop all these DOUBLE PRECISION occurrences at some point

[SeanBryan51]

@Whyborn I've decided to go with a different approach: instead of always initialising trunk_sumbal to -1.0, I've promoted trunk_sumbal to be allocatable to avoid using the variable when it is has not been allocated. This was because I realised the claim I made that "the default value of -1.0 for trunk_sumbal is chosen so that the tolerance (ABS(new_sumbal - trunk_sumbal)) is always greater than or equal to 1.0" is incorrect because new_sumbal could potentially be negative depending on the energy and water balance. I figured this was a better way to avoid this issue.

[Whyborn]

And so the code will throw an error if the value is used before being allocated? I've never tried to use ALLOCATABLE with scalars- I'm guessing it autoallocates when you try to assign it a value?

[SeanBryan51]

And so the code will throw an error if the value is used before being allocated?

Not necessarily, that would depend on the compiler flags and any runtime memory checks that are enabled.

I just tried removing the ALLOCATED condition before computing the tolerance and the code did not error.

I'm guessing it autoallocates when you try to assign it a value?

Allocatable scalars still need to be allocated. The only difference is an array shape specification is not needed when allocating scalars: https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-0/allocate-statement.html

[Whyborn]

Explicit ALLOCATE statements aren't always required for ALLOCATABLE variables; allocation can happen implicitly when assigning a value to the variable e.g.

REAL, DIMENSION(:), ALLOCATABLE :: arr
REAL, ALLOCATABLE :: scal

arr = [1.0, 2.0, 3.0]
scal = 4.0

appears to be perfectly valid F90 code.

[SeanBryan51]

Explicit ALLOCATE statements aren't always required for ALLOCATABLE variables

I did not know implicit allocation on assignment existed in Fortran. Good to know!

After letting this PR simmer in my brain a bit, I think the use of an allocatable scalar in this situation might be overkill: in the broader picture, the value of trunk_sumbal shouldn't be read in at initialisation in cable_driver_init, it should be read in only when we calculate the tolerance. The reason why it was done this way was due to the original structure of the drivers. A much simpler way would be to wrap the initialisation of trunk_sumbal and the tolerance calculation in a subroutine and call that on the last time step.

[Whyborn]

Yea, it seems a bit cumbersome to carry this variable around everywhere, rather than just getting it when we need it.

[SeanBryan51]

Looks like I forgot to rerun benchcab. Once I get the okay from benchcab I will merge this in.

Note: the build-ci for CABLE is currently broken (see #575) so I will ignore this action for now.