Standardized/formatted NAMELIST output write


Is there a way to specify or standardize the way a namelist is written to output?

For example, if I have:

namelist /stuff/ stuff1,stuff2,stuff3%more1,...

and then I want to write it to a file or standard out, such as:

write (9,stuff)

What is writes looks very different depending on the compiler and all character arrays are printed with all their characters even if they are blank.
Therefore the output is awful to look at, and impossible to parse in a portable way due to the changes.

Is there any way the Fortran language could standardize and/or allow formatting templates for namelist writes?

Or, failing that, does anyone know of a simple Fortran library that can write out a namelist in a portable sane way?


  • Ron

Is your purpose to have the namelist output as an easy means to read the values back in again in another Fortran program (or to restart the current one) or do you want to get output that can be used in a completely different context?

In the latter case, by far the easiest way is to use formatted output, so that you have almost full control over the layout and other details. Namelists are not meant for this type of control.

f90nml will parse a namelist and reproduce itself according to a consistent format.

This formatting is very heavily biased to my own preferences, but there are a few formatting flags to control the appearance.

One practical benefit is that many compilers will strip strings of their delimiters (as, paradoxically, required by the standard). Passing through f90nml will restore those delimiters in most cases.

I agree that the output produced by most compilers is rather butt-ugly.

The remarkable thing is that Intel Fortran strips the delimiters from the strings but gfortran requires them. So Intel Fortran can read the file produced by gfortran but not vice versa.

If I recall from my conversation with @sblionel, both are following the standard, albeit in different ways.

Only delimited strings are compliant, so if your namelist has no delimiters then it is not a standards-compliant namelist. GFortran opts to reject such namelists. Intel makes a go at reading them, even though it’s no longer a True Namelist. So Intel can do whatever it wants with this odd quasi-namelist.

The original sin is this: If you do not include delim then your namelist will not use delimiters, according the rules of list-directed output as required by the standard. But this also results in producing a thing which is not actually a namelist!

GFortran averts this paradox by defying the standard and using delimiters. Intel adheres to the standard and will not default to using them. So they have a stronger incentive to ignore them.

I did try to propose changing the default delim value for namelists in this draft proposal but the second-hand feedback was not encouraging so I did not pursue the issue any further.

(And I’m sure none of this is of much interest to the OP!)

@marshallward , not quite…

The standard says that the default for DELIM= is “NONE”. This applies to both list-directed and namelist-directed output. The standard then says, for namelist output:

Namelist output records produced with a DELIM= specifier with a value of NONE and which contain
a character sequence might not be acceptable as namelist input records.

For namelist input, a lack of delimiters is fine for character input, as long as there are no value separators in the string read. For gfortran to give an error in this case would be improper. I hope you are misremembering what it does. If there are no delimiters, then it is standard-conforming to read a character value up until the next value separator (whitespace, comma, slash).

Intel is not “stripping” delimiters.

(Tried to edit my post, but accidentally deleted it…)

I based my statement on this paragraph ( from 1539-1:2017):

When the next effective item is of type character, the input form consists of a sequence of zero or more rep-chars whose kind type parameter is implied by the kind of the corresponding list item, delimited by apostrophes or quotes.

If the strings have no delimiters, then the end product is not a namelist.

If the program is directed to write a namelist without delimiters, then it’s not writing a namelist but rather a thing which closely resembles a namelist.

And I agree here that Intel is following the rules and GFortran is not. So I was incorrect when I accused Intel of “stripping” delimiters. If I had been more careful with my words, I would have said that the output resembles a namelist whose delimiters have been stripped.

I did notice (and the reason for my edit) that does add the crucial phrase “possibly delimited sequence” when reading a namelist, so I also misspoke on this point. (This is list-directed input, oops. Anyway, I will let @sblionel clarify things for me… :slight_smile: )

I did write a quick test code before my previous post, and I observed that GFortran fails on read when delimiters are missing. So perhaps GFortran is also in violation here.

@marshallward , thanks for the quote on input. I was mistaken in saying that it is standard-conforming for a NAMELIST character sequence to not be delimited; that Intel accepts this is an extension (documented as such.) So gfortran is correct to reject such input.

This is fallout from the early days of NAMELIST (IBM had it first, I implemented it for VAX FORTRAN in 1979) where the notion of delimiter modes was nonexistent, and you typically didn’t want delimiters in list-directed output. (See also my Doctor Fortran in “The Modes, They are A-Changin’” - Doctor Fortran ( )

It would have been best if, when NAMELIST was formally added to the standard in F90, it had been specified that delimiters were always output for NAMELIST. I don’t know if it was considered (though one would then need a separate way to specify WHICH delimiters were to be used.)

1 Like


The motivation is for the code to spit out ALL parameters (since reading the input file as a namelist allows the user to supply a subset of parameters) so that the user can know what exact parameters were used for the run. Since there are hundreds of parameters and the code is under constant development, we do not want to have to fix the formats for each one hard-coded.

The namelist gives great flexibility, but reading the output of writing the namelist is pretty bad.
In our case, we have many 256 long character arrays that “can” be specified, so in the namelist output there are TONS of blank space.

I suppose we could write the namelist and then re-read it and strip out the spaces but it seems to me that the namelist in Fortran has such potential and seems to not be discussed or used often anymore?

Some kind of standard write output format (or preferably some high-level format options - such as “do not print trailing spaces in strings”) would be really helpful.

  • Ron

@sumseq ,

I agree with your sentiment re: NAMELIST entirely. NAMELIST can be so useful but unfortunately it seems to get less attention than it deserves. And with a little bit of extra work on it in the language standard, it can be JSON-like (or JSON-lite) and it can provide great benefits in simple and convenient exchange of information (data) between users and programs and also among programs.

Please see this link at the GitHub site for Fortran proposals where @marshallward above had started a related thread:

You may want to consider posting your own proposal(s), or collaborating on others such as those by @marshallward , or lending your support and comments / feedback to them.


Is there any “classification” to these “hundreds of parameters” and are they grouped together in any manner, say with object-oriented design in terms of “classes” iaka as derived types in Fortran?

By some such organization, you may find it easier to handle the input and run data communication with users.