Getting over vertical CFL breaches

Arty · Apr 3, 2024

Hello,

I'm having trouble getting over CFL breaches in domain d01 of a double-way-nested simulation. In the table below are shown some relevant information (i.e. : Config name, Date, Max CFL at i,j,k as well as CFL and w values) :

Config./Month	Date	i	j	k	CFL	w
WS_KF_RRTMG_1_D_execute/20131101_20131130/	2013-11-18_06:38:40	120	14	26	2.000419	-0.4045501
WS_KF_RRTMG_2_D_execute/20131101_20131130/	2013-11-28_11:04:00	29	23	28	2.672609	12.23001
WS_KF_RRTMG_2_D_execute/20131101_20131130_CFL/	2013-11-28_07:28:48	37	26	29	43.43441	NaN
WS_KF_RRTMG_2_A_execute/20131101_20131130/	2013-11-08_08:44:59+/	50	57	2	7.971124	14.43325
WS_KF_RRTMG_2_A_execute/20131101_20131130/	2013-11-08_08:44:59+/	57	58	2	70.72917	169.2141
WS_KF_RRTMG_2_A_execute/20131101_20131130/	2013-11-08_08:44:59+/	61	57	2	16.67289	48.04175
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/	2013-11-08_10:10:51+/	50	57	2	95.61411	104.5045
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/	2013-11-08_10:10:51+/	52	58	2	94.22695	-185.2215
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/	2013-11-08_10:10:51+/	61	57	2	842.9833	3768.595
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/	2013-11-28_09:08:00	19	14	26	6.759264	-10.15765
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/	2013-11-18_06:36:40	120	14	26	2.000036	-0.4398801
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/	2013-11-18_13:24:00	112	51	26	2.008152	4.481654
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_30s/	2013-11-28_10:13:00	30	20	28	2.574980	21.10369
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_36s/	2013-11-28_08:51:36	35	18	26	2.859098	5.297072
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_36s_EPSSM/	2013-11-27_18:18:00	18	39	26	2.640796	7.657585
WS_KF_RRTMG_1_A_execute/20131101_20131130/	2013-11-18_06:37:20	120	14	26	2.000382	-0.3832043

I noticed most of CFL maximum errors occur at 26th vertical level ; except when I use adaptive time-step (which revealed much less stable in my case).

Between configuration showing " 1 " or " 2 ", the SST input has been changed (I noticed inconsistencies in the first inputs and corrected it). The " A " or " D " stands for convection Activated or Deactivated (for domain d02 only ; always activated for domain d01).

If I succeeded running 3 years, having to lower temporarily and once in a while time-step when running with erroneous SST input (1), I cannot complete 3rd month 2013-11 simulation when using corrected SST (2). Nothing changed in the namelist - as shown below - except for the fact that I activated prec_acc :

Code:

dify WS_KF_RRTMG_2_D_execute/20131101_20131130/namelist.input WS_KF_RRTMG_1_D_execute/20131101_20131130/namelist.input
 time_step                           =30 ,              |     time_step                           =40 ,
 use_adaptive_time_step              = .false.,              <
 target_cfl                          = 1.2, 1.2, 1.2,          <
 target_hcfl                         = 0.84, 0.84, 0.84,      <
 max_step_increase_pct               = 50, 50, 51,          <
 starting_time_step                  = 36, 12, -1,          <
 starting_time_step_den              = 0,0,              <
 max_time_step                       = -1, -1, -1,          <
 max_time_step_den                   = 0,0,              <
 min_time_step                       = -1, -1, -1,          <
 min_time_step_den                   = 0,0,              <
 adaptation_domain                   = 1,              <
 bucket_mm                           = 1,              |     prec_acc_dt                         = 360.,360.,
 bucket_J                            = 3.6e6,              |     /
 prec_acc_dt                         = 60,   60,          <
/                                  <

I already activated w_damping (always on - see namelist attached) and tried increasing epssm from 0.1 to 0.5 without success. I'm wondering if there is anything else I could try except for lowering time-step from 40, to 36 and even 30 secons (because then computing time becomes way too long).

Thanks for your advice

William.Hatheway · Apr 13, 2024

Arty said:
Hello,

I'm having trouble getting over CFL breaches in domain d01 of a double-way-nested simulation. In the table below are shown some relevant information (i.e. : Config name, Date, Max CFL at i,j,k as well as CFL and w values) :

