Future: make `aiida-core` fully domain-agnostic

[mbercx]

Motivation

Since AiiDA started within the field of materials science, the core AiiDA package still contains a lot of data types related to this domain. There are several reasons why we may want to move these data types to a more suitable plugin package:

1. It would make the aiida-core package more domain agnostic, possibly promoting its adoption in other fields.
2. Over time, it's become clear that there are some design issues with the current implementation of several of the materials science-related data types. This would be a good time to redesign them.
3. Having the data types in their respective (much more lightweight) packages would make them easier to maintain.

Desired Outcome

This item will be resolved when the following data types have been moved to the corresponding plugin package:

• array.bands -> aiida-atomistic
• array.kpoints -> aiida-atomistic
• array.projection -> aiida-atomistic
• array.trajectory -> aiida-atomistic
• cif -> aiida-atomistic
• orbital -> aiida-atomistic
• structure -> aiida-atomistic
• upf -> aiida-pseudo

Impact

The impact of use case [1] is debatable, and by itself is most likely not enough of an argument to adopt this road map item. However, the improved implementation of these important data types (Use case [2]) will improve the usability for pretty much all current users. Facilitating the maintenance (use case [3]) will make it easier to make further improvements to usability.

Complexity

The move of the materials science-related data types has been discussed over a long time already, and is definitely not trivial to solve. Re-implementing the materials science data types will require quite a bit of work for each one, and it is also not yet clear how to have users move to the new data types smoothly.

Background

There is a long-standing open issue on exactly this topic:

aiidateam/aiida-core#2686

During the last coding week I also started gathering some notes in an AEP, but this was never finalised:

aiidateam/AEP#29

There has already been a lot of discussion on the redesign of the StructureData class, for example on why it uses kinds and how to add properties to the class, see:

aiidateam/aiida-quantumespresso#640

Progress

The legacy UpfData has already been moved to aiida-pseudo, but has not be removed - or even deprecated - in aiida-core.

Although there have been a lot of discussions on the other data types and what to do with them, as far as I know actual progress on the implementation has not been made.

[sphuber]

Links of previous discussions on various plugins:

• array.kpoints:
  • Set the properties of KpointsData class in the constructor. aiida-core#5942

[GeigerJ2]

Adding some notes from our team brainstorming meeting:

• Assigned @mikibonacci to lead the effort
• Focus on StructureData implementation which should be finalized by the end of August
• For the other classes, it's probably enough to just move them out, rather than investing more time for a full redesign (if even needed)
• Plugin support should be there by the end of September
  • Ensure that aiida-qe is fully supported, as well as the use cases we discussed (relaxation, wannier, phonons)
• Fully removing classes from aiida-core is about as backwards incompatible as it gets, so this would require v3 (decide until September)
  • How do we keep supporting the current (will be legacy) StructureData?
  • We could keep maintaining two StructureData classes (similar to how we still have the restapi module in aiida-core, and the aiida-restapi package) however, I feel like this puts too much maintenance burden on us
  • We could move the classes to aiida-atomistic, and make it a dependency of aiida-core (for the moment)
  • aiida meta-package could combine various plugins (including aiida-core, aiida-atomistic, and other plugins maintained by us)