Ability to specify an `override.yml` in command-line

[zooks97]

As Samuel and I are working to understand why Abinit is giving different results from everyone else, it came to me that it would be nice for testing now and in the future to take an override input file in the command line.

This way, running from the command line gives the ability (while not at all being necessary) for developers and power-users alike to easily override the protocol and change whatever underlying workchain / code inputs they like.

This could possibly look something like: aiida-common-workflows launch eos -S Al -p moderate -o abinit_override.yml abinit

$ aiida-common-workflows launch eos -h
...
Options:
...
 -o, --override FILE_PATH
                       Provide override inputs for the specified calculation
                       engine in YAML format

[sphuber]

The problem wouldn't be to add this to the CLI though, but how to pass this down to the generator. Currently there is no input in the common interface to accept overrides. Also, your implementation may use a .yml file, but not all generators do this. For this to work you would have to agree on a common interface first for doing this. Mind you, I have implemented this functionality in aiida-quantumespresso which exactly the idea of a user being able to provide a custom protocol.yml file with custom values and overrides. Making this general and piping it through the common workflow interface is another step though I would say

[zooks97]

Currently, it looks like all but bigDFT and Gaussian use .yml files for specifying the protocol. My suggestion is just to take in a file of the same internal structure and internally merge it over the default protocol.

I see your point though that not everyone will have their generator logic structured in a way that this would be simple, so maybe I'll implement something locally for Abinit for testing purposes, and we can leave it on the table for the future.

[sphuber]

Unless we want to formally standardize the input generator interface to have to accept this override argument that allows one to override values in the used protocol, I would vote to close this.

That being said, I want to raise the point again that this assumes that each generator implementation uses the concept of this protocol file with fields. This might not always be the case and I am not sure we should want to enforce this. One could say that the alternative is that overrides does not override particular fields of a "protocol" schema, but merely overrides explicit inputs in the generated builder. But in that case one can simply override the inputs directly on the builder once it is returned by the input generator and we don't need to complicate the interface for this.