Parser output specification for plane wave codes
This is a document that will try to coordinate the output node naming and content for the plane wave codes.
A note: We should not strive to put all ionic/displacement/trajectory dependent variables into TrajectoryData. Possibly one is only interested in one of those quantities and then it makes no sense to store everything in the database. TrajectoryData could be used as a composite, taking links to the other datatypes. E.g. if several steps is done and all the other datatypes (not just StructureData) changes, i.e. KpointData one can store links to these. In general we could do this for most quantities.
Quantities of interest (might not be in the respective parsers yet):
-
kpoints
-KpointData
- The kpoint grid used.- Input grid/mesh for regular calculations (this is already present as KpointsData).
- Resulting irreducible kpoints.
- Including possible changes of the irreducible grid due to atomic displacements etc. (often handles as ionic steps). This is currently not a possibility and several KpointsData has to be used. These can however not be be stored in any other AiiDA data object. The only option is now to store the kpoints in custom ArrayData objects.
- Full k-point grids when special methods are used. E.g. we might want to store both the irreducible used for the regular calculation and another kpoint object for some special property. Now, these kpoints are stored in custom ArrayData objects, which contain both this kpoint grid and the quantities of interest. Again, there is a problem of not being able to store AiiDA data objects inside others.
-
structure
-StructureData
- The structure.- The input structure
- The relaxed structure
- Intermediate structure, or displaced structures etc. These can now reside in TrajectoryData.
-
parameters
-ParameterData
- Output parameters.- Any quantity that is not system or size dependent (except of course its value). Typically includes total energies, maximum force, stress, symmetry of cells, tensors etc.
-
trajectories
-TrajectoryData
- Trajectories.- Either this should be further developed to also support KpointData and other quantities or we need to decide it is strictly for structural quantities. If the latter, it seems unsystematic to also have say another object with all the KpointsData for each StructureData etc. A possibility is to add something similar to TrajectoryData that is a container for the other quantities, but why not use TrajectoryData? The definition of trajectory can be broad.
-
electron_bands
-BandsData
- The electronic eigenvalues.- Tempted to use eigenvalues, but there are so many different types of eigenvalues so this is probably not a good choice. Band is more restrictive, even in the broader sense.
- Contains the electronic eigenvalues and the KpointData on which they were calculated.
-
phonon_bands
-BandsData
- The phonon eigenvalues.- Similar structure to
electron_bands
. Contains the stuff from the dynamical matrix.
- Similar structure to
-
phonon_displacements
-ArrayData
- The phonon eigenmodes, or the eigenvectors.- Would somewhat be similar to the
wave_functions
, but again totally different. We could possibly put it into thephonon_bands
, but sometimes we only needphonon_bands
orphonon_displacements
. Suggested name forset_array
:array
- Would somewhat be similar to the
-
forces
-ArrayData
- The atomic forces in the system.- Again, should be able to contain forces for several sets of atomic configurations. This is in TrajectoryData, but sometimes we only want the forces. This is fine if TrajectoryData was more modular. Suggested names for
set_array
:final
for the final inter atomic forces,all
for all andinitial
for the first step.all
etc. should not be the default and should be enabled by another parser setting (that could possibly be general for all quantities).
- Again, should be able to contain forces for several sets of atomic configurations. This is in TrajectoryData, but sometimes we only want the forces. This is fine if TrajectoryData was more modular. Suggested names for
-
stress
- The stress in the system.- Similar comments as for
forces
. Suggested names forset_array
, similar toforces
.
- Similar comments as for
-
dos
- The density of states of a system.- This is in principle something we could calculate in AiiDA from
electronic_bands
orphonon_bands
so we should consider not storing this, but calculating it on the fly. However, sometimes this calculation is very costly. So we should probably store it. Suggesting names ofset_array
:total
for the total density of states (and inside this we storeenergies
,total
andpartial
) for non-spin polarized, whileup
anddown
.
- This is in principle something we could calculate in AiiDA from
-
charge_density
- The charge density.- A file link to a charge density file.
-
charge_density_all
- The all electron charge density.- A file link to a charge density file.
-
charge_density_core
- The core electron charge density.- A file link to a charge density file.
-
wave_functions
- The coefficients of the wave functions.- A file link to the wave function coefficients file.
-
wave_functions_der_X
- The derivative of the wave functions to order X.-
A file link to the file that contains some derivative of the wave functions coefficients.
-
Needed for linear response calculations.
-
We could possibly concatenate this with the
wave_functions
.spec.output('output_dos', valid_type=get_data_class('array'), required=False) spec.output('output_occupancies', valid_type=get_data_class('array'), required=False) spec.output('output_energies', valid_type=get_data_class('array'), required=False) spec.output('output_projectors', valid_type=get_data_class('array'), required=False) spec.output('output_dielectrics', valid_type=get_data_class('array'), required=False) spec.output('output_born_charges', valid_type=get_data_class('array'), required=False) spec.output('output_hessian', valid_type=get_data_class('array'), required=False) spec.output('output_dynmat', valid_type=get_data_class('array'), required=False)
-