Reorganization of computational project plugins
One of the points that we can tackle when moving into data
and the use of Base Sections #1728 is the re-organization of the projects in NOMAD for parsers. Here, we should think of a more intuitive picture for grouping parsers, possibly related to methodologies or physical insights on what each plugin is parsing.
The current structure is (note I am leaving out the nexus
project):
atomistic
database
eelsdb
electronic
workflow
I think right now it is not very clear what these projects contain, and we talked some time ago about re-organizing them. Feel free to give suggestions, but here is a tentative organization I was thinking of.
My suggestion is that we organize parsers roughly by properties that are being extracted, or methodologies used when the first is not possible. We could be more verbose on the name of the projects. Here is my suggestion:
-
electronic-structure-calculations
: any code that outputs electronic structure properties such as band structures, dos, electronic responses, etc. E.g., VASP, exciting, QuantumESPRESSO, FHI-aims. -
phononic-calculations
: any code that outputs phonon dispersions and electron-phonon coupling properties. E.g., phonopy, FHI-vibes, EPW. -
molecular-dynamics
: any code that outputs MD properties. It might also mean FF calculations. Somehow this and the next project could be grouped or split further. E.g., GROMACS, LAMMPS. -
structural-calculations
: any code that outputs structural properties such as elastic tensors. These could maybe be grouped with the project for MD in a more generic name? I am not very convinced about this project, as I only saw ElaStic to add here. -
workflow-managers
: any code that manages workflows and outputs properties. I think it can be simplified to "any code that has the word workflow in its documentation". -
databases
: databases parsing. E.g., AFLOW, OpenKIM.
I'd say that the most complicated cases are the ones that output several properties, but for these, we could go with the main usage and clarify in the parser that it could belong to other categories.
I also think that these could be easily extended, e.g.:
-
spectroscopic-properties
: QuantumESPRESSOXSpectra, MsSpec. -
transport-properties
: ShengBTE, elphbolt.
What about other properties, such as bio simulations (e.g., GROMOS)?
So, what do you think? Do you think this organization makes sense, or something is missing? I think @ladinesa you can tell us much more in detail if you have something in mind, as you are the main expert of parsers.