Helpful printout info: 1) gross check for d01 time step, 2) current and sim start date in printout

[davegill]

TYPE: new feature

KEYWORDS: time_step, dx, cfl, ratio, current date, simulation start date

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Users accidentally forget to change the model time step when adjusting
the grid distance. It sometimes takes the model a while to become unstable
enough to die, and it is not always easy to determine why the model stopped.
However, we can't provide a simple "if the time step ratio > 6,
then always stop", because ideal cases would be unintentionally
impacted. Likely there are also real-data cases, maybe LES-scale or urban heat
island studies, where a user could realistically get a stable solution at a dt/dx ratio > 6.

Solution:
For domain 1 only, for real data cases only, for explicit dt cases (no adaptive dt):
Check to see if the time step ratio is greater than a prescribed value (default = 6),
which is defined in the Registry as a namelist option. If so, and the user's time does exceed
the provided limit, then stop immediately. If the user is running a special scenario
where a time step ratio of 8 (for example) would be acceptable, there is an option to
make that workable at run-time.

Whether a user specifies a questionable dt ratio or not, always output a few important nml
settings up towards the top of the model printout (right after the max map factor).

Additionally, to help the users, add the start date and simulation start date into the print-out
that is at the very beginning of the WRF model standard out.

LIST OF MODIFIED FILES:
M dyn_em/start_em.F
M share/input_wrf.F
M Registry/Registry.EM_COMMON

ISSUE:
Fixes #772 "time_step check in the code"

• The model now always outputs the following for real-data cases:

 D01: Time step                              =    320.000000      (s)
 D01: Grid Distance                          =    30.0000000      (km)
 D01: Grid Distance Ratio dt/dx              =    10.6666670      (s/km)
 D01: Ratio Including Maximum Map Factor     =    10.9600906      (s/km)
 D01: NML defined reasonable_time_step_ratio =    8.00000000

TESTS CONDUCTED:

• With a reasonable time step, the model processes as normal.

 &domains
 time_step                           = 180,
 dx                                  = 30000, 10000,  3333.33,
 dy                                  = 30000, 10000,  3333.33,
 /

• With a time step that is too large for a real-data case.

 &domains
 time_step                           = 320! 180,
 dx                                  = 30000, 10000,  3333.33,
 dy                                  = 30000, 10000,  3333.33,
 /

The time step is probably too large for this grid distance, reduce it.
 If you are sure of your settings, set reasonable_time_step_ratio in namelist.input >    10.9600906
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:     335
--- ERROR: Time step too large
-------------------------------------------

• With a real data case, and a ratio < than the namelist ratio, the model runs (for just a bit):

 &domains
 time_step                           = 320
 reasonable_time_step_ratio          = 12.
 dx                                  = 30000, 10000,  3333.33,
 dy                                  = 30000, 10000,  3333.33,

• With a time step ratio greater than 10 for the LES case, the model integrates fine.

 &domains
 time_step                           = 1,
 dx                                  = 90,    50,    16.6667,
 dy                                  = 90,    50,    16.6667,

[davegill]

@weiwangncar @dudhia
With idealized cases, should we make this larger? Should we also use the grid%time_step_sound? We could make the max dt ratio be a namelist variable. This is supposed to be a gross check, so I am not sure how much effort we should put into this effort.

[dudhia]

Yes, I think we should only apply this test to real cases if possible. Some idealized cases can with with 10*dx. The automatic sound step calculation would be advised and is default.

…

On Wed, Feb 13, 2019 at 6:22 AM Dave Gill ***@***.***> wrote: @weiwangncar <https://github.com/weiwangncar> @dudhia <https://github.com/dudhia> With idealized cases, should we make this larger? Should we also use the grid%time_step_sound? We could make the max dt ratio be a namelist variable. This is supposed to be a *gross* check, so I am not sure how much effort we should put into this effort. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGf_A28_eBqqGmqmUar3j9s5-96nT4rks5vMxSFgaJpZM4a31Yw> .

[weiwangncar]

I'd agree. No need to add more namelist - this is just a rough check. Though I wonder if a user has grossly wrong time step, it may be easier to detect the error. If the user has 8xDX time step, it may take longer for model to blow up, is this helping or not? In any case, a check and a print could be helpful ...

…

On Wed, Feb 13, 2019 at 7:10 AM dudhia ***@***.***> wrote: Yes, I think we should only apply this test to real cases if possible. Some idealized cases can with with 10*dx. The automatic sound step calculation would be advised and is default. On Wed, Feb 13, 2019 at 6:22 AM Dave Gill ***@***.***> wrote: > @weiwangncar <https://github.com/weiwangncar> @dudhia > <https://github.com/dudhia> > With idealized cases, should we make this larger? Should we also use the > grid%time_step_sound? We could make the max dt ratio be a namelist > variable. This is supposed to be a *gross* check, so I am not sure how > much effort we should put into this effort. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#784 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/ARGf_A28_eBqqGmqmUar3j9s5-96nT4rks5vMxSFgaJpZM4a31Yw > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMHfkIkwiVLxLqrLum6uazPUz23qY-Oeks5vMx-ZgaJpZM4a31Yw> .

[dudhia]

It could be just the clear message without a fatal error noting that dt > 10 dx. On Wed, Feb 13, 2019 at 7:17 AM weiwangncar <notifications@github.com> wrote:

…

