Closed janssenhenning closed 2 years ago
The idea I now have is more scaled back not messing with the builder but providing a contextmanager to add inpxml_changes to dictionaries directly
Sketch in 6f80f1f67cbf5cf3b5b442cf9335d6fff1bd1020
Closed with #171
All of the workchains take the
inpxml_changes
entry in thewf_parameters
to modify the input at one/serveral fixed point(s) in the workchain.This is nice but it comes with some additional burden compared to working with the
FleurinpModifier
directly since it has to be constructed in a more complex syntax (see below)Example of setting up noco+soc plus setting one magnetic direction
vs.
The first example has several disadvantages:
Since the
inpxml_changes
is the main way of interacting with theFleurinpModifier
in higher level workchains there should be an easier way to construct this input utilizing the methods on theFleurinpModifier
directlyOne idea would be to allow initialization of the
FleurinpModifier
without a FleurinpData essentially transforming it into a builder of something like theinpxml_changes
inputThen an even more high level way could be create a subclass of the
ProcessBuilder
from aiida that provides a method that could be used like thisThe question with this is how this should interact with specifying the
wf_parameters
input directly. I also don't know how feasible/supported it is to subclass theProcessBuilder