Clean things up

[perrette]

The code has evolved from making a read/write namelist code from the namelist itself to a more complete fortran code parser that generate both the namelist and the I/O routines. I noticed that the really useful bit was to code parsing with 1) namelist generation and 2) I/O routines. It would make sense to refactorize the code a bit to make these steps more natural.

Old way

To illustrate that, here is an example of the current commands I use in a research code.

• create namelist params_default.nml from source code:

  f2nml src/*f90 params_default.nml --groups geometry dynamics --type-suffix _t  
  

• create src/ioparams.f90 from namelist (to know which types to search for) AND source code (not to rely on namelist parsing to determine individual variable types, and to include additional type control_type):

  nml2f90 params_default.nml src/ioparams.f90 --src src/*f90 \
  --type-suffix _t  \         #  map namelist block onto fortran types
  --include-groups control --type-map '{"control":"control_type"}'  \    # include a type not in namelist
  --io-nml --command-line   # features to include in ioparams.f90
  

New way?

It would be cleaner to have instead a single code parsing command that looks for the appropriate types, and provide additional information depending on the features to add. For example a new script ioparams that could handle several cases via a --to argument (supplemented by --fmt for ambiguous cases):

• parse source code and create I/O routine:

  ioparams --src src/*f90  --to src/ioparams.f90 --command-line --io-nml  $(TYPES)
  

• create the default namelist according to the source code

  ioparams --src src/*f90 --to params_default.nml  $(TYPES)
  

where $(TYPES) indicates the required input information about which types to search for in the code, and how to map it to namelist or command-line blocks.

In the current setting, you would define TYPES (in the Makefile) beforehand as:

    TYPES = --groups geometry dynamics control  --type-suffix _t   \
        --type-map '{"control":"control_type"}' 

Note that --groups + --type-suffix is a convenient way of mapping from groups (namelist block, command-line groups) to derived types to search for in the code, but this could evolve, too.

Perspectives

This new ioparams utility could actually build on other libraries and formats, like json-fortran (param file in json), flap (command-line) as is already the case with nml, each being a new feature.

So this piece of code is handy and has a potential to evolve. Just need to clean it up to make it more sexy and easy to use.

This will probably involve changing name, likely ioparams !