You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #481, we are also adding a clarification that custom dimension names MUST start with the database or definition provider prefix.
In the property definitions, a number of dimension names (e.g., dim_sites, dim_spacial, ...) are implicitly defined as the dimension names of certain arrays.
However, there is no centralised place to read all dimension names currently defined by our specs.
This might be inconvenient when a user provides a custom array property and needs to also provide the corresponding property definition (in particular, the dimension names for each axis of each custom array).
Not having this centralised list will result in people not reusing the correct name when it's appropriate (e.g., a contributor of data including a force array _exmpl_forces for a structure entry should ideally declare it with dimensions [dim_sites, dim_spatial], and not e.g. [_exmpl_dim_num_atoms, _exmpl_dim_cartesions] or something like this). Doing this properly (i.e., using [dim_sites, dim_spatial]) will allow proper simultaneous slicing of both arrays, e.g., atom coordinates and forces with a query parameter property_slices=dim_sites:4:8:2).
To facilitate data providers (and to avoid inconsistencies in our property definitions), we should therefore:
Provide a centralised table of all dimension names and their human-readable descriptions
Ideally, autogenerate the list of all array properties that use it as one or more of their dimensions
Implement a GitHub action that checks if we are forgetting to declare a dimension name in this table, if at least one array property has it
E.g., the table might look like the following:
Dimension name
Human-readable description
Array axes using this dimension
dim_sites
The number of sites in a structure entry or in a frame of a trajectory
For the structures endpoint: cartesian_site_positions[0], species_at_sites[0]. For the trajectory endpoint: cartesian_site_positions[1]. ...
dim_species
The number of species in a structure entry or in a frame of a trajectory
For the structures endpoint: species[0]. For the trajectory endpoint: ...
dim_spatial
...
...
...
...
...
The text was updated successfully, but these errors were encountered:
In #481, we are also adding a clarification that custom dimension names MUST start with the database or definition provider prefix.
In the property definitions, a number of dimension names (e.g.,
dim_sites
,dim_spacial
, ...) are implicitly defined as the dimension names of certain arrays.However, there is no centralised place to read all dimension names currently defined by our specs.
This might be inconvenient when a user provides a custom array property and needs to also provide the corresponding property definition (in particular, the dimension names for each axis of each custom array).
Not having this centralised list will result in people not reusing the correct name when it's appropriate (e.g., a contributor of data including a force array
_exmpl_forces
for a structure entry should ideally declare it with dimensions[dim_sites, dim_spatial]
, and not e.g.[_exmpl_dim_num_atoms, _exmpl_dim_cartesions]
or something like this). Doing this properly (i.e., using[dim_sites, dim_spatial]
) will allow proper simultaneous slicing of both arrays, e.g., atom coordinates and forces with a query parameterproperty_slices=dim_sites:4:8:2
).To facilitate data providers (and to avoid inconsistencies in our property definitions), we should therefore:
E.g., the table might look like the following:
dim_sites
cartesian_site_positions[0]
,species_at_sites[0]
. For the trajectory endpoint:cartesian_site_positions[1]
. ...dim_species
species[0]
. For the trajectory endpoint: ...dim_spatial
The text was updated successfully, but these errors were encountered: