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
For CifData, which doesn't store data on an atomic level, it's sometimes preferrable to not store atomic site information and more, since the represented structure hosts up towards 1000s of atoms, which would result in suddenly adding a huge amount of unnecessary bytes to the database and also make the search slow.
On another note, I think this may be possible by using aiida-optimade calc, where individual OPTIMADE fields can be specified.
However, since some fields rely on others, field X might still be calculated even if not specified due to Y's dependence on X. (E.g., the list of cartesian_site_positions MUST be the same length as species_on_sites.)
The text was updated successfully, but these errors were encountered:
This is a use case brought up by @ltalirz.
For
CifData
, which doesn't store data on an atomic level, it's sometimes preferrable to not store atomic site information and more, since the represented structure hosts up towards 1000s of atoms, which would result in suddenly adding a huge amount of unnecessary bytes to the database and also make the search slow.On another note, I think this may be possible by using
aiida-optimade calc
, where individual OPTIMADE fields can be specified.However, since some fields rely on others, field X might still be calculated even if not specified due to Y's dependence on X. (E.g., the list of
cartesian_site_positions
MUST be the same length asspecies_on_sites
.)The text was updated successfully, but these errors were encountered: