Conflict for units of shflux

[david.gwyther]

Hi folks

I have been going back over my older code for generating forcing files and checking that everything is doing as I expected. In particular, I was looking at the fields supplied for the surface boundary forcing.

I was looking at this trac ticket https://www.myroms.org/projects/src/ticket/870, where the image shows what ROMS needs as the heat flux, with a net surface flux Q (units of W/m^2), divided by a reference density and heat capacity. (Likewise, a ROMS freshwater flux can be constructed by E-P / rho_{freshwater}).

This suggests that ROMS expects a surface heat flux with units of degCm/s (as the image says), which is some 4e-6 smaller than the net surface heat flux (i.e. divided by approximately 1000 and 4000).

However, I noted what looks like a conflict in the varinfo.yaml file, where the units and comment on the input are in Watt/m2:

Code: Select all

  - variable:       shflux                                           # Input/Output
    standard_name:  surface_downward_heat_flux_in_sea_water
    long_name:      surface net heat flux
    units:          watt meter-2                                     # Input:  [Watt/m2]
    field:          surface heat flux                                # [Celsius m/s]
    time:           shf_time                                         # Output: [Watt/m2]
    index_code:     idTsur(itemp)
    type:           r2dvar
    add_offset:     0.0d0
    scale:          1.0d0

I also looked through set_vbc.F, but couldn't see any division by rho_0 or C_p, and the scale == 1.0 suggest that there is no conversion internally (as there is for swflux -> ssflux; and I believe there used to be with the scale attribute converting swflux from cm/d to m/s).

I am assuming that ROMS expects degCm/s, and thus that I should scale by rho_0 and C_p when I pre-process the data fields, and the unit description in the varinfo.yaml is incorrect?

Thanks in advance and kind regards,

David G.

[wilkin]

The comments in varinfo.yaml tell you the units ROMS expects in a netCDF file, # Input: [Watt/m2]

Code: Select all

- variable:       shflux                                           # Input/Output
    standard_name:  surface_downward_heat_flux_in_sea_water
    long_name:      surface net heat flux
    units:          watt meter-2                                     # Input:  [Watt/m2]
    field:          surface heat flux                                # [Celsius m/s]
    time:           shf_time                                         # Output: [Watt/m2]
    index_code:     idTsur(itemp)
    type:           r2dvar
    add_offset:     0.0d0
    scale:          1.0d0

So, it's definitely Watt/m2 that you should give.

Conversion by the factor of rho0*Cp is set up in Utility/inp_par.F. Look for the code block ...

Code: Select all

!  Convert momentum stresses and tracer flux scales to kinematic
!  Values. Recall, that all the model fluxes are kinematic.
!
        cff=1.0_r8/rho0
        Fscale(idUsms,ng)=cff*Fscale(idUsms,ng)
        Fscale(idVsms,ng)=cff*Fscale(idVsms,ng)
 ...
        cff=1.0_r8/(rho0*Cp)
        Fscale(idTsur(itemp),ng)=cff*Fscale(idTsur(itemp),ng)
        Fscale(idTbot(itemp),ng)=cff*Fscale(idTbot(itemp),ng)
        Fscale(idSrad,ng)=cff*Fscale(idSrad,ng)
 ...

This initializes Fscale which is used later when the netcdf files are read.

For BULK_FLUXES the heat flux components are computed internally in Watts/m2 and near line 868 are converted to kinematic units to pass back to ROMS itself.

Code: Select all

!  Compute surface net heat flux and surface wind stress.
!=======================================================================
!
!  Compute kinematic, surface, net heat flux (degC m/s).  Notice that
!  the signs of latent and sensible fluxes are reversed because fluxes
...
!
      Hscale=1.0_r8/(rho0*Cp)
      cff=1.0_r8/rhow
      DO j=JstrR,JendR
        DO i=IstrR,IendR
          lrflx(i,j)=LRad(i,j)*Hscale
          lhflx(i,j)=-LHeat(i,j)*Hscale
          shflx(i,j)=-SHeat(i,j)*Hscale
          stflux(i,j,itemp)=(srflx(i,j)+lrflx(i,j)+                     &
     &                       lhflx(i,j)+shflx(i,j))
     

For idealized heat fluxes set with Functionals, the user has to make the conversion. This can be seen in Functionals/ana_srflux.h for shortwave radiation. For the UPWELLING example:

Code: Select all

!  Set incoming solar shortwave radiation (degC m/s).  Usually, the
!  shortwave radiation from input files is Watts/m2 and then converted
!  to degC m/s by multiplying by conversion factor 1/(rho0*Cp) during
!  reading (Fscale). However, we are already inside ROMS kernel here
!  and all the fluxes are kinematic so shortwave radiation units need
!  to be degC m/s.
!-----------------------------------------------------------------------
!
      cff=1.0_r8/(rho0*cp)
# if defined UPWELLING
      DO j=JstrT,JendT
        DO i=IstrT,IendT
          srflx(i,j)=cff*150.0_r8
        END DO
      END DO
...

[arango]

The comments in the YAML file within the brackets indicate the internal ROMS code values after multiplying by the scale factor. It is the units that ROMS needs in the governing equations. It has been like that for decades.

[david.gwyther]

Thanks for the replies, John and Hernan.

OK, so the units for Input and Output are as described in varinfo.yaml, but the comment between the Input/Output comments, is the units of the field used internally by ROMS? Possibly a "# Internal units: [Celsius m/s]" would make this clearer.

I suppose I was also dubious about how ROMS was handling conversions, because of the figure in the https://www.myroms.org/projects/src/ticket/870. If you follow the logic for swflux from the ticket and the equations in that figure: we should supply the input field with E-P/rhow, that has units of m/s, then likewise for shflux, following the equations given in that figure, ROMS should expect Qt/(rho0Cp). But, as you point out John, Utility/inp_par.F takes care of that scaling for us.

So there is a potentially confusing/misleading aspect of that trac ticket (at least it was for me!).

I hadn't found the conversion in Utility/inp_par.F - thanks for pointing it out John.

I appreciate you both pointing out how ROMS is handling these parameters internally, for different configurations, etc.

Cheers
Dave

[wilkin]

Well, yes, air-sea flux options and inputs is just another one of the many things we need to add to WikiROMS. Perhaps in my retirement ... !

Scanning those entries in varinfo.yaml I do spot an error in the #Input tag for dQdSST:

Code: Select all

  - variable:       dQdSST                                           # Input
    standard_name:  derivative_of_surface_downward_heat_flux_wrt_sea_surface_temperature
    long_name:      surface net heat flux sensitivity to SST
    units:          watt meter-2 Celsius-1                           # Input:  [Watt/m2]
    field:          d(Q)/d(SST)                                      # [Celsius m/s]
...

The units attribute is correct, but # Input: [Watt/m2] is not. It should be # Input: [Watt/m2/Celsius]

[david.gwyther]

Thanks John - good to have cleared that up.
Cheers
Dave