`PwParser`: Fix trajectory verification for `fixed_coords`

[mbercx]

Fixes #792

For relax and vc-relax calculations, the PwParser does an extra check on the TrajectoryData output to see if the structure has been properly converged. However, when comparing the final forces with the threshold, it does not consider that some site coordinates may have been fixed with the fixed_coords setting.

Here we extract the fixed_coords setting from the PwCalculation inputs, and pass it to the verify_convergence_trajectory function. This has been adapted to ignore forces for fixed coordinates by setting the corresponding forces to zero before comparing them with the force threshold.

[mbercx]

@sphuber will add a test once we agree on the implementation!

@Sokseiha I already manually tried to parse the output files you sent me, but perhaps you can try to run another (cheap) example with the PR branch to see if it all works as expected?

[mbercx]

@sphuber have added some more explanation regarding the fixed_coords numpy magic and moved some checks into a validator instead of raising errors during the preparation for submission.

Note that since the structure isn't there for the PwCalculation when it is excluded in a higher-level work chain (e.g. in the PwRelaxWorkChain), the validation for checking that the number of sites matches the number of fixed_coords lists is only run if the structure input is there. So I still left the same check in the preparation step as well. I suppose it's still better for the work chain to except than fail because of bad inputs.

[mbercx]

Pre-approving but if possible would still be good to verify this works in real example with @Sokseiha

I'm still testing + adding tests! And actually found some bugs, so good thing too ^^

[mbercx]

There, now she's ready for another review. I've added tests for both the input file generation and the parsing (relax and vc-relax`).

[mbercx]

@sphuber still found a flaw in the current implementation (i.e. the parsing expected fixed_coords lowercase) and added a test. @AriannaCantarella maybe you can give this one a test for your hydrogen restorer work chain?

[mbercx]

@sphuber: As a side note: what should the "best practises" for validator methods be? i.e. do you agree with the following:

1. We add them as a classmethod or staticmethod on the process class they are validating the input ports for. Although those that do not use the cls could also be added as separate functions defined before the process class, I think the validators are typically directly tied to the class anyways and it is tidier to have them all in one place.
2. We do not add them as hidden methods, i.e. they are not prefaced with an underscore _. Although it is rare to call the validators outside of the class, one could potentially think of a use case for this, and most of the methods defined on e.g. a work chain class are rarely called outside of the class, save for e.g. testing.

[sphuber]

@sphuber: As a side note: what should the "best practises" for validator methods be? i.e. do you agree with the following:

1. We add them as a classmethod or staticmethod on the process class they are validating the input ports for. Although those that do not use the cls could also be added as separate functions defined before the process class, I think the validators are typically directly tied to the class anyways and it is tidier to have them all in one place.
2. We do not add them as hidden methods, i.e. they are not prefaced with an underscore _. Although it is rare to call the validators outside of the class, one could potentially think of a use case for this, and most of the methods defined on e.g. a work chain class are rarely called outside of the class, save for e.g. testing.

I agree on both points. I also add validators as public class methods or static methods

[mbercx]

@sphuber this has been tested in the field by @AriannaCantarella. If you could give one final sign off on this one I'll then rebase https://github.com/aiidateam/aiida-quantumespresso/pull/818 and we can merge that as well.