LONGWAVE_OUT

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
22jzhou
Posts: 6
Joined: Wed Jun 19, 2024 5:23 pm
Location: Shantou University

LONGWAVE_OUT

#1 Unread post by 22jzhou »

My simulation results are showing a high temperature. If I want to define something in the Surface forcing section of the .h file, can I add #LONGWAVE_OUT to my existing setup? I added lwrad to my forcing file and included #LONGWAVE_OUT in the .h file, but my a.dat file doesn't show LONGOUT_OUT. What could be the problem?
Here’s what my existing .h settings look like:
/***************** Model dynamics */
#define SOLVE3D
#define UV_ADV
#define UV_COR
#define UV_QDRAG
#define DJ_GRADPS

/************ Grid configuration */
#define MASKING
#define SPHERICAL
#define CURVGRID


/**** Mixing ********************/
#define TS_DIF2
#define MIX_GEO_TS
#define UV_VIS2
#define MIX_S_UV
#define MY25_MIXING
#define DIFF_GRID
#define VISC_GRID
#define TS_SMAGORINSKY
#define UV_SMAGORINSKY

/*#define LMD_MIXING*/

# ifdef MY25_MIXING
# define KANTHA_CLAYSON
# define N2S2_HORAVG
# define RI_SPLINES
# endif
# ifdef LMD_MIXING
# define LMD_RIMIX
# define LMD_CONVEC
# define LMD_SKPP
# define LMD_BKPP
# define LMD_NONLOCAL
# define LMD_DDMIX
# define RI_SPLINES
# endif

/**** Equation of State *********/
#define NONLIN_EOS
#define SPLINES_VDIFF
#define SPLINES_VVISC
#define SALINITY

/*************** Surface Forcing */
# define SOLAR_SOURCE
# define QCORRECTION
# define DIURNAL_SRFLUX
#LONGWAVE_OUT

/************** Other options ***/
#define RADIATION_2D
#define AVERAGES
#define ANA_BTFLUX
#define ANA_BSFLUX
#define LIMIT_BSTRESS
/*#define LIMIT_VVISC
#define LIMIT_VDIFF*/
# define WTYPE_GRID
# define ANA_WTYPE
/*#define ANA_SPONGE*/
/*#define ANA_SMFLUX*/
/*#define ANA_SMFLUX*/
/*#define ANA_STFLUX*/
/*#define ANA_SSFLUX*/
/*#define ANA_SRFLUX*/

/******** Tide ************/

# define RAMP_TIDES
# define SSH_TIDES
# define UV_TIDES
# define ADD_M2OBC
# define ADD_FSOBC



/* nudging the time in *.in shall be set */

#undef OUT_DOUBLE
#define RST_SINGLE

/*#define DIAGNOSTICS_UV*/


/******* FENNEL ecological model setting********/

/*# define BIO_FENNEL*/
/*# define DENITRIFICATION*/
/*# define BIO_SEDIMENT*/
/*# define ANA_SPFLUX*/
/*# define ANA_BPFLUX*/

/*# define ANA_CLOUD*/

/*# define DIAGNOSTICS_BIO*/

User avatar
wilkin
Posts: 922
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: LONGWAVE_OUT

#2 Unread post by wilkin »

#define LONGWAVE_OUT is an option to compute outgoing (upward) longwave radition based on model SST. One would never specify upward longwave separately.
This post might be helpful: https://www.myroms.org/forum/viewtopic. ... OUT#p25453
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
lfelipem
Posts: 5
Joined: Thu Aug 15, 2013 1:54 pm
Location: Federal University of Bahia
Contact:

Re: LONGWAVE_OUT

#3 Unread post by lfelipem »

I recently had some problems with downward longwave radiation and downward shortwave radiation when creating the forcing fields for the ECMWF model, and I noticed that the times added up and the values gradually increased over time.

The solution was to make up the difference between one day and the previous day. This solved my problem with the rising temperatures.

I suggest you check your atmospheric forcing values. It should help.

User avatar
wilkin
Posts: 922
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: LONGWAVE_OUT

#4 Unread post by wilkin »

When using radiation data from ECMWF (or any meteorological model analysis) pay attention to the units.

