Motivation
When computers and codes were originally designed, a certain level of rigidity on their properties was established in order to try to impose a stricter level of control over the preservation of the provenance. However, the frequent changes an updates that computer clusters perform on their systems forces users to be also updating the ways in which they access those resources. Part of this required versatility was taken into account by allowing some parameters of computer access to be set in the configuration of the computer, rather than in its attributes during setup. However, many users find that this is not enough and express frustration at the limitations that these entities still have.
Some examples include:
-
After updating software in clusters, some software change location and thus the respective code needs to be updated or changed to a new one. Creating a new code is the natural solution, but it tends to then over-complicate querying later.
-
One may want to set up a computer to be able to be used with different schedulers (specially considering the inclusion of meta-schedulers such as aiida-hyperqueue), but by doing so the remote folders created by one are technically in a different computer and thus copying of files between those is not allowed.
Desired Outcome
Rethink how immutability works in the computer and code nodes, what restrictions can be relaxed, which ones we want to keep to ensure a cleaner provenance, and what other options can we offer users to facilitate dealing with these immutability problems in the cases that need to remain.
Impact
This will potentially improve usability for all users of AiiDA.
Complexity
Since this is not a bug or missing feature, but a direct consequence of how we enforce the "respect" for the provenance and this clashing or resulting inconvenience in practical usage, the biggest issue here is to rethink a more general principle of AiiDA. Since this is coming from unforeseen practical inconvenience, it is worth it to first try to do a thorough compilation of user frustrations and also some thinking into other potential problems.
Progress
The first task should be to do a comprehensive analysis of the situation and gather any remaining use case that may be relevant to consider.
Motivation
When computers and codes were originally designed, a certain level of rigidity on their properties was established in order to try to impose a stricter level of control over the preservation of the provenance. However, the frequent changes an updates that computer clusters perform on their systems forces users to be also updating the ways in which they access those resources. Part of this required versatility was taken into account by allowing some parameters of computer access to be set in the
configurationof the computer, rather than in its attributes during setup. However, many users find that this is not enough and express frustration at the limitations that these entities still have.Some examples include:
After updating software in clusters, some software change location and thus the respective code needs to be updated or changed to a new one. Creating a new code is the natural solution, but it tends to then over-complicate querying later.
One may want to set up a computer to be able to be used with different schedulers (specially considering the inclusion of meta-schedulers such as aiida-hyperqueue), but by doing so the remote folders created by one are technically in a different computer and thus copying of files between those is not allowed.
Desired Outcome
Rethink how immutability works in the computer and code nodes, what restrictions can be relaxed, which ones we want to keep to ensure a cleaner provenance, and what other options can we offer users to facilitate dealing with these immutability problems in the cases that need to remain.
Impact
This will potentially improve usability for all users of AiiDA.
Complexity
Since this is not a bug or missing feature, but a direct consequence of how we enforce the "respect" for the provenance and this clashing or resulting inconvenience in practical usage, the biggest issue here is to rethink a more general principle of AiiDA. Since this is coming from unforeseen practical inconvenience, it is worth it to first try to do a thorough compilation of user frustrations and also some thinking into other potential problems.
Progress
The first task should be to do a comprehensive analysis of the situation and gather any remaining use case that may be relevant to consider.