support for ERA5 nonaccumulated variables

[lnferris]

@Alexander-Barth this is in reference to issue. Please take a look at these additions and see if they look correct:

/src/Atmosphere/prepare_era5.jl

/src/metadata_era5.jl

/examples/forcing_era5.py

[Alexander-Barth]

Thank you for the PR! I can you delete the 3 .DS_Store files?

I am wondering if we need a separate meatadata.jl file. The idea is that this file provides the attributes as needed by ROMS. Would it work if we use the the current meatadata.jl with the ERA5 data? Can you explain me why you needed to change this file?

Thanks again!

[lnferris]

It is because the wind in ERA5 is 10-m wind and the air humidity and temperature are 2-m (rather than surface-referenced, as in metadata.jl). One solution would be to entirely remove verbiage related to the reference height, e.g. "surface" for wind_time, Uwind, Vwind, qair_time, Qair, tair_time, and Tair. The user would then just have to think about which forcing data they used when setting (in roms.in):

! Height (m) of atmospheric measurements for Bulk fluxes parameterization.
      BLK_ZQ == 2.0d0                     ! air humidity
      BLK_ZT == 2.0d0                     ! air temperature
      BLK_ZW == 10.0d0                     ! winds

[Alexander-Barth]

Yes, I agree with that "surface" is not very specific. Unfortunately that are the terms used e.g. in ROMS/External/varinfo.yaml from ROMS-4.1

 - variable:       Tair                                             # Input
    standard_name:  surface_air_temperature
    long_name:      surface air temperature
    units:          Celsius                                          # [Kelvin]
    field:          surface air temperature
    time:           tair_time
    index_code:     idTair
    type:           r2dvar
    add_offset:     0.0d0
    scale:          1.0d0

Surprisingly there is no (or no more) term surface_air_temperature in the CF conventions.

The operational ECMWF forecast use the same reference depth as ERA5:

	short u10(time, latitude, longitude) ;
		u10:scale_factor = 0.000609159924372661 ;
		u10:add_offset = 2.94145405269773 ;
		u10:_FillValue = -32767s ;
		u10:missing_value = -32767s ;
		u10:units = "m s**-1" ;
		u10:long_name = "10 metre U wind component" ;
	short v10(time, latitude, longitude) ;
		v10:scale_factor = 0.000713792096878538 ;
		v10:add_offset = -3.90648959410752 ;
		v10:_FillValue = -32767s ;
		v10:missing_value = -32767s ;
		v10:units = "m s**-1" ;
		v10:long_name = "10 metre V wind component" ;
	short t2m(time, latitude, longitude) ;
		t2m:scale_factor = 0.000860644786071521 ;
		t2m:add_offset = 284.752377294794 ;
		t2m:_FillValue = -32767s ;
		t2m:missing_value = -32767s ;
		t2m:units = "K" ;
		t2m:long_name = "2 metre temperature" ;

Can you confirm that ROMS accepts the forcing field (with the different long name)?
Do you know if there are some tools (in the context of ROMS) that expects the long_names to be surface air temperature (and similar for winds)?

[lnferris]

I believe that the long_name is not carried forward from the prepared forcing data, e.g. model2021_swflux.nc. According to this it seems like Vinfo(1), 'swflux' used to staple the data, which is trusted to be in the units described in V(2-3), to its ROMS name V(6).

'swflux'                                           ! Input
  'data surface net freshwater flux, (E-P)/rhow'
  'meter second-1'                                 ! Input:  [m/s]
  'surface net freshwater flux, scalar, series'    ! [PSS m/s]
  'swf_time'
  'idsfwf'
  'r2dvar'
  1.0d0

The point being that the long_name in metadata.jl doesn't really matter, as long as the user remembers to set the right values in roms.in based on the actual reference height.

Regarding situations where ROMS expects surface heights, ROMS needs to know the reference height (whether that is 0m, 2m, or 10m...) for bulk fluxes. For example, you can see the provided reference height BLK_ZQ, BLK_ZT, BLK_ZW being using here to rescale the data. I don't personally use any meteorology sources that reference to surface, though. I know ERA5 and JRA55 do not. Maybe if someone had a mooring with anemometer and used data from that sensor package (elevated at 0m or 3.1m or 999m) to compute bulk fluxes for an entire [hopefully small] domain? But that leaves the realm of preparing standard meteorological data. Let me know if I misunderstood this question.

[Alexander-Barth]

Well after thinking a bit about this, I think that we should rather use the default long_name as they are used in ROMS (even if they do not include the reference height). Would it be possible for you to change this PR to use metadata.jl (rather than having a separate metadata_era5.jl). I can also make the changes myself after the merge.