Currently, the only submittable artifacts alchemiscale supports from users are AlchemicalNetworks. This has worked well, but some users would like to be able to submit custom metadata associated with their AlchemicalNetworks that can be used for processing results downstream without needing an external system to retain this information.
To support this, we could add a metadata kwarg to AlchemiscaleClient.create_network that takes in a string as input. This string could contain any information a user believes they need associated with their submitted AlchemicalNetwork on initial submission, with perhaps server-side size/length limits imposed to keep these from being arbitrarily large. Restricting the data type to strings puts the burden on the user to serialize this data in a form they can deserialize before it hits the client, and avoids forcing them to use a particular data model, e.g. pydantic.
This string could be stored in either the state store or the object store. The state store would give faster retrieval, but the object store is more suitable for potentially large objects.
There may be other possible solutions with benefits/drawbacks. We will collect these here before proceeding to an implementation.
Currently, the only submittable artifacts
alchemiscalesupports from users areAlchemicalNetworks. This has worked well, but some users would like to be able to submit custom metadata associated with theirAlchemicalNetworks that can be used for processing results downstream without needing an external system to retain this information.To support this, we could add a
metadatakwarg toAlchemiscaleClient.create_networkthat takes in a string as input. This string could contain any information a user believes they need associated with their submittedAlchemicalNetworkon initial submission, with perhaps server-side size/length limits imposed to keep these from being arbitrarily large. Restricting the data type to strings puts the burden on the user to serialize this data in a form they can deserialize before it hits the client, and avoids forcing them to use a particular data model, e.g.pydantic.This string could be stored in either the state store or the object store. The state store would give faster retrieval, but the object store is more suitable for potentially large objects.
There may be other possible solutions with benefits/drawbacks. We will collect these here before proceeding to an implementation.