Skip to content

Parser output specification for plane wave codes

Espen edited this page Jan 25, 2019 · 14 revisions

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.
  • 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 the phonon_bands, but sometimes we only need phonon_bands or phonon_displacements. Suggested name for set_array: array
  • 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 and initial 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).
  • stress - The stress in the system.

    • Similar comments as for forces. Suggested names for set_array, similar to forces.
  • dos - The density of states of a system.

    • This is in principle something we could calculate in AiiDA from electronic_bands or phonon_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 of set_array: total for the total density of states (and inside this we store energies, total and partial) for non-spin polarized, while up and down.
  • 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)