Design decisions

This document collects decisions and open questions concerning the design of the code registry.

Templating mechanism vs duplication

There are certainly aspects of the computer setup that users of the AiiDA code registry will want to customize. We can vaguely differentiate two types of customization:

1. Popular "variants", for example corresponding to different scheduler partitions using #SBATCH --partition=.... Other aspects of the configuration may depend on the variant (e.g. mpiprocs_per_machine).
2. User-specific customizations, e.g. setting #SBATCH --account=... on the computer level in order to avoid having to specify the account for every calculation.

One could imagine solving this by introducing variables using a templating language, such as jinja, e.g. #SBATCH --account={{account}}. verdi computer setup and its colleagues would then need to detect these template variables and prompt the user for them. It may be possible and worthwhile to investigate this route, but it is also clear that it adds complexity by introducing another level of prompting & logic.

Single-file build of the registry

While the folder structure is a useful and simple way of organisation, it is not ideal when you would like to write a command line client or graphical user interface to help users set up codes from the registry (you'll need a local clone of the repository; traverse the directory structure, ...). Short of a fully fledged API, we can use CI on the master branch in order to build a nested yaml file that contains all configuration information in the repository.

The structure could be something like

---
computers:
  - directory: daint-mc
    computer-setup:
      label: ...
      prepend-text: ...
    computer-configure:
      ...
    codes:
      - label: ...
        ...
      - label: ...
        ...
  - directory: fidis
    ...

Sharing configuration information via AiiDA export files

Instead of sharing information on Computer and Code configurations through yaml files, as done here, one could also share them through AiiDA export files. E.g. the registry could use CI in order to build an AiiDA export file containing all computers and codes defined in the registry.

At first sight, this has the advantage that AiiDA users won't just have computers of the same name - the corresponding AiiDA entities (including the UUID) will be the same [1], which is useful information when trying to reproduce someone else's work.

However, in order to reap these benefits, users would need to use computers exactly as configured in the registry, which is probably not flexible enough for everyday use. Using the same names is, in practice, already a big step forward; and the built-in hashing functionality makes it easy to check whether the content of two AiiDA entities is in fact identical (even if they do not share the same UUID).

[1] One could try playing some tricks on the registry side in order to make sure that the UUIDs only change, when the actual computer/code configuration changes.