I'd agree. No need to add more namelist - this is just a rough check. Though I wonder if a user has grossly wrong time step, it may be easier to detect the error. If the user has 8xDX time step, it may take longer for model to blow up, is this helping or not? In any case, a check and a print could be helpful ... On Wed, Feb 13, 2019 at 7:10 AM dudhia ***@***.***> wrote: > Yes, I think we should only apply this test to real cases if possible. > Some idealized cases can with with 10*dx. The automatic sound step > calculation would be advised and is default. > > On Wed, Feb 13, 2019 at 6:22 AM Dave Gill ***@***.***> > wrote: > > > @weiwangncar <https://github.com/weiwangncar> @dudhia > > <https://github.com/dudhia> > > With idealized cases, should we make this larger? Should we also use the > > grid%time_step_sound? We could make the max dt ratio be a namelist > > variable. This is supposed to be a *gross* check, so I am not sure how > > much effort we should put into this effort. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#784 (comment)>, or > mute > > the thread > > < > https://github.com/notifications/unsubscribe-auth/ARGf_A28_eBqqGmqmUar3j9s5-96nT4rks5vMxSFgaJpZM4a31Yw > > > > . > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#784 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AMHfkIkwiVLxLqrLum6uazPUz23qY-Oeks5vMx-ZgaJpZM4a31Yw > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGf_BprV6r590erm7A1PI7_xAzuBRINks5vMyFggaJpZM4a31Yw> .

[davegill]

@weiwangncar @dudhia
Folks,

1. It is not easy to determine if this is an ideal run or not, we have to make a number of assumptions. By the time we have all of the info, we are into the start_em.F file (past check_a_mundo with nml entries, past input_wrf with metadata information).
2. I am not all that keen on only having a warning at the beginning of the print out. I doubt that helps most users who make this mistake. When the model fails, we rarely look up at the top of the model standard out. A compromise: what if we do a fatal error if dt ratio > 12, and print a warning if the dt ratio is only > 8?

[dudhia]

There may be some applications like LES where they can get away with > 12*dx, so it could be a condition that only is fatal for dt > 10s for example, i.e dt > 10*dx and dt > 10s. Maybe we can somehow provide an override option too. Jimy

…

On Wed, Feb 13, 2019 at 2:40 PM Dave Gill ***@***.***> wrote: @weiwangncar <https://github.com/weiwangncar> @dudhia <https://github.com/dudhia> Folks, 1. It is not easy to determine if this is an ideal run or not, we have to make a number of assumptions. By the time we have all of the info, we are into the start_em.F file (past check_a_mundo with nml entries, past input_wrf with metadata information). 2. I am not all that keen on only having a warning at the beginning of the print out. I doubt that helps most users who make this mistake. When the model fails, we rarely look up at the top of the model standard out. A compromise: what if we do a fatal error if dt ratio > 12, and print a warning if the dt ratio is only > 8? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGf_B-9Od3f6TiuYaFsjoj0LOX6Ks6Lks5vM4kmgaJpZM4a31Yw> .

[cmattocks]

I remember developing something similar for the WRF Domain Wizard (WDW):

A boolean isNamelistValid() function is used by the NamelistAnalyzer class to validate the entire contents of the namelist. All errors are stored in a mutable structure (an auto-sorting Java TreeMap) within an ErrorInfo object. If the isNamelistValid() method returns false, the ErrorInfo object is interrogated to find the problematic line number(s) in the namelist, as well as the error message(s) that indicate what is wrong and how to fix the problem. The WDW GUI pops up an error message dialog box to alert the user of any problems.

A numerical stability checker, which analyzes the grid spacing and time step at all grid nesting levels in the WRF namelist.input file to prevent the submittal of simulations that are likely to go unstable, was developed and incorporated into the WDW code base. It was decided to initially employ practical "rules of thumb" in this validation function, rather than implement complicated CFL criteria based on the numerical schemes selected, their accuracy, the numerical order of the computational viscosity chosen, etc. For the WRF-ARW (WRF-NMM) core, the rule of thumb is to set the time step in seconds to about 4-6 (2.25) times the horizontal resolution (in km).

A demonstration of its capabilities is shown in Fig. 6. After a user alters the horizontal grid spacing and/or time step in the Namelist Editor and saves the namelist.input file, he/she can press the "Validate" button to check for configuration problems. In the example shown, a user has attempted to use a time step of 60 seconds for a 2.7 km WRF-ARW simulation. In this case, the algorithm alerts the user ands uggests that a time step of 16.2 seconds should be used to maintain stability. After the user follows this recommendation and modifies the value for the variable time_step in the namelist.input file, saves this configuration, and presses the "Validate" button once again, the Java function integralTimeStep() recommends that the user adjust the time step to 16.1435 seconds if he/she wants an integral number of time steps per hour, in this case 223.

[davegill]

@dudhia @weiwangncar
Folks,
I think that I have addressed most concerns for this gross time-step error test:

1. Only real-data cases are impacted, ideal cases are by-passed
2. A ratio of 10 is the default, any dt/dx >10 fails
3. A run-time option allows a user to over-ride this ratio setting (not intended for the namelist)

[weiwangncar]

Perhaps we could add a recommended time step?

[weiwangncar]

@davegill @dudhia I'm concerned that if someone used 8xDX, and model runs for a long time and then blows up. Would this make it harder to diagnose?

[dudhia]

Perhaps a separate warning (not error) could be printed for > 6*dx

…

On Mon, Mar 11, 2019 at 3:21 PM weiwangncar ***@***.***> wrote: @davegill <https://github.com/davegill> @dudhia <https://github.com/dudhia> I'm concerned that if someone used 8xDX, and model runs for a long time and then blows up. Would this make it harder to diagnose? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGf_IgYxhjelQ-0sjs8w7AkSoWM7pewks5vVsjBgaJpZM4a31Yw> .

[dudhia]

I think printing "reasonable" as 8*dx may be misleading. We have to think of another way to describe this limit.

[davegill]

@weiwangncar @dudhia
Wei and Jimy,
Would you please provide a review for the gross time step check.