Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • nomad-FAIR nomad-FAIR
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 215
    • Issues 215
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 27
    • Merge requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • nomad-labnomad-lab
  • nomad-FAIRnomad-FAIR
  • Issues
  • #357
Closed
Open
Issue created Jun 09, 2020 by Lauri Himanen@himanel1Maintainer

Metainfo suggestions

Here's a few ideas for the metainfo workshop next week:

  • section_metadata refactoring: The idea behind section_metadata is to provide a "summary" of the entry contents that can also be easily serialized for ElasticSearch for performant searches. This section contains duplicate or derived information that is gathered by a normalizer from section_run or other sources. Here are a few key points that could be improved/refactored within section_metadata:

    1. As we are expanding from DFT to other domains (experimental, classical potentials, higher-order quantum methods, etc.) we could think about the top-level organization of section_metadata. Instead of doing a top-level division between these domains (currently section_metadata has subsections dft, ems) could we do a division that would better support cross-searches across different domains? E.g. introducing subsections for material, method, and properties? These subsections could share some common metainfo between the different subfields (e.g. information about crystal symmetry can be included within the material subsection), but also support subfield-specific data under corresponding sections (e.g. (section_metadata/method/dft vs section_metadata/method/ems)
    2. Could the information contained in section_symmetry, is_representative, section_prototype be moved as part of section_metadata?
    3. Information that summarizes the calculation type (e.g. geometry optimization vs. molecular dynamics vs. phonon calculation vs. single point calculation) is very hard to find within the current metainfo. section_encyclopedia now contains a relatively simple keyword for this (section_metadata/encyclopedia/calculation/calculation_type, but maybe this should be renamed and placed somewhere else? Maybe this metainfo could also be used for experimental data to summarize the technique?
    4. Could we introduce a metainfo that summarizes the used calculation methodology? Currently the method information can be found by combining information from all section_methods, but the referencing mechanism makes it hard to see the overarching methodology. E.g. providing a summary metainfo that summarizes the method is much easier to understand (and search) than navigating through section_methods. Of course, we still need to keep section_methods as they contain all the details.
  • Normalization: If I understood correctly, all extensive properties should be reported per the simulation cell? Related to this:

    1. The property vibrational_free_energy_at_constant_volume is reported per atom, should it be fixed?
    2. It would make sense to also report some of the values in a normalized form that can be directly compared between other materials, e.g. heat_capacity/specific_heat_capacity, dos_values/dos_values_normalized, etc. What would be a good mechanism for providing these values, how should they be named and is there some kind of default normalization we should use (e.g. per atom, per kilogram)?
    3. The normalized band structure energies and values should be reported under section_k_band, and section_k_band_normalized should be removed.
Edited Jun 10, 2020 by Lauri Himanen
Assignee
Assign to
Time tracking