Adding sfcWind derivation from uas and vas

[malininae]

Following #1895 and #2234 the sfcWind derivation from uas and vas has been added and the wind components fixes for uas and vas from ERA5 has been added. NB: it was impossible to add a height10m to the custom CMOR table.

[valeriupredoi]

@malininae many thanks for this! Looks good to me, but the time coordinate of the fixed cube is different from the time coordinate in the cmor cube:

cmor_cube coords:
DimCoord :  time / (days since 1850-1-1 00:00:00, standard calendar)
    points: [1990-01-01 00:00:00, 1990-01-01 01:00:00, 1990-01-01 02:00:00]
    shape: (3,)
    dtype: float64
    standard_name: 'time'
    long_name: 'time'
    var_name: 'time'

vs

fixed_cube coords:
DimCoord :  time / (days since 1850-1-1 00:00:00, standard calendar)
   points: [1989-12-31 23:30:00, 1990-01-01 00:30:00, 1990-01-01 01:30:00]
   shape: (3,)
   dtype: float64
   standard_name: 'time'
   long_name: 'time'
   var_name: 'time'

[valeriupredoi]

time coord of fixed cube needs looking into, apart from that all fine 🍺

[malininae]

time coord of fixed cube needs looking into, apart from that all fine 🍺

Is this the output from ERA? If yes, I've added the 30 mins offset for the hourly uas and vas

[valeriupredoi]

time coord of fixed cube needs looking into, apart from that all fine 🍺

Is this the output from ERA? If yes, I've added the 30 mins offset for the hourly uas and vas

indeed! See #2242 (comment) - exactly half hour early 😁 So I guess this is the fix motivated by #2234 - so please adjust the test cube as well, so that the test reflects the correct time points. In the future it'd be good if you opened a separate PR per issue or fix needing solving, things are a bit more clear that way 👍

[malininae]

time coord of fixed cube needs looking into, apart from that all fine 🍺

Is this the output from ERA? If yes, I've added the 30 mins offset for the hourly uas and vas

indeed! See #2242 (comment) - exactly half hour early 😁 So I guess this is the fix motivated by #2234 - so please adjust the test cube as well, so that the test reflects the correct time points. In the future it'd be good if you opened a separate PR per issue or fix needing solving, things are a bit more clear that way 👍

Sorry!!! I thought since they are related better to handle them in one pull request, will do better the next time 😊 By adjusting the test cube you mean the derived one? If yes, I'm currently applying the function to the models too.

[valeriupredoi]

time coord of fixed cube needs looking into, apart from that all fine 🍺

Is this the output from ERA? If yes, I've added the 30 mins offset for the hourly uas and vas

indeed! See #2242 (comment) - exactly half hour early 😁 So I guess this is the fix motivated by #2234 - so please adjust the test cube as well, so that the test reflects the correct time points. In the future it'd be good if you opened a separate PR per issue or fix needing solving, things are a bit more clear that way 👍

Sorry!!! I thought since they are related better to handle them in one pull request, will do better the next time 😊 By adjusting the test cube you mean the derived one? If yes, I'm currently applying the function to the models too.

not a problem at all - just for future reference 🍺

As for the failing tests, the uas and vas CMOR times don't match the fixed times, please have a look at how the time coordinate gets created for the CMOR cubes via time = _cmor_time('E1hr') in the vas and uas cases - I, for one, am not sure which is the correct one, it seems to me that 30min offset should not break the world, but you are the one to decide, in any case, either the function that assembles the CMOR time or the fix has to change 👍

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (0668223) 93.72% compared to head (66cfcfb) 93.73%.
Report is 20 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2242   +/-   ##
=======================================
  Coverage   93.72%   93.73%           
=======================================
  Files         238      239    +1     
  Lines       13125    13138   +13     
=======================================
+ Hits        12302    12315   +13     
  Misses        823      823           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[valeriupredoi]

cheers muchly for the very useful work, Liza! @bouweandela maybe you got time give this one last glance, and merge, pls bud? 🍺

[lukruh]

Hey @malininae thanks for the work, that might be useful for me too. I'm interested in sfcWind from ERA5, but on a monthly frequency. However, I just wanted to point out that the calculation is not linear, which means deriving sfcWind from monthly wind components is not the same as monthly mean of sfcWind calculated from higher frequencies. I'm not sure how monthly windspeed at 10m is calculated in the published ERA5 monthly dataset, but probably from higher frequencies.

Do you think it makes sense to limit the required input data to hourly and/or 3hourly data?

[malininae]

Hey @malininae thanks for the work, that might be useful for me too. I'm interested in sfcWind from ERA5, but on a monthly frequency. However, I just wanted to point out that the calculation is not linear, which means deriving sfcWind from monthly wind components is not the same as monthly mean of sfcWind calculated from higher frequencies. I'm not sure how monthly windspeed at 10m is calculated in the published ERA5 monthly dataset, but probably from higher frequencies.

Do you think it makes sense to limit the required input data to hourly and/or 3hourly data?

@lukruh thanks for the comment! It's indeed not an obvious question. I am writing a paper on extreme winds now and I looked through the 'stopping point' when sqrt(uas^2+vas^2) is not giving the same answer for different time aggregations. For my region of interest and my application, the stopping will be at 6 hours, however for some regions 6 hours is too much already and I would stop at 3. Daily give too much of an uncertainty due to non-linearity, as you mention. At the same time I was suggested by a model developer to use daily data. I agree, that I should add the constrain on the frequency, but which one to use for the, honestly, I don't know. I would suggest a day maybe and raise a warning if the frequency is above 3 hours?

[bouweandela]

To move this pull request forward, I would be keen to get #2256 merged first, then take out the custom variable from this pull request and then merge this.

[bouweandela]

#2256 has now been merged.