-
Notifications
You must be signed in to change notification settings - Fork 32
Home
In this page the aiida plugin developers can find all the guidelines to join the project. Also, we collect here the summary of the decisions we took during meetings and exchanges in the issues section.
The aim of the project consists in achieving a common interface for different codes to compute in an automated way common materials properties.
For a specific task (for instance the relaxation of a structure), we agree on the API of a "builder factory" (named for instance following the pattern <Code><Task>InputGenerator), i.e. a python class that is able to return an AiiDA builder containing the required inputs to submit an AiiDA process (typically a WorkChain) computing the property. With API we mean the name and signature of the methods that this "builder factory" has and its expected inputs. In other words, a line of the kind:
input_generator = <Code><Task>InputGenerator() builder = inputs_generator.get_builder(par1, par2, ..., protocol="protocol_name", ...)
should return a builder for an AiiDA process able to complete the task <Task> and the SIGNATURE OF get_builder (indicated in the example with par1, par2, ...) MUST BE THE SAME for each <Code> (given a <Task>). Among the inputs we agreed to have the protocol. A protocol groups operational parameters for a <Code> calculation and it is meant to offer a set of inputs with the desired balance of accuracy and efficiency. We indicatively agreed to have at least 3 protocols: "fast", "moderate" and "precise". The specifications of each protocol are entirely up to the <Code> and they might change according to the <Task>.
In addition to a method get_builder, the class <Code><Task>InputGenerator has additional methods, for instance to return information about the possible protocols available for the specific task. Rationale: one of the goals of this <Code><Task>InputGenerator classes is to be used to automatically generate GUIs. The GUI is specific to the property (e.g., one for structure relaxation, one for bands calculations, ...). However, given a task (relaxation, for instance), the GUI should be autogenerated for any <Code> implementation. Therefore, for instance, we define methods to get the list of valid protocols that the calculation accepts. The available protocols can differ between implementations, but the way to access the list must be the same for each code.
Finally, the AiiDA process to be run (whose builder is return by get_builder) should return standardized outputs among different codes, for a specific task. For instance, in the case of the relaxation of a structure, all should return a StructureData node, with an output return link labeled relaxed_structure, with the final structure obtained after a relaxation.