Namelists - input.nml considered harmful

[hkershaw-brown]

DART namelist file is hardcoded as input.nml

• All namelists are in one file
• Other programs (e.g. MOM6) also have a file input.nml
• If you want to run a program on with different input.nmls you can't do that in the same directory, e.g. a bunch of pmo runs.
• Repeated /nmls in a file can be tricksy
• all namelists are compulsory (except KDE which is the first optional namelist in dart) -> big file, lots of stuff you don't care about, or worse do care about but don't notice.

Throwing some thoughts out there:

• namelist file as argument to program
• one namelist x_ml per file
• construct a namelist file from a (arguably) more user friendly format.

[enrico-mi]

Adding that input.nml is hardcoded to be read from the working directory, not from the directory where the executable is (at least for perfect_model_obs).
So a workaround for running a bunch of pmo runs on different nmls could be to launch the program from different directories with each its own input.nml. This might be ok for a user multitasking a few things, but would get ugly pretty quickly for complex workflows and parallel calls.

• namelist file as argument to program

I think something of this kind would improve flexibility a lot.

[nancycollins]

several times i wanted to use dart routines in standalone utilities (e.g. the time manager routines), but requiring an input.nml in the current running directory made the utility useless. i experimented with a version of the utilities_mod.f90 that had a routine to set the option to NOT require an input.nml. the result ran, but you did have to worry about how to set the options you wanted which would have been set by the namelist (e.g. the calendar type from the time manager namelist, the error status level from utilities namelist, etc). i think having an alternate here is generally useful beyond the crocodile needs.

i don't know if my try at not requiring an nml file is the right solution - perhaps being able to name the namelist file and putting it in any directory might be enough. e.g. my "print_doy" program could live in my own ~/bin directory, and always use ~/bin/print_doy.nml as its namelist. (i don't know about current fortran compilers, but i believe older ones had problems with using files in other directories so that could be an issue with this approach.)