Picongpu: command line parsing

[psychocoderHPC]

Currently we use boost program options to parse command line parameter.
It is not possible to create hierarchical groups with boost program options.
For multi plugins this has a few negative side effects:

• it is not possible to use options without an argument e.g. --enable_compression
• if a plugin is written as multi plugin than explicit passed optional parameters will always passed to the oldest created plugin where the optional argument is not defined. e.g.
   Command line parameter can be used multiple times to create e.g. dumps with different dumping period.  In the case where a optional parameter with a default value is explicitly defined the parameter will be always passed to the instance of the multi plugin where the parameter is not set. e.g. ``--hdf5.period 128 --hdf5.file simData1 --hdf5.period 1000 --hdf5.file simData2 --hdf5.source 'species_all'`` creates two plugins:  - 1th. dump **all species data** each 128th time step.  - 2nd. dump **all fields and species data** (this is the default) data each 1000th time step.

possible Solutions

• change the command line parser
• pass options for the plugin as a single string to the plugin e.g.

--hdf5 "--period 128 --file simData1" --hdf5 "--period 1000 --file simData2 --source species_all

[theZiz]

The second "solution" is awful!

[ax3l]

I think we should go for the following for our RT parameters:

• only expose very fundamental parameters such as -g, -s, -d, maybe --periodic to the command line
• expose all other only (and the above fundamental!) cmd line options via hierarchical config files (note: boost program options' config files are not hierarchical but just flat groups), e.g. yaml (read in and broadcasted by the master rank for scalability; type safety can be problematic) or dhall

As always, a cmd line arg will overwrite a config file arg for the (few!) fundamental command line options.

This is useful, since a cmd line is generally not flexible/clear/well-defined enough for our simulation (plugin) options, e.g. when it comes to default values of optional arguments in multi-params. Users interface with PIConGPU via config files anyway (e.g. cfg). For quick and dirty tests & execs, the few fundamental parameters are enough.

We can then check if we even need the !TBG functionality from cfg files in yaml files for our RT options (which natively supports references but maybe no more complex math syntax) or if we still need to stay in the tbg-cfg scope for user input interaction. but for plugins (non-fundamental options, see above) we never did more than simple string concatenation anyway in the cfg, so yaml will do. Also, we can write python interfaces if needed for the yaml generation as well, covering all cases a cfg file does right now for the user input and allowing to reduce tbg for pure usage of batch system abstraction.

[ax3l]

CLI11 is a stand-alone, modern, amalgamated header if needed, library that supports subcommands (blog, tutorial). It also supports INI files.

This looks like a great alternative to Boost.ProgramOptions for a C++11 code base like ours.

Still, we should stick to the strategy long-term to

only expose very fundamental parameters such as -g, -s, -d, maybe --periodic to the command line

[ax3l]

As noted here, this is related to generalizing out input towards a simpler and abstract interface such as PICMI.

(See an early LWFA example.)