Selecting proper nudging parameter values

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
lcbernardo
Posts: 59
Joined: Wed Oct 01, 2014 8:57 pm
Location: Tokyo Institute of Technology

Selecting proper nudging parameter values

#1 Post by lcbernardo » Mon Jun 11, 2018 5:33 am

I am now running a simulation for the southernmost Ryukyu Islands in Japan, forced mainly by Global HYCOM, tides, and an atmospheric model. And to test the model performance, I have been comparing time-series outputs to field observations of temperature. And although there is reasonable reproduction of long term trends, there are shorter duration features that the model could not seem to capture correctly. I have been performing some tuning of the parameters, and I noticed that varying the nudging parameters (especially TNUDG, M3NUDG, and OBCFAC) has resulted in notable differences in the model output, and hence I'd like to ask for advice how to properly set them.

I'm not sure if I understand correctly, but will using small values (TNUDG and M3NUDG of 1 day or less, and an OBCFAC of 1) result in a stronger imposition of the boundary conditions? Like perhaps approaching clamped conditions? And are there any kinds of rules of thumb to set such values, or is it mostly case to case? I would greatly appreciate any help!

My current LBC setting is:

LBC(isFsur) == Cha Cha Cha Cha ! free-surface
LBC(isUbar) == Fla Fla Fla Fla ! 2D U-momentum
LBC(isVbar) == Fla Fla Fla Fla ! 2D V-momentum
LBC(isUvel) == RadNud RadNud RadNud RadNud ! 3D U-momentum
LBC(isVvel) == RadNud RadNud RadNud RadNud ! 3D V-momentum
LBC(isMtke) == Gra Gra Gra Gra ! mixing TKE

LBC(isTvar) == RadNud RadNud RadNud RadNud \ ! temperature
RadNud RadNud RadNud RadNud ! salinity


And in my *.h file, I have set:

#define UV_ADV
#define UV_COR
/*#define UV_U3ADV_SPLIT*/
/*#define UV_C2ADVECTION*/
/*#define UV_C4ADVECTION*/
/*#define UV_SADVECTION*/
#define UV_VIS2
/*#define UV_VIS4*/
#define UV_SMAGORINSKY
#define TS_DIF2
#define TS_SMAGORINSKY

/*#define TS_U3ADV_SPLIT*/
/*#define TS_C4HADVECTION*/
#define TS_U3HADVECTION
/*#define TS_C2HADVECTION*/
/*#define TS_C2VADVECTION*/
#define TS_C4VADVECTION
/*#define TS_SVADVECTION*/
/*#define TS_MPDATA*/
/*#define TS_DIF2*/
/*#define TS_DIF4*/

#define MIX_S_UV
/*#define MIX_GEO_UV*/
#define MIX_S_TS
/*#define MIX_GEO_TS*/
/*#define MIX_ISO_TS*/

#undef ANA_GRID
#define MASKING


#define NONLIN_EOS
#define SALINITY
#define ATM_PRESS

/*#define PJ_GRADPQ4 */
#define DJ_GRADPS
#define SOLVE3D

/*#define SPLINES*/
/*#define RI_HORAVG*/
/*#define RI_VERAVG*/

#define WET_DRY


/*** Option for Boundary condition ***/
#define RADIATION_2D

/*** Option for tidal forcing ***/
#define SSH_TIDES
#define UV_TIDES
/*#define RAMP_TIDES*/
#define ADD_FSOBC
#define ADD_M2OBC

/*#define AVERAGES*/

/*#define ANA_INITIAL*/
/*#define ANA_FSOBC*/
/*#define ANA_M2OBC*/
/*#define ANA_TOBC*/

#define SOLAR_SOURCE

#define BULK_FLUXES
#ifdef BULK_FLUXES
# define LONGWAVE
# define EMINUSP
# define COOL_SKIN
/*# define ANA_CLOUD*/
/*# define ANA_HUMID*/
/*# define ANA_PAIR*/
/*# define ANA_TAIR*/
/*# define ANA_RAIN*/
/*# define ANA_WINDS*/
# define ANA_SRFLUX
# define ALBEDO
/*# define LOCAL_TIME +9.0*/
/*# define DIURNAL_SRFLUX*/
#else
# define ANA_SMFLUX
# define ANA_STFLUX
#endif

/*#define DIAGNOSTICS_UV*/
/*#define DIAGNOSTICS_TS*/

/*** submarine groundwater discharge ***/

/*#define SGD_ON*/ /*Original CPP flag */

/*** waves-ocean (SWAN/ROMS) two-way coupling. ***/

/*#define SWAN_COUPLING*/
/*#define NEARSHORE_MELLOR08*/
/*#define SVENDSEN_ROLLER*/
#ifdef SWAN_COUPLING
# define MCT_LIB
#endif
/*#define AIR_OCEAN*/

