In recipe_wflow, use daily ERA5 data from the new cmorizer.

[Peter9192]

This PR changes the PCRglob recipe to take advantage of the new era5 cmorizer (#1432)

There was a bug in the old cmorizer. Some cmorized variables were
daily accumulations, and averaging them correctly now changes the valid
time to 11:30. This breaks the diagnostic, because there we do
some calculations between accumulated variables and non-accumulated variables.
Therefore, the regrid time preprocessor has been added.

[Peter9192]

@jeromaerts could you have a look? The valid time of our ERA5 data is either 12:00 (tas) or 11:30 (radiation) UTC. They're combined in the DeBruin computation, so we need them to be at the same time points. Currently, the regrid_time preprocessor changes the time points to midnight (without changing the data). Then you get a 12-hour offset. I see two ways to deal with this:

• Keep the regrid_time preprocessor and, at the end of the diagnostic, shift everything back half a day. We'll still be calculating PET on variables shifted 30 mins in time, but perhaps that negligible?
• Change the diagnostic to interpolate all data to the same time points (12:00 UTC). We might have to extrapolate half an hour for the last time point in the dataset in that case. Or add the first day of the next year in the recipe.

@SarahAlidoost @sverhoeven @bouweandela @JaroCamphuijsen @nielsdrost

[jeromaerts]

@Peter9192
In my opinion the calculation of PET variables shifted by 30 mins in time is acceptable/ negligible. I am concerned, however, that these type of fixes are a bit hacky.

Although the difference is negligible, I propose to interpolate all data to the same time points.

[bouweandela]

Keep the regrid_time preprocessor and, at the end of the diagnostic, shift everything back half a day.

@Peter9192 In that case I think it would be more transparent to just shift the times in the diagnostic for those variables that need it at the point where this is needed, the 12 hour shift seems to add needless complication.

I propose to interpolate all data to the same time points.

@jeromaerts Note that the daily data is derived from hourly data, it might make more sense to interpolate the hourly data before computing the mean or even change the temporal statistics function so it does a weighted mean instead of only looking at the time points that are contained within a day: time points from 0-23 hours lead to an average time point of 11:30 for instantaneous variables, while it would probably make more sense to include 0 hours of the next day too in this computation, and then give the two time points at 0 hours half the weight of the other time points. However, this could be a considerable amount of work, so we need to decide whether or not this important.

[SarahAlidoost]

@Peter9192 @bouweandela @jeromaerts Half-hour time shift is implemented for tas and psl in marrmot diagnostic, here #1600

[SarahAlidoost]

@Peter9192 thanks, looks good. Also, could you please update the documentation of wflow here

[Peter9192]

update the documentation

Good one! Done :-)

[SarahAlidoost]

update the documentation

Good one! Done :-)

Thanks, and also please address the merge conflict.

[bouweandela]

@SarahAlidoost Can you please approve the pull request once you're happy with it?
@Peter9192 Could you please update the pull request title? For clarity, it should mention the name of the recipe that is changed and I think you no longer use the regrid_time preprocessor?

[Peter9192]

Could you please update the title?

Done

[SarahAlidoost]

@SarahAlidoost Can you please approve the pull request once you're happy with it?
@Peter9192 Could you please update the pull request title? For clarity, it should mention the name of the recipe that is changed and I think you no longer use the regrid_time preprocessor?

@bouweandela Done.