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
Intake-ESM provides the ability to provide a derived variable registry: a utility class which allows intake-ESM to construct variables on the fly, at query time.
These registries need to provided before the intake-ESM datastore is opened - hence the updates will need to be in intake-dataframe-catalog, approximately here, and would allow us to translate variables & add relevant metadata, potentially feeding into CMORisation efforts.
Properties of Derived Variable Registries
Silent Failure
If we attempt to register a derived variable which requires a variable which is unavailable in a dataset, then the derived variable will not be added to the xarray dataset when loaded: eg.
Unless doing so causes some unanticipated performance issues, this should mean we can pass a comprehensive list of all variables in - without needing to worry about missing variables breaking the registry.
Although derived variables are computed lazily, intake-ESM handles searching derived variables smoothly: eg.
NB. You still search on variable - not derived variable, and intake-ESM will return the original variable that was used to translate the variable too.
Derived variable registries can be used to create user defined variables, as well as translation: see docs. I think it should be possible to allow a user to hook into this and register their own derived variables in order to search for the subset of catalogued datasets from which they could obtain that derived variable.
The text was updated successfully, but these errors were encountered:
Describe the issue
Intake-ESM provides the ability to provide a derived variable registry: a utility class which allows intake-ESM to construct variables on the fly, at query time.
These registries need to provided before the intake-ESM datastore is opened - hence the updates will need to be in intake-dataframe-catalog, approximately here, and would allow us to translate variables & add relevant metadata, potentially feeding into CMORisation efforts.
Properties of Derived Variable Registries
NB. You still search on variable - not derived variable, and intake-ESM will return the original variable that was used to translate the variable too.
The text was updated successfully, but these errors were encountered: