cppdefs for BULK_FLUX
cppdefs for BULK_FLUX
At first, I used Forcing Flux input files to simulate my model. Comparing with SODA Climatology, The temperature results are not so good(shown below).
Then be advised to using Bulk Flux input files, I open #define BULK_FLUXES in .h files. The result in the first month is close to SODA, but it gets worse in following months gradually(shown below).
Expect for #define BULK_FLUXES, what else cpps should I define?
Following is Activated C-preprocessing Options in my .h file.
oceanM Northwest Pacific Model
ANA_BSFLUX Analytical kinematic bottom salinity flux.
ANA_BTFLUX Analytical kinematic bottom temperature flux.
ASSUMED_SHAPE Using assumed-shape arrays.
AVERAGES Writing out time-averaged nonlinear model fields.
BULK_FLUXES Surface bulk fluxes parameterization.
CURVGRID Orthogonal curvilinear grid.
DIFF_GRID Horizontal diffusion coefficient scaled by grid size.
DIURNAL_SRFLUX Modulate shortwave radiation by the local diurnal cycle.
DJ_GRADPS Parabolic Splines density Jacobian (Shchepetkin, 2002).
DOUBLE_PRECISION Double precision arithmetic.
EMINUSP Compute Salt Flux using E-P.
INLINE_2DIO Processing 3D IO level by level to reduce memory needs.
KANTHA_CLAYSON Kantha and Clayson stability function formulation.
MASKING Land/Sea masking.
MIX_GEO_TS Mixing of tracers along geopotential surfaces.
MIX_S_UV Mixing of momentum along constant S-surfaces.
MPI MPI distributed-memory configuration.
MY25_MIXING Mellor/Yamada Level-2.5 mixing closure.
NONLINEAR Nonlinear Model.
NONLIN_EOS Nonlinear Equation of State for seawater.
NO_WRITE_GRID Not Writing grid arrays into NetCDF ouput files.
N2S2_HORAVG Horizontal smoothing of buoyancy and shear.
POWER_LAW Power-law shape time-averaging barotropic filter.
QCORRECTION Surface net heat flux correction.
K_GSCHEME Third-order upstream advection of TKE fields.
!RST_SINGLE Double precision fields in restart NetCDF file.
SALINITY Using salinity.
SOLVE3D Solving 3D Primitive Equations.
SPLINES Conservative parabolic spline reconstruction.
TS_U3HADVECTION Third-order upstream horizontal advection of tracers.
TS_C4VADVECTION Fourth-order centered vertical advection of tracers.
TS_DIF2 Harmonic mixing of tracers.
UV_ADV Advection of momentum.
UV_COR Coriolis term.
UV_U3HADVECTION Third-order upstream horizontal advection of 3D momentum.
UV_C4VADVECTION Fourth-order centered vertical advection of momentum.
UV_QDRAG Quadratic bottom stress.
UV_VIS2 Harmonic mixing of momentum.
VAR_RHO_2D Variable density barotropic mode.
VISC_GRID Horizontal viscosity coefficient scaled by grid size.
Any suggestion are welcomed, thank you in advance.
Then be advised to using Bulk Flux input files, I open #define BULK_FLUXES in .h files. The result in the first month is close to SODA, but it gets worse in following months gradually(shown below).
Expect for #define BULK_FLUXES, what else cpps should I define?
Following is Activated C-preprocessing Options in my .h file.
oceanM Northwest Pacific Model
ANA_BSFLUX Analytical kinematic bottom salinity flux.
ANA_BTFLUX Analytical kinematic bottom temperature flux.
ASSUMED_SHAPE Using assumed-shape arrays.
AVERAGES Writing out time-averaged nonlinear model fields.
BULK_FLUXES Surface bulk fluxes parameterization.
CURVGRID Orthogonal curvilinear grid.
DIFF_GRID Horizontal diffusion coefficient scaled by grid size.
DIURNAL_SRFLUX Modulate shortwave radiation by the local diurnal cycle.
DJ_GRADPS Parabolic Splines density Jacobian (Shchepetkin, 2002).
DOUBLE_PRECISION Double precision arithmetic.
EMINUSP Compute Salt Flux using E-P.
INLINE_2DIO Processing 3D IO level by level to reduce memory needs.
KANTHA_CLAYSON Kantha and Clayson stability function formulation.
MASKING Land/Sea masking.
MIX_GEO_TS Mixing of tracers along geopotential surfaces.
MIX_S_UV Mixing of momentum along constant S-surfaces.
MPI MPI distributed-memory configuration.
MY25_MIXING Mellor/Yamada Level-2.5 mixing closure.
NONLINEAR Nonlinear Model.
NONLIN_EOS Nonlinear Equation of State for seawater.
NO_WRITE_GRID Not Writing grid arrays into NetCDF ouput files.
N2S2_HORAVG Horizontal smoothing of buoyancy and shear.
POWER_LAW Power-law shape time-averaging barotropic filter.
QCORRECTION Surface net heat flux correction.
K_GSCHEME Third-order upstream advection of TKE fields.
!RST_SINGLE Double precision fields in restart NetCDF file.
SALINITY Using salinity.
SOLVE3D Solving 3D Primitive Equations.
SPLINES Conservative parabolic spline reconstruction.
TS_U3HADVECTION Third-order upstream horizontal advection of tracers.
TS_C4VADVECTION Fourth-order centered vertical advection of tracers.
TS_DIF2 Harmonic mixing of tracers.
UV_ADV Advection of momentum.
UV_COR Coriolis term.
UV_U3HADVECTION Third-order upstream horizontal advection of 3D momentum.
UV_C4VADVECTION Fourth-order centered vertical advection of momentum.
UV_QDRAG Quadratic bottom stress.
UV_VIS2 Harmonic mixing of momentum.
VAR_RHO_2D Variable density barotropic mode.
VISC_GRID Horizontal viscosity coefficient scaled by grid size.
Any suggestion are welcomed, thank you in advance.
Re: cppdefs for BULK_FLUX
Turning on BULK_FLUX is one step. What are you using to provide the atmospheric fields? How frequently? You have:
which I would not use if the atmospheric fields are say three-hourly.
Code: Select all
DIURNAL_SRFLUX Modulate shortwave radiation by the local diurnal cycle.
- arango
- Site Admin
- Posts: 1367
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: cppdefs for BULK_FLUX
My current strategy is to activate LONGWAVE_OUT and provide downward longwave radiation so bulk_flux will subtract the outgoing IR by using ROMS surface temperature (K), infrared emissivity, and Stefan-Boltzmann constant. I also use downward shortwave radiation and I activate COOL_SKIN to correct for mean absorption in the cool-skin layer. Both the longwave and shortwave data needs to be provided frequently, at least every three hours. We need to check for any long warming trends in the solution. The source and resolution of the atmospheric data are very important. You need to take that into consideration when comparing with analysis data. Some of those products have ocean data assimilation, but that's another topic.
Additionally, sometimes I activate WIND_MINUS_CURRENT to compute the effective winds by subtracting the surface ocean currents.
You need to be sure that the sign of the shortwave and longwave is correct into the ocean. Atmospheric models and data may have the opposite sign.
Additionally, sometimes I activate WIND_MINUS_CURRENT to compute the effective winds by subtracting the surface ocean currents.
You need to be sure that the sign of the shortwave and longwave is correct into the ocean. Atmospheric models and data may have the opposite sign.
Re: cppdefs for BULK_FLUX
Thanks a lot for your reply.kate wrote:Turning on BULK_FLUX is one step. What are you using to provide the atmospheric fields? How frequently? You have:which I would not use if the atmospheric fields are say three-hourly.Code: Select all
DIURNAL_SRFLUX Modulate shortwave radiation by the local diurnal cycle.
I uesed Uwind,Vwind,Tair,rain,Qair,Pair,lwrad_down,lwrad,swrad,SST,and dQdSST. They all are monthly data. Expect dQdSST is from SODA climatology dataset, others are all from COADS05. I hope to simulate the climatology condition in East China Sea.
Following are detailed information about my atmospheric and oceanic fields.(when copy these information, I find a mistake on the units of Uwind and Vwind. Is it possible that the unsatisfied result comes from this mistake? )
Uwind
Size: 205x253x12
Dimensions: xi_rho,eta_rho,wind_time
Datatype: single
Attributes:
long_name = '10-meter u-wind component'
units = 'wind_time'
coordinates = 'lon_rho lat_rho'
Vwind
Size: 205x253x12
Dimensions: xi_rho,eta_rho,wind_time
Datatype: single
Attributes:
long_name = '10-meter v-wind component'
units = 'wind_time'
coordinates = 'lon_rho lat_rho'
Tair
Size: 205x253x12
Dimensions: xi_rho,eta_rho,tair_time
Datatype: single
Attributes:
long_name = 'surface air temperature'
units = 'Celsius'
time = 'tair_time'
coordinates = 'lon lat'
rain
Size: 205x253x12
Dimensions: xi_rho,eta_rho,rain_time
Datatype: single
Attributes:
long_name = 'rain fall rate'
units = 'kilogram meter-2 second-1'
time = 'rain_time'
coordinates = 'lon lat'
Qair
Size: 205x253x12
Dimensions: xi_rho,eta_rho,qair_time
Datatype: single
Attributes:
long_name = 'surface air relative humidity'
units = 'percentage'
time = 'qair_time'
coordinates = 'lon lat'
Pair
Size: 205x253x12
Dimensions: xi_rho,eta_rho,pair_time
Datatype: single
Attributes:
long_name = 'surface air pressure'
units = 'millibar'
time = 'pair_time'
coordinates = 'lon lat'
lwrad_down
Size: 205x253x12
Dimensions: xi_rho,eta_rho,lrf_time
Datatype: single
Attributes:
long_name = 'downwelling longwave radiation flux'
units = 'Watts meter-2'
time = 'lrf_time'
positive = 'downward flux, heating'
negative = 'upward flux, cooling'
coordinates = 'lon lat'
lwrad
Size: 205x253x12
Dimensions: xi_rho,eta_rho,lrf_time
Datatype: single
Attributes:
long_name = 'net longwave radiation'
units = 'Watts meter-2'
time = 'lrf_time'
positive = 'downward flux, heating'
negative = 'upward flux, cooling'
coordinates = 'lon lat'
swrad
Size: 205x253x12
Dimensions: xi_rho,eta_rho,srf_time
Datatype: single
Attributes:
long_name = 'solar shortwave radiation'
units = 'Watts meter-2'
time = 'srf_time'
positive = 'downward flux, heating'
negative = 'upward flux, cooling'
coordinates = 'lon lat'
SST
Size: 205x253x12
Dimensions: xi_rho,eta_rho,sst_time
Datatype: single
Attributes:
long_name = 'sea surface temperature'
units = 'Celsius'
time = 'sst_time'
coordinates = 'lon lat'
dQdSST
Size: 205x253x12
Dimensions: xi_rho,eta_rho,sst_time
Datatype: double
Attributes:
long_name = 'surface net heat flux sensitivity to SST'
units = 'Watts meter-2 Celsius-1'
Last edited by fLy0516 on Thu May 02, 2019 1:45 am, edited 1 time in total.
Re: cppdefs for BULK_FLUX
arango wrote:My current strategy is to activate LONGWAVE_OUT and provide downward longwave radiation so bulk_flux will subtract the outgoing IR by using ROMS surface temperature (K), infrared emissivity, and Stefan-Boltzmann constant. I also use downward shortwave radiation and I activate COOL_SKIN to correct for mean absorption in the cool-skin layer. Both the longwave and shortwave data needs to be provided frequently, at least every three hours. We need to check for any long warming trends in the solution. The source and resolution of the atmospheric data are very important. You need to take that into consideration when comparing with analysis data. Some of those products have ocean data assimilation, but that's another topic.
Additionally, sometimes I activate WIND_MINUS_CURRENT to compute the effective winds by subtracting the surface ocean currents.
You need to be sure that the sign of the shortwave and longwave is correct into the ocean. Atmospheric models and data may have the opposite sign.
Thank you so much.
It is important to provide high-time resolution input data for simulation. I am not sure whether it is necessary for a climatology case. Actually, I hope to use this model to simulate the climatology condition of East China Sea, then aim to project the future sea surface height under global warming scenarios. I am afraid it maybe hard for me to get so frequent data in the future projection step.
Re: cppdefs for BULK_FLUX
When checked my input fields, I find another possible mistake.
As arango said
It seems that the Romstools make_bulk.m has misused the outgoing longwave radiation as net longwave radiation. Next what should I do, to find other net longwave radiation data for the make_bulk.m function to write correct lwrad_down and lwrad? or change some cppdefs in .h file?
As arango said
I find my input fileds the lwrad_down (downwelling longwave radiation flux) and lwrad (net longwave radiation flux) which written using Romstools make_bulk.m function maybe wrong. This function reads COADS longrad.cdf data to use directly as lwrad, actually COADS longrad.cdf long name is outgoing longwave radiation,Then lwrad_down is calculated byactivate LONGWAVE_OUT and provide downward longwave radiation so bulk_flux will subtract the outgoing IR by using ROMS surface temperature (K), infrared emissivity, and Stefan-Boltzmann constant.
Code: Select all
lwup=emiss_lw.*sigmaSB.*((sst+CtoK).^4);nc{'lwrad_down'}(tindex,:,:)=-(radlw-lwup);
It seems that the Romstools make_bulk.m has misused the outgoing longwave radiation as net longwave radiation. Next what should I do, to find other net longwave radiation data for the make_bulk.m function to write correct lwrad_down and lwrad? or change some cppdefs in .h file?
Re: cppdefs for BULK_FLUX
I was recently asked to look into the future projection business. One can download CMIP5 results from any number of different models. For CMIP6, some of the early pre-industrial runs are out there now, but only the French have results for a future run so far (searching for three-hourly). The web portals: CMIP5 and CMIP6. The variables I would use are called huss (surface specific humidity), pr (precip), prsn (snowfall), ps (surface pressure), rlds (downward longwave), rsds (shortwave), tas (surface air temp), uas (surface u-wind), vas (surface v-wind). Beware the units! Pressure is in Pascals, Tair in Kelvins. I don't use SST or dQdSST.
The CORE or CORE2 fields should be available for download as well, used for driving the hindcast portions of these simulations - I think it is six-hourly. I gave up many years ago on monthly forcings.
The CORE or CORE2 fields should be available for download as well, used for driving the hindcast portions of these simulations - I think it is six-hourly. I gave up many years ago on monthly forcings.
Re: cppdefs for BULK_FLUX
Now I begin to doubt my simulation steps. My task is to simulate sea level height in future 50 or 100 years. So I separate it into three steps:
First, simulating the climatology condition for my study area until model is stable. Forcing fields in this step are come from climatology datasets.
Second, simulating the history period forced by CMIP5 history output data. This step use the above last stable output as initial input.
Third, simulating the future condition based on CMIP5 future output data.
Are these steps right? I consider CMIP5 because my task began before CMIP6 is open. If it is OK, I will change to use CMIP6 later. I have used monthly data,since previously I do not pay attention to the fact the resolution of data can impact on simulation results so much.
First, simulating the climatology condition for my study area until model is stable. Forcing fields in this step are come from climatology datasets.
Second, simulating the history period forced by CMIP5 history output data. This step use the above last stable output as initial input.
Third, simulating the future condition based on CMIP5 future output data.
Are these steps right? I consider CMIP5 because my task began before CMIP6 is open. If it is OK, I will change to use CMIP6 later. I have used monthly data,since previously I do not pay attention to the fact the resolution of data can impact on simulation results so much.
Re: cppdefs for BULK_FLUX
Remember ROMS is a Boussinesq model so there will be no sea level rise due to thermal expansion. You will have to diagnose that separately offline, or provide that influence through open boundary conditions on sea level. Your approach will only capture the effects of local changes in circulation on the local mean dynamic topography.My task is to simulate sea level height in future 50 or 100 years. First, simulating the climatology condition for my study area until model is stable. ... Second, simulating the history period forced by CMIP5 history output data. ... Third, simulating the future condition based on CMIP5 future output data.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
Re: cppdefs for BULK_FLUX
I would simply skip the first step. No problem using CMIP5 - it has the RCP scenarios we have all heard about.First, simulating the climatology condition for my study area until model is stable. Forcing fields in this step are come from climatology datasets.
Second, simulating the history period forced by CMIP5 history output data. This step use the above last stable output as initial input.
Third, simulating the future condition based on CMIP5 future output data.
You mention frequency of forcing. Not only do I want to resolve the storm scale of changes in winds (and inertial motions), but I would ideally like higher spacial resolution too. One problem with using these products near the coast is that a grid cell the atmosphere things of as land could be over your water and that can cause some weird heating/cooling/upwelling effects. We use a code called sosie to extrapolate ocean values into the land of our forcing fields before we let ROMS interpolate to our grid.
Re: cppdefs for BULK_FLUX
Thank all you for giving valuable guides.
Re: cppdefs for BULK_FLUX
Recently I simulate the model under CMIP6 forcing, there are a question about the TIME_REF.
The Calendar for CMIP6 downloaded variables is "365 days", however that is "365.25days" for TIME_REF = 0 in ROMS .in file。
what should do to match the ROMS calendar and CMIP6 calendar?
I would really appreciate for your help.
The Calendar for CMIP6 downloaded variables is "365 days", however that is "365.25days" for TIME_REF = 0 in ROMS .in file。
what should do to match the ROMS calendar and CMIP6 calendar?
I would really appreciate for your help.