/* define only one of the following 5 */
#define UV_LOGDRAG
/*#define UV_QDRAG*/
/*#define MB_BBL*/
/*#define SG_BBL*/
/*#define SSW_BBL*/

#ifdef MB_BBL
/*# define MB_CALC_ZNOT*/
#endif

#ifdef SSW_BBL
/*# define SSW_CALC_ZNOT*/
# define SSW_LOGINT
#endif
#define LIMIT_BSTRESS


#ifdef SOLVE3D

/* define only one of the following 4 */
/*# define BVF_MIXING*/
# define GLS_MIXING
/*# define MY25_MIXING*/
/*# define LMD_MIXING*/

# if defined GLS_MIXING
/*# define CRAIG_BANNER*/
# define KANTHA_CLAYSON
/*# define CANUTO_A*/
/*# define CANUTO_B*/
/*# define K_C4ADVECTION*/
/*# define K_C2ADVECTION*/
/*# define N2S2_HORAVG*/
/*# define ZOS_HSIG*/
/*# define TKE_WAVEDISS*/
# endif

# if defined MY25_MIXING
# define KANTHA_CLAYSON
# undef CANUTO_A
/*# define K_C4ADVECTION*/
# define N2S2_HORAVG
# endif

# ifdef LMD_MIXING
# define LMD_RIMIX
# define LMD_CONVEC
# define LMD_SKPP
# define LMD_BKPP
# define LMD_NONLOCAL
# endif


/*# define SEDIMENT*/
# ifdef SEDIMENT
# define SUSPLOAD
# undef BEDLOAD_SOULSBY
# undef BEDLOAD_MPM
/*# define SED_MORPH*/
# endif
# if defined SEDIMENT || defined SG_BBL || defined MB_BBL || defined SSW_BBL
# define ANA_SEDIMENT
# define REVER_SEDIMENT
# endif
# define ANA_BPFLUX
# define ANA_BTFLUX
# define ANA_BSFLUX
# define ANA_SPFLUX

#endif

User avatar
kate
Posts: 3683
Joined: Wed Jul 02, 2003 5:29 pm
Location: IMS/UAF, USA

Re: Selecting proper nudging parameter values

#2 Post by kate » Mon Jun 11, 2018 6:21 am

The thinking behind RadNud is that you want incoming signals to come in from the boundary conditions, but you want outgoing signals to leave the domain without reflection. The nudging timescales should therefore be short on incoming signals, long on outgoing signals - because the boundary conditions won't generally match the outgoing signals. So you pick values that work better than others.

So then if things aren't going as well as you'd like, you can resort to a stronger hammer with nudging to a climatology. We use a monthly climatology, so we want this nudging to be less strong than the strong nudging on the incoming boundary conditions if those are more frequent in time (and you want frequent boundary conditions if you can get them).

lcbernardo
Posts: 59
Joined: Wed Oct 01, 2014 8:57 pm
Location: Tokyo Institute of Technology

Re: Selecting proper nudging parameter values

#3 Post by lcbernardo » Wed Jun 13, 2018 5:05 am

Thank you for the explanation on the use of nudging and the implications for the model output. I'll think about the points you mentioned to help guide me through the numerical experiments I'm conducting.

Also, I'd like to get a more quantitative sense of "strong" and "weak" nudging in terms of TNUDG, ZNUDG, M2NUDG, M3NUDG, and OBCFAC, for example. If nudging to a monthly climatology for example, should the number of days in the nudging time scales be set to a higher number, perhaps in the range 10 to 100, as opposed to a daily/subdaily boundary forcing?

Regarding another point, is the choice of the proper TNUDG, ZNUDG, M2NUDG, M3NUDG, and OBCFAC values also influenced by the vertical mixing scheme used? I have been using mainly GLS_MIXING and have been testing the k-kl, k-epsilon, and k-omega schemes. I'd be happy for any help or advice.

User avatar
kate
Posts: 3683
Joined: Wed Jul 02, 2003 5:29 pm
Location: IMS/UAF, USA

Re: Selecting proper nudging parameter values

#4 Post by kate » Wed Jun 13, 2018 5:32 am

My Arctic case is in the ROMS manual. I have a nudging band of 20 grid points, with the strongest nudging right at the boundary of 30 days. I don't let that override the boundary nudging timescales which are 360 days for outflow and 3 days for inflow. That is strong enough to disrupt the along-boundary flow which likes to develop without the climatology nudging.

lcbernardo
Posts: 59
Joined: Wed Oct 01, 2014 8:57 pm
Location: Tokyo Institute of Technology

Re: Selecting proper nudging parameter values

#5 Post by lcbernardo » Thu Jun 14, 2018 2:03 am

Thank you for sharing the link to the manual, and for explaining the choices for your Arctic case. I see. So I guess selecting the parameter values is in a large part application-dependent, and you need to work towards the most realistic solution possible. I greatly appreciate your help!

Post Reply