Limited use of nn_fsbc (and nn_dttrc) due to set_xmlatt bug

[hadcv]

The automatic freq_op definition using nn_fsbc in set_xmlatt (iom.F90) as revised at r3940 (ticket #1122) is currently written to XIOS as a size 1 integer:

WRITE(cl1,'(i1)') nn_fsbc ; CALL iom_set_field_attr('SBC' , freq_op = cl1'ts', freq_offset='0ts')
WRITE(cl1,'(i1)') nn_dttrc ; CALL iom_set_field_attr('ptrc_T' , freq_op = cl1'ts', freq_offset='0ts')
WRITE(cl1,'(i1)') nn_dttrc ; CALL iom_set_field_attr('diad_T' , freq_op = cl1'ts', freq_offset='0ts')

This causes an overflow for nn_fsbc >= 10 and causes the model to hang during the iom_setkt call. Presumably there is a similar issue for nn_dttrc >= 10.

Simply fixed by instead specifying something like:

CHARACTER(len=16) :: clfreq
WRITE(clfreq,'(i0)') nn_fsbc

Does this sound ok?

[acc]

WRITE(clfreq,'(i0)') nn_fsbc

Does this sound ok?

Not sure if i0 is standard? The f90 standard I checked states that for the 'Iw' edit descriptor, w must be positive.

[acc]

... but 'i0' is in the Fortran2003 standard:

On output, with I, B, O, Z, and F editing, the specified value of the field width w may be zero. In such cases, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks. The specified value of w shall not be zero on input.

so it should be ok.

[smasson]

We had internal discussions when I introduced this '(i1)'. It appears that nobody ever used values larger than 5 (or maybe 7?). The larger is the value, the larger is the error you are doing. We would not recommend to use higher value than 5. That's why we though that using '(i1)' would be ok. I would try to avoid fancy features of f2003 that could create problems with some compilers...

[hadcv]

My case is rather extreme I will admit, as I was using nn_fsbc=45. I agree we would not want to use values of this magnitude!

'i0' is a cover-all, but as you say is not native to Fortran 90. Perhaps the best thing to do then is to have a ctl_stp call for "lk_iomput=TRUE & nn_fsbc > 9" so the model fails with an explanation at least (instead of hanging).

[hadcv]

Done at [4164], as per proposed fix in comment 4