If they are not Watts m-2 but Joules m-2 then they are accumulated over a time interval
https://codes.ecmwf.int/grib/param-db/147
which might be 3, 6 or even 9 up to 12 hours from the start of the forecast. This is why they appear to grow over time until they reset at the next accumulation interval. If the data are reported multiple times during the accumulation the logic to convert Joules m-2 to Watts m-2 is a bit tortuous, but straightforward.

You can't just divide all data by the total accumulation interval because what you effectively have is

F(3 hours) = integral_t=0^t=3 Q dt
F(6 hours) = integral_t=0^t=6 Q dt

so to get the average flux in the first interval it's

Qbar(at 1.5 hours) = F(3 hours)/3 hours
Qbar(at 4.5 hours) = (F(6hours-F(3 hours))/3 hours
etc ...
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
lfelipem
Posts: 5
Joined: Thu Aug 15, 2013 1:54 pm
Location: Federal University of Bahia
Contact:

Re: LONGWAVE_OUT

#5 Unread post by lfelipem »

Perfect, Wilkin.

Maybe I misspoke. But that's what I ended up doing to get the right values for the simulation.

22jzhou
Posts: 6
Joined: Wed Jun 19, 2024 5:23 pm
Location: Shantou University

Re: LONGWAVE_OUT

#6 Unread post by 22jzhou »

wilkin wrote: Mon Sep 02, 2024 4:03 pm When using radiation data from ECMWF (or any meteorological model analysis) pay attention to the units.

If they are not Watts m-2 but Joules m-2 then they are accumulated over a time interval
https://codes.ecmwf.int/grib/param-db/147
which might be 3, 6 or even 9 up to 12 hours from the start of the forecast. This is why they appear to grow over time until they reset at the next accumulation interval. If the data are reported multiple times during the accumulation the logic to convert Joules m-2 to Watts m-2 is a bit tortuous, but straightforward.

You can't just divide all data by the total accumulation interval because what you effectively have is

F(3 hours) = integral_t=0^t=3 Q dt
F(6 hours) = integral_t=0^t=6 Q dt

so to get the average flux in the first interval it's

Qbar(at 1.5 hours) = F(3 hours)/3 hours
Qbar(at 4.5 hours) = (F(6hours-F(3 hours))/3 hours
etc ...
Hello! Thank you for your response. I checked, and my units are Watts m-2. The simulated temperature has been consistently too high. I've tried changing the mixing scheme, boundary conditions, the wtype, shortwave radiation, and so on, but none of these have helped solve the problem. I'd like to ask you about this issue.




继续聊天
😘 你喜欢这个扩展吗?
25
升级

User avatar
wilkin
Posts: 922
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: LONGWAVE_OUT

#7 Unread post by wilkin »

If you literally have the CPP defs you posted earlier ...
/*************** Surface Forcing */
# define SOLAR_SOURCE
# define QCORRECTION
# define DIURNAL_SRFLUX
#LONGWAVE_OUT
then you do not have LONGWAVE_OUT defined, because there is no #define

Be careful with # define DIURNAL_SRFLUX. If the swrad data you provide are not daily (or longer) averages, but resolve the diurnal cycle (e.g. you downloaded 3-hourly radiation from ECMWF) then DIURNAL_SRFLUX will roughly double the radiation. I have posted about this before.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

22jzhou
Posts: 6
Joined: Wed Jun 19, 2024 5:23 pm
Location: Shantou University

Re: LONGWAVE_OUT

#8 Unread post by 22jzhou »

wilkin wrote: Wed Sep 04, 2024 3:19 pm If you literally have the CPP defs you posted earlier ...
/*************** Surface Forcing */
# define SOLAR_SOURCE
# define QCORRECTION
# define DIURNAL_SRFLUX
#LONGWAVE_OUT
then you do not have LONGWAVE_OUT defined, because there is no #define

Be careful with # define DIURNAL_SRFLUX. If the swrad data you provide are not daily (or longer) averages, but resolve the diurnal cycle (e.g. you downloaded 3-hourly radiation from ECMWF) then DIURNAL_SRFLUX will roughly double the radiation. I have posted about this before.
Hello, the swrad I provided is the monthly average. Do I need to modify my .h file?

Post Reply