Enhance attributes of codes?

[giovannipizzi]

Should we add additional (optional) attributes for codes, stored as attributes and not only as extras (as we suggest in #420 )?

In my opinion, for these we should have a clear idea and documentation of what they do.

An idea could be to have e.g. the md5 of the executable, and if it is present, the daemon adds to the scheduler script, before the execution, a check of the md5 - if it does not match, it exits. (Anyway, we should claim explicitly this is not 100% perfect, as the linked libraries can change, but at least we check if the user just recompiled the code and still wants to use it).

Any other options that are worth being added as attributes rather than extras?

Things that can be added (in the "private extras", see #2231)

• [ ] code executable MD5
• [ ] code version number (from #220)

[giovannipizzi]

This actually now should be in the aiida-reserved extras (like hidden). Discussion still open

[mbercx]

Not sure if this should be discussed here or a different (yet to be opened) issue, but something we were thinking of adding to the attributes/extras is the version of the code being run (e.g. in case of Quantum ESPRESSO: v6.8, v7.1 etc..). The main motivation for this is that some of the inputs need to be prepared differently for different versions, the most recent example being the hubbard U&V inputs that starting from v7.1 require a completely separate card.

A couple of options:

1. Ask the version of the code during code setup. The plugin could specify multiple supported versions, and then the version would be stored as an attribute. This would most likely break setup scripts though.
2. Add a verdi code test command that also quickly runs the binary. For QE the version can be extracted from the header.
3. Simply ask the user to add the version of the code to the extras of the code. This would have to be clearly documented, and in case something goes wrong when running the code the user should be pointed to this possible reason for failure.