JuDFTteam / aiida-fleur

AiiDA plugin of the high-performance density functional theory code FLEUR (www.judft.de) for high-throughput electronic structure calculations.
https://aiida-fleur.readthedocs.io
Other
14 stars 7 forks source link

Provide declarative way of building `inpxml_changes` input #168

Closed janssenhenning closed 2 years ago

janssenhenning commented 2 years ago

All of the workchains take the inpxml_changes entry in the wf_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

[('set_inpchanges', {
                'changes': {
                    'l_noco': True,
                    'l_soc': True,
                    'ctail': False
      }
  }),
  ('set_atomgroup', {
      'species': 'all-Fe',
      'changes': {
          'nocoparams': {
              'alpha': np.pi/4,
              'beta': np.pi/2
          }
      }
  })]

vs.

fm = FleurinpModifier(fleurinp)
fm.set_inpchanges({'l_noco': True, 'l_soc': True, 'ctail': False})
fm.set_atomgroup(species='all-Fe', changes={
                                'nocoparams': {
                                    'alpha': np.pi/4,
                                    'beta': np.pi/2
                                }})

The first example has several disadvantages:

  1. The nested list/tuples/dicts make it very easy to do mistakes
  2. There is no way of utilizing any autocomplete

Since the inpxml_changes is the main way of interacting with the FleurinpModifier in higher level workchains there should be an easier way to construct this input utilizing the methods on the FleurinpModifier directly

One idea would be to allow initialization of the FleurinpModifier without a FleurinpData essentially transforming it into a builder of something like the inpxml_changes input

Then 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 this

builder = plugins.WorkflowFactory('fleur.scf').get_builder()

with builder.inpxml_changes() as fm:
    fm.set_inpchanges({'l_noco': True, 'l_soc': True, 'ctail': False})
    fm.set_atomgroup(species='all-Fe', changes={
                                'nocoparams': {
                                    'alpha': np.pi/4,
                                    'beta': np.pi/2
                                }})
#The inpxml_changes input is now constructed in the builder 

The 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 the ProcessBuilder

janssenhenning commented 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

janssenhenning commented 2 years ago

Closed with #171