Config./Month
Date
i
j
k
CFL
w
WS_KF_RRTMG_1_D_execute/20131101_20131130/
2013-11-18_06:38:40
120
14
26
2.000419
-0.4045501
WS_KF_RRTMG_2_D_execute/20131101_20131130/
2013-11-28_11:04:00
29
23
28
2.672609
12.23001
WS_KF_RRTMG_2_D_execute/20131101_20131130_CFL/
2013-11-28_07:28:48
37
26
29
43.43441
NaN
WS_KF_RRTMG_2_A_execute/20131101_20131130/
2013-11-08_08:44:59+**/**
50
57
2
7.971124
14.43325
WS_KF_RRTMG_2_A_execute/20131101_20131130/
2013-11-08_08:44:59+**/**
57
58
2
70.72917
169.2141
WS_KF_RRTMG_2_A_execute/20131101_20131130/
2013-11-08_08:44:59+**/**
61
57
2
16.67289
48.04175
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/
2013-11-08_10:10:51+**/**
50
57
2
95.61411
104.5045
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/
2013-11-08_10:10:51+**/**
52
58
2
94.22695
-185.2215
WS_KF_RRTMG_2_A_execute/20131101_20131130_ADAPTIVE01/
2013-11-08_10:10:51+**/**
61
57
2
842.9833
3768.595
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/
2013-11-28_09:08:00
19
14
26
6.759264
-10.15765
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/
2013-11-18_06:36:40
120
14
26
2.000036
-0.4398801
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL/
2013-11-18_13:24:00
112
51
26
2.008152
4.481654
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_30s/
2013-11-28_10:13:00
30
20
28
2.574980
21.10369
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_36s/
2013-11-28_08:51:36
35
18
26
2.859098
5.297072
WS_KF_RRTMG_2_A_execute/20131101_20131130_CFL_36s_EPSSM/
2013-11-27_18:18:00
18
39
26
2.640796
7.657585
WS_KF_RRTMG_1_A_execute/20131101_20131130/
2013-11-18_06:37:20
120
14
26
2.000382
-0.3832043

I noticed most of CFL maximum errors occur at 26th vertical level ; except when I use adaptive time-step (which revealed much less stable in my case).

Between configuration showing " 1 " or " 2 ", the SST input has been changed (I noticed inconsistencies in the first inputs and corrected it). The " A " or " D " stands for convection Activated or Deactivated (for domain d02 only ; always activated for domain d01).

If I succeeded running 3 years, having to lower temporarily and once in a while time-step when running with erroneous SST input (1), I cannot complete 3rd month 2013-11 simulation when using corrected SST (2). Nothing changed in the namelist - as shown below - except for the fact that I activated prec_acc :

Code:

dify WS_KF_RRTMG_2_D_execute/20131101_20131130/namelist.input WS_KF_RRTMG_1_D_execute/20131101_20131130/namelist.input time_step =30 , | time_step =40 , use_adaptive_time_step = .false., < target_cfl = 1.2, 1.2, 1.2, < target_hcfl = 0.84, 0.84, 0.84, < max_step_increase_pct = 50, 50, 51, < starting_time_step = 36, 12, -1, < starting_time_step_den = 0,0, < max_time_step = -1, -1, -1, < max_time_step_den = 0,0, < min_time_step = -1, -1, -1, < min_time_step_den = 0,0, < adaptation_domain = 1, < bucket_mm = 1, | prec_acc_dt = 360.,360., bucket_J = 3.6e6, | / prec_acc_dt = 60, 60, < / <

I already activated w_damping (always on - see namelist attached) and tried increasing epssm from 0.1 to 0.5 without success. I'm wondering if there is anything else I could try except for lowering time-step from 40, to 36 and even 30 secons (because then computing time becomes way too long).

Thanks for your advice

What part of the world are you running this model over? Does it have steep topography?

Arty · Apr 13, 2024

William.Hatheway said:
What part of the world are you running this model over? Does it have steep topography?

I'm running it over Tahiti & Moorea islands, in French Polynesia, South Pacific. Despite these are quite mountainous volcanic islands, the topography is not so steep even at the resolution I'm working (2.333 km). Moreover, the max. CFL errors always occur far from the islands, over the ocean (except when adaptive time-step is used : then errors occur over the main island of Tahiti).

However, I should not that reducing time-step to 10s has done the trick (which exclude inputs data as cause for CFL errors), and the next month ran flawlessly back at a 40s time-step. I suppose I'll have to deal with it.

Ming Chen · Apr 15, 2024

Arty,
Your namelist.input looks fine to me. Would you please tell me what data you used to drive this case?

Arty · Apr 15, 2024

Ming Chen said:
Arty,
Your namelist.input looks fine to me. Would you please tell me what data you used to drive this case?

Hello Ming,

LBCs are made up of NDOWN processed wrfouts (21 km to 7 km horizontal resolution) ; doubled vertical refinement (32+1 to 64+1 vertical levels).
Surface inputs are made up of NCO/CDO-processed interpolation of the same previous run's wrfouts for SST and VEGFRA (the latter being constant over time). I did correct SST data as mentionned in first post, because I noticed errors (unnatural ponctual low values - see this post).

I had no trouble running another configuration of the model ; and the CFL crashes on this "KF" configuration have been overcome by reducing time-step to 10s for the crashing-month. It now ran on a 40s time-step for 3-4 other months already.

I'd be happy to understand that a little bit more if possible. Thank you.

Ming Chen · Apr 16, 2024

Arty,
CFL violation possibly occurs when (1) time step is too large, or (2) topography is high, or (3) input data is not physically reasonable. In some cases the model may manage to overcome the CFL violation before it crashes and run to the end successfully.
Without looking at all the details, it is hard for me to tell the exact reason for CFL violation in your case. It is always a nice try to reduce time step to overcome CFL violation.

Getting over vertical CFL breaches

Arty

Member

Attachments

William.Hatheway

Active member

Arty

Member

Ming Chen

Moderator

Arty

Member

Ming Chen

Moderator