materialdigital/adis2023

Interactive comparison of the same quantum espresso workflow implemented in Aiida, jobflow, pyiron and simstack.

ADIS 2023

As part of the Ab initio Description of Iron and Steel (ADIS2023): Digitalization and Workflows workshop the developers of the workflow frameworks Aiida, jobflow, pyiron and simstack met and discussded their frameworks. During these discussions it became clear that while the naming and the extent of the implementation of certain components differ, there were also large number of similarities. To enable a more direct comparison of the different frameworks, the same workflow was implemented in all four workflow frameworks. These implementations are shared in this repository and are rendered as a jupyter book website. The examples can even be executed directly in the web browser using mybinder.

adis2023's Issues

Semantics

@mbercx @jan-janssen @JaGeo @schaarj

I started creating semantics.md. The definition of parser is more or less what @mbercx and I agreed on, but there are the following points I was not so sure about:

• An input parser does not return anything for file-based software
• What is an input parser supposed to do for python-based software (e.g. interactive LAMMPS)

And on top of this, we might have to make a distinction between requirements and recommendations.

By the way, obviously you are also very welcome to make changes there.

❓ Should we also implement an electronic band structure example?

The EOS workflow example already highlights various aspects of how the engines deal with certain aspects of scientific workflows:

1. Executing Python code.
2. Executing external code.
3. Connecting steps in a workflow.
4. Running multiple external calculations in parallel.
5. Waiting for long-running calculations before executing the next step.
6. Persistance.

And probably more. However, one aspect that isn't covered at the moment is restarts. I.e. what if the second calculation requires access to the full output files of the first?

A typical example here is a band structure calculation, where you would first run an SCF to obtain the charge density, and then an NSCF along a k-path. Quantum ESPRESSO loves working with restarts, typically running multiple different "codes" (it's a code suite, after all). Another example would be the DOS. For this you'd run:

pw.x (SCF) -> pw.x (NSCF) -> dos.x (post-processing)

and each restart requires (large) output files from the previous step. So I'm curious to see how other workflow engines specify parent directories, indicate that a follow-up step should wait for the previous, make sure the files are only cleaned up at the end, etc...

Another note: the next step in the verification project (after EOS) is also band structures, i.e. construct a common band structure workflow for various "quantum engines" (Quantum ESPRESSO, VASP, ABINIT, ...) and compare results.

Updated pyiron example

https://github.com/jan-janssen/quantum_espresso_pyiron_base

I moved it to a separate repository, so compare different implementations side by side.

Link to Hack.md

https://hackmd.io/3ERXUrWhSPOiEnH_PLF1iA