PwRelaxWorkChain: Move RelaxType input to get_builder_from_protocol

[mbercx]

Instead of having the Relaxtype as an input of the PwRelaxWorkChain, it
would be better to properly separate church and state by making it an
input of the get_builder_from_protocol method. Based on the chosen
Relaxtype, this will properly populate the builder of the
PwRelaxWorkChain.

Second, currently for RelaxType.NONE, the PwRelaxWorkChain fixes
the atoms using the if_pos inputs explained explained here:

https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm1094

and then run a 'relax' type calculation. This leads to issues with
all calculations raising ERROR_IONIC_CONVERGENCE_NOT_REACHED
exit codes from the parser.

Instead, here we set parameters['CONTROL']['calculation'] = 'scf' for
RelaxType.NONE in the get_builder_from_protocol method, since
this "relaxation" type really corresponds to a static calculation.

Besides this, we also:

• Make sure the PwRelaxWorkChain only runs 1 PwBaseWorkChain for
  RelaxType's NONE, ATOMS and SHAPE. I.e. meta convergence is
  turned off.
• Make sure we do not run a "final_scf" when 'calculation' is set to 'scf'
  for the PwBaseWorkChain that does the relaxation.
• Make sure we don't run into an error in the results step of the outline
  when running with 'calculation' set to 'scf'.

TODO

• Ask @sphuber if we really need to be able to disguise static calculations
  as PwRelaxWorkChains.
• Give this work chain logic another hard look and see if it can't be simplified.
• Add more tests for these RelaxTypes and the work chain logic.
• Test all of the RelaxTypes and make sure we don't run into more errors.

[sphuber]

Thanks @mbercx . Have a couple of suggestions

[mbercx]

Alright, @sphuber, I made the changes and already took a soft look at some of the logic. However, I'm left wondering why we treat the RelaxType different from the SpinType and ElectronicType. Most of the RelaxType logic can be moved into the get_builder_from_protocol method:

• Setting the correct pw.parameters['CONTROL']['calculation'] and pw.parameters['CELL']['cell_dofree'].
• Setting the meta_convergence and final_scf inputs.
• The RelaxType.NONE logic can also be included by instead looking at the pw.parameters['CONTROL']['calculation']. If this is set to 'scf', then we won't have an output_structure for the one and only PwBaseWorkChain, but we can deal with this in the logic of the work chain.

What do you think? Is there anything I've missed?

I think right now it's a little confusing that the RelaxType has to be passed as a Str to the inputs of the PwRelaxWorkChain, but the SpinType and ElectronicType have to be passed as an argument to the get_builder_from_protocol method.

[sphuber]

Two minor things

[mbercx]

Alright, @sphuber! As per our discussion, I've properly separated church and state by moving the RelaxType from an input of the PwRelaxWorkChain to an input argument of the PwRelaxWorkChain.get_builder_from_protocol method. I've done some testing for the different RelaxTypes, and everything seems to be working as expected:

• Input parameters and settings look good, and are now tested in workflows/protocols/pw/test_relax.py.
• The work chain only uses meta convergence when the volume can change i.e. as long as calculation isn't scf or relax, and cell_dofree isn't shape.
• If calculation is set to scf, the work chain doesn't run the final scf.

Let me know if I should reorganise the commits somewhat. Should we perhaps split this in two PR's? i.e.:

• running with calculation == 'scf' for RelaxType.NONE
• Move the RelaxType to get_builder_from_protocol.

[sphuber]

Thanks @mbercx . Looking good, just two minor comments.

Let me know if I should reorganise the commits somewhat. Should we perhaps split this in two PR's?

To be honest, I see two commits at most, but for me it would be good to squash them in a single one and simply describing well all the individual changes. Most of the changes should not really affect behavior of what was released.

[mbercx]

Uh oh! Copy Pasta! 😅

[sphuber]

I think this has still the capacity to fail now, no? I don't think it is guaranteed that ['CONTROL']['calculation'] or ['CELL']['cell_dofree'] exists. For the former, we should probably add a validator in the spec because the user now has to indicate the calculation mode (before we did it through the relax_type input). The second one is sometimes not defined and that is ok, so we should do something like self.ctx.relax_inputs.pw.parameters.get('CELL', {}).get('cell_dofree', None) == 'shape'

[mbercx]

Right, of course. 🤦

One issue with the validator is that the user might still use the relaxation_scheme input, and I don't think I can check if this input is provided in the validator of the base input? So the user might not provide the 'calculation', in the base input, but the relaxation_scheme instead.

[sphuber]

you can put the validator on the top-level namespace for now with a comment that once relaxation_scheme is removed, it can be moved to the parameters port. In the top-level you will have access to all inputs

[mbercx]

I've added the validator which checks if the base input has ['pw']['parameters']['CONTROL']['calculation'] specified. It might be a little confusing to a user that still relies on relaxation_scheme and doesn't specify the calculation input, but I maybe this is ok? Or is there an elegant solution to this?

[sphuber]

yeah, as my previous comment said, you can move the validator to the top level inputs which has access to all

def validate_inputs(inputs, ctx):
    """Validator for top level namespace."""
        parameters = inputs['base']['pw']['parameters'].get_dict()

        if 'relaxation_scheme' not in inputs and 'calculation' not in parameters.get('CONTROL', {}):
            return 'The parameters in `base.pw.parameters` do not specify the required key `CONTROL.calculation`.'

def define(cls, spec):
    spec.input()
    ....
    spec.inputs.validator = validate_inputs

Note also that you should not raise an exception from a validator but simply return a string with the error message

[mbercx]

Ah, it seems Github hadn't updated the comments when I replied to yours, sorry about that!