Where we want to go

support for complex queries

1. use properties not in the RDB, full MD trajectories, wavefunction,...
   • map reduce queries
   • Flink
2. Have updated global informations that are expensive to calculate
   • connection between configurations "close" systems (neighboring list)
   • tags for special configurations (minima for a given calculation/method)
   • distributed responsive system
   • Flink (+ http://akka.io/ ?)

Supporting multiple codes

Describe Data of a calculation

• we want to be able to describe:
  • various properties calculated in a run
  • derived properties
• need unique way to identify a given property
• need to be able to trat similar properties in the same way
• the NomadMetaInfo is exactly aimed at solving this conundrum

NomadMetaInfo

• Wiki http://nomad-dev.rz-berlin.mpg.de/wiki/NomadMetaInfo

Not only parsing results

• derived quantites
  • BSSE corrected energies
  • comparable energy

Comparing Energies

• Total Energy
• MethodConsistentAtomizationEnergy: Total energy minus the energy of the same number of isolated atoms calculated with the same method (functional,...), basisset and accuracy.
• MethodConsistentFormationEnergy: Total energy minus the same number of atomic energies of the most stable form of the element calculated with the same method (functional,...), basisset and accuracy.
• FittedComparableEnergy: Total energy minus the an atom dependent contibution that depends on method, periodicity, basisset and accuracy, fitted so that the spread of the resulting binding energies is minimized.
• FittedComparableEnergyV1: First version of the fit of the total energy minus the an atom dependent contibution that depends on method, periodicity, basisset and accuracy, fitted so that the spread of the resulting binding energies is minimized.

Normalized format

• relationship between MetaInfo, and how to access it when stored in a given format should be specified
• currently two main standarized formats:
  • json (with extension .nomadinfo.json)
  • hdf5 (with extension .nomadinfo.h5)

• embeds description of the MetaInfo used

• Simple property
  • index: method, config, scfIter, sub iterations
  • value: multidimensional array

MetaInfo and parsing

• parser can output its results using a normalized format
• outputting all data looks slow -> possible to share parser between lab and repo?
• API interface (to be done):
  • set requested MetaInfo
  • write out values using a common interface (SAX like parsing?)

MetaInfo and querying

• MetaInfo can be used to access a property

Slowly open up the code

open git repo

• where
  • github offers nice collaboration tools, free for open source projects

  • registered the nomad-dev organization (an organization can have multiple people handling )

  • license for the code? possible open source licenses
  • BSD/MIT style (you can do whatever with the code even closed derivatives)
  • apache 2.0 (constraints related to patents, incompatible with GPLv2)
  • L-GPL (if you distribute a binary, then modification to the library have to be given back)
  • GPL (if you distribute a binary, then all application code has to be given back, might give issues when linking 3-rd part libs)

  • AGPL (if outputs of the binary are given out, all application code has to be given)

Improvements to the repository I would like to see

• common private git
• RZG?
• cleanup repo
• maven like directory structure
• remove dependencies from repo
• modular db
• unique human readable names: first.last_InstitutionShort or if email -> institution is unique emailName
• transition to more REST & template based approach

  • proposed url structure

    /userName > info on the user, list of datasets uploaded by this user /userName/datasetName > latest version of that dataset /userName/datasetName/YYYY-MM-DD-N > frozen version YYYY-MM-DD-N of the dataset