clarify command line options

[teuben]

I found the output of "exp -h" potentially confusing. Are the -c and -f flags the same, but in addition, you can also just leave it off it seems. The latter in particular will make it hard to have future expansion (which I took from the athena package) where you can conveniently override config parameters, and is also not well shown in the usage output:

Usage:
  exp [OPTION...]

for example to make re-use of a template config file possible, one could allow a series of keyword=value argument:

    exp -f myconfig.yml   nsteps=100000 outdir=run2 

this still bypasses the fact that nsteps and outdir are part of Global: or Components: etc.

[teuben]

I guess if nsteps= is unique in the yaml, accept it,other complain and don't allow it?

[The9Cat]

Yes, the -c and -f were for backward compatibility with (much) older versions of exp. The no flag default was a user request some time back.

Overrides of YAML parameters are possible to implement, of course. Especially for global parameters, in principle, one could specify the precise YAML on the command line for any bit. exp used to work this way, but I found myself overusing the feature and ended up confused. So I ditched the whole thing. It would be possible to reinstate it it the future.

Let's see if others have comments on this.

[michael-petersen]

It probably does make sense to clean up the backward compatibility. I'm sure no one is using these anymore, apart from perhaps to check the version/git hash after a compile.

For command line options, I think most users would probably solve the override problem by having Python generate YAML (one of the great strengths of YAML!). Of course that's probably just the primary use case, and I could still perhaps envision people wanting to override specific inputs.

I think my preference is to push users towards generating YAML files (even temporary ones) to manage overrides, as we might otherwise end up with more custom code to manage.

[The9Cat]

I'm happy to get rid of -c or -f. The original mnemonic was -c for config and -f for file. Maybe I like -c slightly better?

As for building the functionality in the exp parser, I'm less in favor. Both because I find it confusing to have both, albeit convenient in some use cases, and because of the extra maintenance.

For people who really wanted this functionality, it would be easy to write a Python driver that eats a YAML file and replaces additional command line options with key=value pairs, writes a temporary YAML file and then calls exp. One would parse the command line to keep everything before the appearance of exp as options to pass to the shell (e.g. mpirun -np 4 ... exp), find the -c my.yml and everything after my.yml would be interpreted as key=value options.