Closed jypeter closed 2 years ago
Your example only shows that operation clim_average(...,'annual')
translates in CRS as time_average(...)
without any parameter. This is the correct, complete translation, as shown by the code, and this is enough to recompute the value if needed.
It can be considered as unfortunate that calling function clim_average
translates in time_average
in CRS, but this is the price to pay if one wants to provide a versatile climaf function that embeds climaf operators.
You may also have discovered here that a call to clim_average(...,'annual') may lead to incorrect results if argument dataset does not cover full years.
My mistake for not noticing that we had clim_average
and time_average
! :-(
I actually wanted to perform an average on all time steps, for each member of an ensemble, but I thought that time_average
could not be applied to an ensemble (as described in #223) and decided to use clim_average(...,'annual')
This is loosely linked to #197
I'm experimenting with applying operations to ensembles, and checking the incrementally longer
crs
I get after chaining several operations. Unfortunately, I'm only getting the detailed parameters forllbox
. I don't know if this is becausellbox
is the first operator I use, or because the other operators are not set up to print their parametersMaybe I should use
my_ds.buildcrs(crsrewrite=some_hopefully_existing_function)
instead ofmy_ds.crs
?I understand of course the interest of usually keeping the crs not too long so that it remains readable. I'm just wondering if there is an existing way of getting a detailed crs when you are debugging. Maybe there is a way to get this by playing with the logging parameters, but I'm more looking for a way to get the information in the code, from a dataset object
As an example, here is a part of my code:
And I get the following
crs
results for one of the members (with only the detailed parameters ofllbox
)