Missing safety checks for the number of field in confin (HDF5 version)

[ALF-Import-Bot]

In GitLab by @gpan on Nov 14, 2025, 16:58 UTC:

I found that in the HDF5-based workflow, there is no check for the number of field stored in confin.h5. This may lead to unsafe behavior when the dimensions of the fields do not match the values in parameters (e.g., ltrot).

Under normal case, a mismatch between ltrot in parameters and the field dimensions in confin.h5 would be caught by the consistency checks against data.h5, and an error would be raised:

Error in test_attribute_double:
  Attribute name: "beta"
  Supplied value: 8.000000
  Read value:     6.000000
  Difference = 2.000000
 alf_hdf5_mod.F90 (757):
 Generic error
 Terminating program
1

then everything is OK. (Also suggests highlighting the difference comes from things in data.h5 and in parameters in the error info. Sometimes, people will think data.h5 only saves measurement, without parameters.)

However, in certain situations — for example, the case encountered by Disha — the user copied only confout.h5 and confin.h5 but not data.h5. When parameters contains an incorrect ltrot value (larger than the dimension in confin.h5), the program performs out-of-bounds array accesses while reading the fields. The run continues and later fails with errors such as NaN elements in the Green’s function, instead of stopping immediately with a clear message of the mismatch of dimension of fields:

 Warning: Smallest scale is approaching the smalles representable value.
          Consider switching to LOG.

or an error like:

Green function A contains NaN, calculation is being aborted!

 control_mod.F90 (239):
 Generic error
 Terminating program

which is not clear what happened.

This suggests that Fields_mod.F90 lacks a necessary consistency check. In particular, after:

CALL h5dget_space_f(dset_id, dataspace, hdferr)

! Get dataspace's rank
CALL h5sget_simple_extent_ndims_f(dataspace, rank, hdferr)

there is no verification that the dimensions of fields in confin.h5 match the allocated size of this%f.

Would it make sense to add an explicit check such as:

if (dims(1) /= SIZE(this%f,1) .or. dims(2) /= SIZE(this%f,2)) then
    STOP "ERROR: configuration size mismatch!"
endif

to prevent silent out-of-bounds access and provide a clear diagnostic early?

I would like to hear your thoughts on whether such a check should be added, or if you believe this situation should be handled in a different way or just ignore this.

Migrated from GitLab: https://git.physik.uni-wuerzburg.de/ALF/ALF/-/issues/329

[ALF-Import-Bot]

In GitLab by @fassaad on Nov 14, 2025, 17:42 UTC:

This security test should be pretty easy to implement. Best Fakher.

[ALF-Import-Bot]

In GitLab by @johanneshofmann87 on Nov 17, 2025, 09:13 UTC:

I think this would be a good opportunity to check which variables we test, and which ones we don't. As far as I can tell, NSweep is not tested nor is the number of MPI tasks (apart from an implicit test in some cases through confin.out [crash if MPI is increased, decreasing the number runs smoothly]). I'm sure there are more variables we should think about.