units of swflux
lnferris opened this issue · 8 comments
In prepare_ecmwf.jl, the scale for swflux is scale = 1.0/Δt_seconds*(24*3600.0). Should it be scale = 1.0/Δt_seconds to match the units of varinfo.dat, which is meters seconds-1? I noticed this after my output freshwater flux was zero.
If so, I think metadata.jl should also be changed, as the units for swflux are units = "centimeter day-1"
Here are relevant links:
https://www.myroms.org/projects/src/ticket/870
https://www.myroms.org/forum/viewtopic.php?p=24023#p24023 <- suggests m/s
https://www.myroms.org/index.php?page=forcing <-suggests cm/day
Thank you for bringing that up. I just made a commit to fix to problem.
For my reference, this is the change in the ROMS code:
git diff -b 5d272cb78~ 5d272cb78 External/varinfo.dat--- a/ROMS/External/varinfo.dat
+++ b/ROMS/External/varinfo.dat
@@ -2,7 +2,7 @@
! ROMS/TOMS IO NetCDF variables.
!
!git $Id$
-!svn $Id: varinfo.dat 1039 2020-10-12 03:54:49Z arango $
+!svn $Id: varinfo.dat 1041 2020-10-16 00:00:17Z arango $
!========================================================= Hernan G. Arango ===
! Copyright (c) 2002-2020 The ROMS/TOMS Group !
! Licensed under a MIT/X style license !
@@ -54,11 +54,11 @@
! Notice that we use the prefix 'ocean' in the variable name to differentiate
! between oceanic and atmospheric time clocks in fully coupled applications.
!
-! Notice that salinity does not have physical units. A commented [PSU] can
+! Notice that salinity does not have physical units. A commented [PSS] can
! be found below to indicate that the practical salinity scale was used to
! determine conductivity. See,
!
-! http://marine.rutgers.edu/po/users/forum/viewtopic.php?t=294
+! https://www.myroms.org/forum/viewtopic.php?t=294
!
!------------------------------------------------------------------------------
! SVN Repository
@@ -246,7 +246,7 @@
'salt' ! Input/Output
'salinity'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salinity, scalar, series'
'ocean_time'
'idTvar(isalt)'
@@ -264,7 +264,7 @@
'salt_sur' ! Output
'surface salinity'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salinity, scalar, series'
'ocean_time'
'idsurT(isalt)'
@@ -528,7 +528,7 @@
'salt_tide' ! Input/Output
'time-accumulated salinity tide harmonics'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_tide, scalar'
'ocean_time'
'idTrcH(isalt)'
@@ -537,7 +537,7 @@
'salt_detided' ! Output
'detided potential temperature'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_detided, scalar, series'
'ocean_time'
'idTrcD(isalt)'
@@ -700,8 +700,8 @@
1.0d0
'ssflux' ! Output
- 'surface net salt flux, (E-P)*SALT'
- 'meter second-1' ! [PSU m/s]
+ 'kinematic surface net salt flux, SALT*(E-P)/rhow'
+ 'meter second-1' ! [PSS m/s]
'surface net salt flux, scalar, series'
'ssf_time'
'idTsur(isalt)'
@@ -709,20 +709,20 @@
1.0d0
'swflux' ! Input
- 'surface net freshwater flux, (E-P)'
- 'centimeter day-1' ! Input: [m/s]
- 'surface net salt flux, scalar, series' ! [PSU m/s]
+ '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.157407d-7 ! 0.01/86400
+ 1.0d0
'EminusP' ! Input/Output
- 'bulk_flux surface net freshwater flux, (E-P)'
+ 'modeled surface net freshwater flux, (E-P)/rhow'
'meter second-1' ! computed by NLM ROMS
- 'EminusP, scalar, series' ! bulk_flux.F and
- 'ocean_time' ! needed in adjoint-based
- 'idEmPf' ! applications
+ 'EminusP, scalar, series' ! bulk_flux.F or coupling
+ 'ocean_time'
+ 'idEmPf'
'r2dvar'
1.0d0
@@ -738,7 +738,7 @@
'bwflux' ! Input
'bottom net freshwater flux'
'centimeter day-1' ! Input: [m/s]
- 'bottom water flux, scalar, series' ! [PSU m/s]
+ 'bottom water flux, scalar, series' ! [PSS m/s]
'bwf_time'
'idTbot(isalt)'
'r2dvar'
@@ -1322,7 +1322,7 @@
'salt_west' ! Input
'salinity western boundary condition'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_west, scalar, series'
'salt_time'
'idTbry(iwest,isalt)'
@@ -1331,7 +1331,7 @@
'salt_east' ! Input
'salinity eastern boundary condition'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_east, scalar, series'
'salt_time'
'idTbry(ieast,isalt)'
@@ -1340,7 +1340,7 @@
'salt_south' ! Input
'salinity southern boundary condition'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_south, scalar, series'
'salt_time'
'idTbry(isouth,isalt)'
@@ -1349,7 +1349,7 @@
'salt_north' ! Input
'salinity northern boundary condition'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_north, scalar, series'
'salt_time'
'idTbry(inorth,isalt)'
@@ -1835,7 +1835,7 @@
'river_salt' ! Input
'river runoff salinity'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'river_salt, scalar, series'
'river_time'
'idRtrc(isalt)'
@@ -2091,7 +2091,7 @@
'SSS' ! Input
'sea surface salinity climatology'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'SSS, scalar, series'
'sss_time'
'idSSSc'
@@ -2216,7 +2216,7 @@
'salt' ! Input
'salinity functional'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_time, scalar, series'
'salt_time'
'idTads(isalt)'
@@ -2290,7 +2290,7 @@
'salt' ! Input
'salinity impulse forcing'
- 'nondimensional' ! [PSU]
+ 'nondimensional' ! [PSS]
'salt_time, scalar, series'
'salt_time'
'idTtlf(isalt)'Surprisingly the current revision of d_ecmwf2roms.m (svn 1156 2023-02-18 01:44:37Z) still uses cm day-1
% Uwind (m s-1) v10u
% Vwind (m s-1) v10v
% sustr (N m-2) ewss / (3*3600); 3-hour step
% svstr (N m-2) nsss / (3*3600); 3-hour step
% shflux (W m-2) (ssr+str+sshf+slhf) / (3*3600)
% swrad (W m-2) ssr / (3*3600); 3-hour step
% lwrad_down (W m-2) strd / (3*3600); 3-hour step
% latent (W m-2) slhf / (3*3600); 3-hour step
% sensible (W m-2) sshf / (3*3600): 3-hour step
% rain (kg m-2 s-1) tp * Rho_w / (3*3600)
% evaporation (kg m-2 s-1) e * Rho_w / (3*3600)
% swflux (cm day-1) (e - tp) * 100 / (3/24); 0.125 day step
% cloud (nondimesional) tcc
% Pair (mb) msl / 100; (1 mb = 100 Pa)
% Tair (Celsius) t2m - 273.15; (1 C = 273.15 K)
% Qair (percentage) 100 * (E/Es)
I also noticed this accumulation scheme (shared with d_ecmwf2roms.m) creates positive and negative rain, which should be positive-definite (I think). Is this consistent with your experience? If not, the issue may be my selection for reset_accumulation.
I am happy to share a script to prepare forcing in terms of ERA5 variables that do not require accumulation, if desired.
I am happy to share a script to prepare forcing in terms of ERA5 variables that do not require accumulation, if desired.
yes, that would be really great! Can you make a pull request?
Is this issue (the bug in accumulation scheme) still open? I don't remember if we left it in my or your court. I think the hangup was whether to give ERA its own metadata based on the height of wind speed, etc.
Yes, this issue is corrected here:
(I am closing this issue, feel free to re-open if necessary)