Handle situations when pre-digested structures are required.

[bosonie]

The common interface built in this project is based on the signature of get_builder that is common for every plugin implementation. For the relaxation task, among the arguments of get_builder, there is the structure to relax. While the structure is usually untouched by get_builder, there are situations (often due to plugin specific peculiarities) when modifying the structure would be useful. At least two cases come to mind:

• In order to run antiferromagnetic calculations, QuantumEspresso requires to have different kinds for spin-up and spin-down atoms (even if they correspond to the same element).

• When the relaxation of a molecule is performed, some codes would benefit from the definition of a cell with a lot of vacuum, while other codes might show a degradation of performances if the cell is too big.

Of course users knowing in details the code they want to run, can just change the structure in advance and pass to get_builder the correct structure. However the aim of this project is also to offer a tool to less expert users and allow to automatically run relaxations on the same structure with different codes.

Solutions to the problems might be:

• Allowing get_builder to modify the structure and return it as an unstored structure. In this way the connection between the relaxation and the original structure is lost.

• Allowing get_builder to modify the structure through a calcfunction and returning a builder with a stored structure.

In both cases we would need to agree on a "standard" for structures and have ONLY SOME plugins to implement the proper modifications in get_builder.

[broeder-j]

Other use cases are:

• Films: semifinite, single slab, repeated slab, different vacuum sizes, with all combinations of pbc. (fleur expects the 3rd component to be orthogonal to the film plane.)
• Structures, with vacancies, partial occupations, mixed occupations or X-elements in (methods like KKR needs these for explicitly empty spheres), kinds with weights.
• Structures with not only single atoms at Sites.
• Large structures, i.e 1000 + sites

I come more and more to think that the proper way for the code is to reject things (or at least issue a strong warning) which are not in the right 'format' and keep the responsibility on the 'user' side. But provide the user with tools to convert/prepare 'Structures' in the different ways and document well what will work and is expected. If we have these common tools, certain input builders might auto deploy them. Then it would still be something 'common', but certain 'converters' will be only needed by certain codes.

I think this is important, because:

1. It should be transparent to the user what happens and how things are supposed to be used. 2.We want the common workflows to give results which are meaning full in the end and to build trust on the user side and not just run everything in some way one can input in them.

The general problem here is how to deal with the fact that a common workflows allows of course for a much wider set/space of inputs as any of the specific code implementation support.

In other cases (relax, types, magnetism) we with have decided on 'Types' and sometimes defined a minimum set of a 'Type' which needs to be supported by a code to implement a common workflow. So maybe annotating a structure with 'bulk, film, 1D, molecule' might help, since pbc alone seems to be not enough for this. Then the common-workflow can define how these are allowed to look like (we could say that the pbc defines this for the common workflow, i.e we do not allow a molecule to be given with pbc (true, true, true) and a vacuum, box.). And the code specific implementations can decide if they want to support it and how, but it is clear how these structure types look like when they are given to a common workflow. This of course requires the inputbuilders to change the StructureData, which provenance should not be lost.