f90nml fails to read namelist entries for Fortran90 structure variables

[pjoeckel]

f90nml version: 1.1.2
python: 3.6.9 (default, Oct 29 2019, 10:39:36) [GCC]
OS: SuSe Linux 15.0

f90nml fails to read namelists, which contain entries for initialising arrays of types (fortran structures), such as

  TYPE T_TS_IO
     !
     CHARACTER(LEN=STRLEN_OBJECT) :: name = ''
     CHARACTER(LEN=STRLEN_ULONG)  :: fname = ''
     REAL(DP), DIMENSION(2)       :: vr = (/ -HUGE(0.0_dp), HUGE(0.0_dp) /)
     INTEGER, DIMENSION(2)        :: cnt = (/TS_BD_STOP, TS_BD_STOP/)
     INTEGER                      :: im = TS_IM_PREV
     INTEGER, DIMENSION(6)        :: pdt = (/ -1, -1, -1, -1, -1, -1 /)
     REAL(DP)                     :: offset = 0.0_dp
     !     
  END TYPE T_TS_IO
  TYPE(T_TS_IO), DIMENSION(NMAXTS), PUBLIC :: TS

with the corresponding import.nml

&CTRL_TS
!
TS(1) = 'qbo', '$INPUTDIR_MESSY/qbo/misc/FUB_01_hist_X_QBO_195001_201212.txt',  ,99.90, 0, 0, 0, , , , , , , 0.0,
!
TS(2) = 'solact','$INPUTDIR_MESSY/jval/misc/NRLSSI_FUB1.0_hist_X_solar1AU_19500101_20111231.txt', , , 0, 0, 0, , , , , , , 0.0,
!
TS(4) = 'solspec','$INPUTDIR_MESSY/rad/fubrad/misc/NRLSSI_FUB1.0_hist_X_spec055_19500101_20111231.txt', , , 0, 0, 0, , , , , , , 0.0,
!
/

The output of

import f90nml
nml = f90nml.read('import.nml')
print(nml)

becomes

 python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value $INPUTDIR_MESSY/qbo/misc/FUB_01_hist_X_QBO_195001_201212.txt is not assigned to any variable and has been removed.
  ''.format(v=next_value)
 python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value 99.9 is not assigned to any variable and has been removed.
  ''.format(v=next_value)
  python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value 0 is not assigned to any variable and has been removed.
  ''.format(v=next_value)
 python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value 0.0 is not assigned to any variable and has been removed.
  ''.format(v=next_value)
 python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value $INPUTDIR_MESSY/jval/misc/NRLSSI_FUB1.0_hist_X_solar1AU_19500101_20111231.txt is not assigned to any variable and has been removed.
  ''.format(v=next_value)
 python3.6/site-packages/f90nml/parser.py:788: UserWarning: f90nml: warning: Value $INPUTDIR_MESSY/rad/fubrad/misc/NRLSSI_FUB1.0_hist_X_spec055_19500101_20111231.txt is not assigned to any variable and has been removed.
  ''.format(v=next_value)
&ctrl_ts
    ts(1:4) = 'qbo', 'solact', , 'solspec'
/

I wonder, if this is a bug or a missing feature?
At least it is a valid namelist ...

[marshallward]

No, we don't support anything like this at the moment. I'm not even sure how it would work, though there are options discussed below.

It's rejecting your namelist because it thinks you're trying to assign an array to an array element. I think it would also have issues since it would think this is an array of mixed types.

I have to think about how to handle this case. We confront certain limitations since the namelist does not carry information about the type of its input. In this case, though, one might be able to infer it since the data is mixed. Alternatively, we could just start supporting arrays of mixed type as valid inputs for an element, indexed or otherwise.

To clarify one point: We do support arrays of derived types. But we don't currently support this sort of array initialization across fields.

[marshallward]

BTW I can confirm that f90nml can parse this array-based assignment over fields if TS is not an array, so the mixed types is not a issue, although there is still the problem of not knowing what it is.

You can get out of your current situation if you replace the array initialization with explicit fields. For example, if I read/write your example namelist in GFortran 9, this is the output:

&CTRL_TS
 TS(1)%NAME="qbo                                                                                                 ",
 TS(1)%FNAME="$INPUTDIR_MESSY/qbo/misc/FUB_01_hist_X_QBO_195001_201212.txt                                        ",
 TS(1)%VR= -3.4028234663852886E+038,  99.900000000000006     ,
 TS(1)%CNT= 2*0          ,
 TS(1)%IM=0          ,
 TS(1)%PDT= 6*-1         ,
 TS(1)%OFFSET=  0.0000000000000000     ,
 TS(2)%NAME="solact                                                                                              ",
 TS(2)%FNAME="$INPUTDIR_MESSY/jval/misc/NRLSSI_FUB1.0_hist_X_solar1AU_19500101_20111231.txt                       ",
 TS(2)%VR= -3.4028234663852886E+038,  3.4028234663852886E+038,
 TS(2)%CNT= 2*0          ,
 TS(2)%IM=0          ,
 TS(2)%PDT= 6*-1         ,
 TS(2)%OFFSET=  0.0000000000000000     ,
 TS(3)%NAME="                                                                                                    ",
 TS(3)%FNAME="                                                                                                    ",
 TS(3)%VR= -3.4028234663852886E+038,  3.4028234663852886E+038,
 TS(3)%CNT=1          ,999        ,
 TS(3)%IM=123        ,
 TS(3)%PDT= 6*-1         ,
 TS(3)%OFFSET=  0.0000000000000000     ,
 TS(4)%NAME="solspec                                                                                             ",
 TS(4)%FNAME="$INPUTDIR_MESSY/rad/fubrad/misc/NRLSSI_FUB1.0_hist_X_spec055_19500101_20111231.txt                  ",
 TS(4)%VR= -3.4028234663852886E+038,  3.4028234663852886E+038,
 TS(4)%CNT= 2*0          ,
 TS(4)%IM=0          ,
 TS(4)%PDT= 6*-1         ,
 TS(4)%OFFSET=  0.0000000000000000     ,
 /

(taking a few liberties with your example, and also explicit removing the TS(3) entry, which used the default values.)

f90nml seems to be reading this namelist correctly.

But I still agree that your original example is a valid namelist, even if a challenge to parse, and it's worthwhile to try and support it to the best of our ability.

[jacobwilliams]

Would any Fortran compiler's namelist READ be able to understand the original case? I would think not, but I've never tried anything like that before. That's certainly not what a namelist WRITE would produce for any compiler I've seen.

[marshallward]

I tested @pjoeckel's example in gfortran 9.2 and it worked, and the standard does seem to support this list-style input for derived types (13.11.3.2p2):

When the designator in the input record represents an array variable or a variable of derived type, the effect is as if the variable represented were expanded into a sequence of scalar list items, in the same way that formatted input/output list items are expanded (12.6.3).

I also agree that this is not the usual output, and I can't imagine any compiler producing this style of output.