This will be possible with the new functionality that will be shipped with aiida-core==1.2.0

This should allow the user to project additional or other properties of the UpfData nodes contained within a family, such as the number of electrons

Currently aiida-sssp only allows installing an SSSP configuration by downloading it from the Materials Cloud archive. This can be quite limiting for example when the resources are not available or the machine does not have internet connection. We should look into providing the option to install from resources already on disk. The question is what level of validation we implement. Do we allow non-official SSSP configurations and just any UPF family? Should we make a separate Group subclass for these, i.e. a UpfFamily with the SsspFamily being a subclass of this adding additional restrictions and validations?

On May 27th, the Materials Cloud Archive migrated to a new backend and the current URL that we use for the SSSP archive entry is no longer valid.

Hi,

See the following:

aiida-core 1.1.1 has requirement click==7.0

aiida-sssp 0.1.0 has requirement click~=7.1

So the two packages are incompatible. But if I change the version config in setup.json of aiida-core for this package to the following:

click~=7.1

This problem will disappear, but I still not so clear whether this this intentional revision will compromise the functions.

Regards

This concept is currently loosely implemented by storing a regular Dict node, that contains an attribute that cross references the label of the Group of UpfData for which it provides the recommended cutoffs. This is necessary since there is no official link to couple a Dict node to a Group in aiida-core. Another possibility would be to store the data directly on the Group instance, but since it currently does not have a way to store arbitrary attributes, that is not possible. A final possibility would be to include a single Dict node in the collection of nodes of the Group itself

• Loose Dict node loosely coupled through an attribute
• Include Dict node as one of the nodes in the collection in the Group itself
• Couple Dict node to Group through actual link, with custom LinkType
• Store the cutoffs directly on the Group instance as metadata or attributes

The last two possibilities would first require more functionality to be implemented in aiida-core.

The download of the pseudo tarball can take quite a while so it would be nice to show a progress bar during this period.

This information will be important for later verification in case there are inconsistency problems found with the family. Of course groups are mutable so the nodes could simply have been swapped out but assuming no peddling this might still be useful information.

consider integrating workflows for regenerating sssp from
https://github.com/giprandini/sssp-protocol

this would be very useful in order to avoid losing this capability.

in that case, please also make a new version of the sssp archive record that points to this package

The functionality implemented so far is really useful to work with UPF families. However, the current design explicitly does not support any UPF family, but only well-defined SSSP families. It would be relatively easy to generalize the functionality and have the SsspFamily simply be a subclass of a generic UpfFamily that only allows SSSP configurations to be stored. The only problem here would be naming.

The most logical naming of the classes would be UpfFamily and SsspFamily with the latter being a subclass of the former. The most logical corresponding entry point names would be upf.family and sssp.family, respectively. However, given that the plugin package is called aiida-sssp, and convention states that the entry point prefix should therefore be sssp, these names would break convention.

Other options:

sssp.upf.family = aiida_sssp.groups.upf:UpfFamily
sssp.family = aiida_sssp.groups.sssp.SsspFamily