Bring Command Line arguments up to minimal expectations

[PDoakORNL]

Describe the bug

• [ ] Conform to basic linux standards i.e.
• [x] --version gives version
• [ ] --dryrun remove
• [ ] --help provides help for all official options
• [ ] --gpu fatal error
• [ ] Die if options aren't consumed or have unparsable arguments
• [ ] Always print version, commit hash, citation notice.

35 discusses this but mixed with output and is not an issue that can be finished.

Expected behavior As above

System:

• system name [e.g. fusiont5, summit]
• modules loaded [e.g. output of module list]
• other systems where this is reproducible [e.g. "my laptop", "none"]

Additional context Add any other context about the problem here.

[ye-luo]

"Conform to basic linux standards i.e." what do you refer to specifically? My request will be one hyphen for a single character (-h). two for a word (--help). I would die '--gpu' option, it was introduced for legacy CUDA but broken. Instead input control should be used.

Could you add more details so we can take action accurately and quickly?

[PDoakORNL]

What the standard is is open to discussion. But more or less as you say @ye-luo.
Some combination of gnu guidlines and POSIX

[prckent]

Good topic.

A request: currently if the qmcpack executable is run without arguments, we print (1) the rank and free memory (2) "No input file given", (3) Usage: qmcpack <input-files>. Notably missing is the version of the application, git hash etc. My suggestion would be that we always print the version header that we print to standard output at the startup of a typical run. (The formatted "QMCPACK v1.2.3, git hash, please cite..." part). And if the other improvements listed above are made, we could default to printing the --help.

AFAIK there is no consistency at all in --option and -options. e.g. cmake and gcc do different things. We could support one or both - the latter is a bit more user friendly.

I agree with Ye on abort if --gpu is specified

I don't know if --dryrun even works or if anyone is using it today. I worked at one time but is certainly untested and a bit of an edge case. I suggest to remove it. If anyone objects, they have to convince us it is really worth it and then gain the responsibility to write the test cases that we can run in CI :-)

I'll note that there is lots of output cleanup still needed, and I think there is an issue on it started by @markdewing a couple of years ago. Printing less useful-only-to-developers information at the standard verbosity level would be a start.

[PDoakORNL]

for handling "long options" --option using a single dash -option is not compatible with posix style -xzf style single letter options and as far as I can tell cmake does not support that. -fno-whatever and -Wvendor-option are special cases at least -Wvendor-option is covered by posix. Currently we require --option I'd say stick with it.

--option=value or --option value I think many command line executables support both that I think we can do with little effort.

35 is @markdewing's output cleanup issue and is still valid, I just wanted to split this issue off it.

[lshulen]

A comment on the history of --dryrun. This was very useful in the past before we had workflow systems. Paul has commented recently on how difficult it can be to create a working input file by hand. The point of the feature was to let a user see what the QMCPACK thought the input specified, rather than having to wait for queueing etc on a cluster.

Now that workflow systems make the process of generating a proper input file more foolproof, I have no issue with it going away. If at some point in the future we found lots of users wanting to build their input files by hand or if determining the required memory for calculations becomes difficult, that would be the time to consider reintroducing it.

[prckent]

Thanks for the background Luke. Agreed we could add it back if needed.