wfl's QE calculator with directory handling.

[gelzinyte]

Added a Calculator which extends ASE's espresso calculator to execute each calculation in a separate directory and handle parameters in awfl.caclulators.espresso.evaluate_autopara_wrappable way. Workflow's espresso calculator now can be parallelised with the generic.py.

@bernstei once I have taken into account your comments, I'd like to remove the dft.py & espresso.evaluate_autopara_wrappable QE interface and rewrite VASP and CASTEP in a similar way.

[bernstei]

@bernstei once I have taken into account your comments, I'd like to remove the dft.py & espresso.evaluate_autopara_wrappable QE interface and rewrite VASP and CASTEP in a similar way.

Do you mean comments I made earlier, or comments about this particular set of changes?

[gelzinyte]

I meant these changes in particular. Though on the second thought, it makes more sense to review everything in one go, so I have removed the previous QE interface.

About previous comments - I didn't implement reuse of run directories (you mentioned it in #17), I would leave that for another issue/PR. And I don't think there is anything that could be conveniently generalised for other wfl's calculators like this, but let me know what you think.

[bernstei]

I'll look over the changes, but do you know why the QE test is failing? The numbers are close, but not within the tolerance.

[gelzinyte]

The reference values were what I got on our cluster, but the values on github are different. I am updating the tolerance requirements, although I'm not sure if that's the best thing to do.

[bernstei]

The reference values were what I got on our cluster, but the values on github are different. I am updating the tolerance requirements, although I'm not sure if that's the best thing to do.

Forces are generally harder to converge than energies, and the specific values it'll converge to are likely to depend on architecture, number of cores, etc, so I'm not so surprised the tolerance can't be super tight.

[bernstei]

[edited] I guess the idea is that the calculate() itself calls setup_params_for_this_calc which makes sense. Let me think some more.

[bernstei]

[edited] I guess the idea is that the calculate itself calls setup_params_for_this_calc which makes sense. Let me think some more.

OK - I looked at generic.py more carefully, and I think the warning is fine (may not even be needed, but let's leave it for now). I'm updating the docstring.

[bernstei]

I just pushed a little fix to the import in dft.py. If it passes, I think we can merge.

[bernstei]

@gelzinyte do you think we should merge now?

[gelzinyte]

Thanks for looking through - do merge if the last unresolved conversation is ok with you.