Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

stop in Noah MP

epotter1

New member
I've been coming across problems with Noah MP in WRF, has anyone else had these issues?

The error file is attached here (it was actually rsl.error.0278) along with my namelist, but the error is:

Setvtz: problem with vtxbar1/3: 7 NaN NaN 42.5832520 0.500000000 1871.25427 720.000000
q, number, diam1,3(mm) = 3.86155821E-12 -2.50762096E-04 0.165096357 0.299999982
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 4644
STOP in Noah-MP
-------------------------------------------
MPICH ERROR [Rank 278]

I had a different error that also resulted in 'STOP in Noah-MP' when I compiled using a cray compiler, but everything was working fine with a gnu compiler until this. The same namelist options ran fine for a different time period, and this time period has run to completion with one set of physics options, but crashed in another 6 with different errors (but around the same time).

I'm struggling to work out whether this is a crash due to WRF or the HPC setup (I'm using ARCHER2). Any ideas or help would be much appreciated!
 

Attachments

  • namelist.input
    7.1 KB · Views: 3
  • rsl.error.0000
    191.2 KB · Views: 1
You specified an obsolete sfclay option:
sf_sfclay_physics = 91, 91, 91, 91,
Note that NoahMP may not be consistent with this old version of sfclay scheme.

Can you try the option below and let me know whether it works?
sf_sfclay_physics = 1, 1, 1, 1,
 
Hi, thanks very much for your suggestion. Unfortunately I ran into the same problem (at the same time) with sf_sfclay_physics=1. In the setup I'm using as a test case, this is happening at the first boundary input (6 hours into the run), although in a different WRF setup this has run for longer.
 

Attachments

  • namelist.input
    7.2 KB · Views: 3
This is a restart run and I am suspicious that your wrfrst files are somehow damaged. In your rsl file, it states that

**WARNING** Time in input file not equal to time on domain **WARNING**


**WARNING** Trying next time in file ...


Time in file: 2019-05-03_06:00:00


Time on domain: 2019-06-12_00:00:00
...

Those NaN value indicates that physics went wrong in this case.

Please double check your wrfrst files to make sure they are correct.
 
Hi, thanks for this suggestion. WRF can run for a number of days from these restart files before crashing, so I don't think there's an obvious problem with these. I assumed the **WARNING** notice is just saying the WRF runs through the times in wrflowinp before it hits the restart time? One run that is working fine (also with restarts) also has this warning.

I am running a chain of jobs with multiple restarts due to the computing time limit, and it runs through a few restart starts before crashing.

Thanks again for your ideas! I'm grateful for any ideas.
 
Top