Modify the inputfile creation to make it more flexible

[aiidaplugins]

Modify the inputfile creation to make it more flexible

[JPchico]

The first thing that must be done is create functions to write certain input "blocks".

• The basic control block, should be placed in the input before any other control block. It should accept the following LAMMPS keywords:

  • units (required, if not given by the user, a default will have to be given)
  • newton (optional)
  • processors (optional)

• The structure block, should contain the information that describes the structure, the following LAMMPS tags should be accepted:

  • box tilt (by default it should be set to large, but can be overwritten by the user, could it be perhaps determined by the structure?)
  • boundary (should be gotten from the orm.StructureData)
  • dimension (should be gotten from the orm.StructureData)
  • atom_style and read_data (the orm.StructureData should be written in a LAMMPS compatible format, and the file name should be given here)

• The potential block, should include information needed to describe the potential information. If one modifies the aiida-lammps potential data type many of these factors could be passed to the input as attributes of the data node. The following keywords should be present:

  • pair_style (either given by the user or auto-generated from the input potential, if one modifies the potential data type this could be one of the attributes)
  • pair_coeff (for some potentials the data needs to be passed directly instead of being read in a file, this means that depending on the type of potential either a set of values or a potential file needs to be passed).

• The compute block should contain as many of the compute options options given by LAMMPS.

• The simulation block should contain information about the MD simulation itself, time steps, number of steps, temperature etc.

Probably one needs to make a more narrow division in the simulation block, as probably different control options are needed for relaxation, pure MD and minimization.

[JPchico]

I was working on the "fix" block, which would deal with the fix options from LAMMPS, and how they can be set into the input. And I was thinking that the user could pass the parameters, into a dictionary in the following way

    parameters_fix = {
        'box/relax':{
            'group':'all', 'type':[{'keyword': 'tri', 'value':1e-3}, {'keyword': 'couple', 'value': 'none'}]
        },
        'brownian':{
            'group':'all', 'type':[100, 1.0, {'keyword':'rng', 'value':'gaussian'}]
        }
    }

Each "fix" as defined in the LAMMPS input is a key in the dictionary, whose value is a nested dictionary that contains the group option (to which subset of atoms the fix will be applied) then the "type" of fix is passed as a list, whose entries can be dictionaries with key value pairs and/or single entries. The key value pair makes sense for a lot of of the entries, as usually that is how they are setup in LAMMPS. However, the capability of passing single values is also provided as some inputs do not follow this key value approach, instead the value is just passed directly to the "fix".

This would mean of course that the user would need to know this, however, this seems like a reasonable assumption since the LAMMPS documentation explains how each input has to be passed.

A dictionary such as this would allow the ix strings to be written with a simple function

    fix_string = ""
    for key, value in parameters_fix.items():
        fix_string += f"fix {key.replace('/','_')}_aiida {value['group']} {key} "
        fix_string += " ".join([f"{entry['keyword']} {entry['value']}" if isinstance(entry, dict) else f"{entry}" for entry in value['type']])
        fix_string += "\n"

which produces a LAMMPS compatible text block

fix box_relax_aiida all box/relax tri 0.001 couple none
fix brownian_aiida all brownian 100 1.0 rng gaussian

The names for each fix are auto-generated, so that of that way they can be recreated in other parts of the input is needed.

As far as I know there is no need to keep the order in mind when one is generating the keywords, if this is important the issue becomes much more complicated (this is what can happen in the compute and one needs to be careful).

What do you think @chrisjsewell ? Do you think this is a good solution for this part?

[JPchico]

One issue with the flexible input file generation is also how to discriminate the computes and fixes between global and local since they have to be printed in different files, thermo and dump respectively. To solve this issue a helper json file with information from each of the quantities that can be printed in lammps is added to the code, of this way when generating the string to print the calculation the plugin will know whether the quantity should go to thermo and or dump.

The json file also stores the size of the vectors so that the headers can be properly written, this should help with the parsing of the output files. However, there are some variables which are either not well documented and/or the sizes are dynamical so getting their size before hand is not possible.

[JPchico]

Closed via #35