WOULD GO OFF TOP: KF

Any issues with the actual running of the WRF.

WOULD GO OFF TOP: KF

Postby rgashrit » Tue Jul 08, 2008 4:15 am

Hai

I am working with WRFV3.0 on an IBM cluster. I see this runtime problem randomly on some day.
How to fix it??
*******************************************************
DYNAMICS OPTION: Eulerian Mass Coordinate
med_initialdata_input: calling input_model_input
STEPRA,STEPCU,STEPBL 11 2 1
WRF NUMBER OF TILES = 1
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 195 195 NaNQ 5000.000000
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 194 196 NaNQ 5000.000000
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 195 196 -NaNQ 5000.000000
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 196 196 NaNQ 5000.000000
*******************************************************
1. For 27 Km resolution I use the time step of 120s (I also tried with 90s).
rgashrit
 
Posts: 8
Joined: Mon Jun 30, 2008 11:46 pm

Re: WOULD GO OFF TOP: KF

Postby jimmyc » Tue Jul 08, 2008 12:20 pm

That problem is from the KFeta cumulus scheme. Others have gotten this error either from a bad lower boundary condition, the time step may be too long, or a bad lateral boundary condition. This problem may also be from other causes ... the previous wrf forum had a few people who experienced this but I dont know if those posts have been transferred to this forum yet.

where is i,j 195,196 ? at the lateral boundary? is it over the ocean?

Did the kfeta scheme spit out some text fortran files in the run directory?

with a 27 km grid you probably want to go lower than 90 second time steps: I typically use 3*dx or in your case on the order of 80 seconds or LOWER. try 60 seconds.

if you can output or post process the data just prior to the error, look at the sounding for that grid point and examine the parcel path. If KFeta has an equilibrium level above the model top, that is when the error is generated. so key things to look for are a superadiabatic layer in the low levels, from which cape should be abnormally large.

This error could also result if there are cfl errors and the grid scale vertical velocity is getting abnormally large.
The views expressed in this message do not necessarily reflect those of NOAA or the National Weather Service or the University of Oklahoma.
James Correia, Jr
jimmyc
 
Posts: 519
Joined: Tue Apr 15, 2008 1:10 am

Re: WOULD GO OFF TOP: KF

Postby rgashrit » Wed Jul 09, 2008 4:00 am

Dear James

I'll try your suggestion to plot a sounding using RIP for that location. This happens just after the start of the run. i.e., after the first wrfout file is written. There is a core dump and no other ascii file.

I must point out even with 60 sec I got the same result. Surprisingly, same run done on a CRAY machine had different problem. All along it featured huge number of points with cfl>2. With resuded time step to 90, 60 this number of grids came down. In this runs on CRAY I didn't come across the WOULD GO OFF TOP error.

raghu
rgashrit
 
Posts: 8
Joined: Mon Jun 30, 2008 11:46 pm

Re: WOULD GO OFF TOP: KF

Postby jimmyc » Wed Jul 09, 2008 10:10 am

well, if the cfl error is popping up prior to the would go off top problem, then most likely vertical velocity is becoming large and setting off the error message inside the KFeta cumulus scheme via the trigger function.

if this is happening at the start of the run, make sure the initial fields all look good. you can also output the data more frequent to see where the problem first arises.
The views expressed in this message do not necessarily reflect those of NOAA or the National Weather Service or the University of Oklahoma.
James Correia, Jr
jimmyc
 
Posts: 519
Joined: Tue Apr 15, 2008 1:10 am

Re: WOULD GO OFF TOP: KF_EAT_PARA I, J

Postby leonard » Fri Apr 03, 2009 8:04 pm

Hi jimmyc and rgashrit,

I have the same "KF_ETA_PARA I,J,DPTHMX,DPMIN" problem when I run WRF benchmark data set from http://www.mmm.ucar.edu/wrf/bench/. A namelist.input is provided in the data. How can I modify this namelist.input to solve the issue? Thanks in advance.

Below is the head of rsl.error.0000:

taskid: 0 hostname: d28n03
Quilting with 1 groups of 0 I/O tasks.
Namelist fdda not found in namelist.input. Using registry defaults for variables in fdda
Namelist dfi_control not found in namelist.input. Using registry defaults for variables in dfi_control
Namelist grib2 not found in namelist.input. Using registry defaults for variables in grib2
Ntasks in X 8 , ntasks in Y 8
WRF V3.0.1.1 MODEL
*************************************
Parent domain
ids,ide,jds,jde 1 425 1 300
ims,ime,jms,jme -4 60 -4 45
ips,ipe,jps,jpe 1 53 1 38
*************************************
DYNAMICS OPTION: Eulerian Mass Coordinate
med_initialdata_input: calling input_model_input
input_wrf: SIMULATION_START_DATE not available in input
will use head_grid start time from namelist
STEPRA,STEPCU,STEPBL 8 4 1
Timing for Writing wrfout_d01_2001-10-24_00:00:00 for domain 1: 524.95001 elapsed seconds.
Timing for processing lateral boundary for domain 1: 11.07000 elapsed seconds.
WRF NUMBER OF TILES = 1
Timing for main: time 2001-10-24_00:01:12 on domain 1: 568.20001 elapsed seconds.
Timing for main: time 2001-10-24_00:02:24 on domain 1: 30.18000 elapsed seconds.
Timing for main: time 2001-10-24_00:03:36 on domain 1: 29.07000 elapsed seconds.
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 2 2 -NaNQ 5000.000000
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 3 2 -NaNQ 5000.000000
(numerous lines of "WOULD GO OFF TOP:" follows)

Leonard
2009-4-4
leonard
 
Posts: 25
Joined: Thu Feb 19, 2009 9:40 pm

Re: WOULD GO OFF TOP: KF

Postby jimmyc » Sat Apr 04, 2009 2:05 am

I dont know much about the benchmark case.
What is the model time step and grid spacing?

Nanq is a not an integer. In this case, the parcel never reaches an equilibrium level, which means something is wrong.

It could be the initial data, the compiler, the time step, etc.
Have you looked at the initial fields to verify that they are correct in the wrfout file? look at soundings at the grid point in question.
Try lowering the time step from 72 seconds to 60 seconds.
Attempt to use a newer compiler for the model.
Check the lateral boundary conditions. The grid points (i,j) being printed out are in the forcing frame.

wrfhelp@ucar.edu might be able to help diagnose the issue ... after you try the above.
The views expressed in this message do not necessarily reflect those of NOAA or the National Weather Service or the University of Oklahoma.
James Correia, Jr
jimmyc
 
Posts: 519
Joined: Tue Apr 15, 2008 1:10 am

Re: WOULD GO OFF TOP: KF

Postby hnlim » Thu Jul 02, 2009 12:11 pm

Hi

I have the above problem for 1 run case but when I turned off w_damping, it goes off.
However on a 2nd run, the error arises again. w_damping does not seem to be able to work.
And from the list of possible causes, I found that this pixel is over the ocean.

What is the cause of this? Is it that the scheme is creating too strong a convection?

Thanks
hnlim
 
Posts: 74
Joined: Wed Apr 16, 2008 11:51 am

Re: WOULD GO OFF TOP: KF

Postby dcvz » Thu Jul 02, 2009 9:01 pm

I've had cases with the "OFF THE TOP" prints where the ultimate source of the problem was not in KF at all. Once NaNs start appearing they can propagate around through the code and cause trouble (depending on the compiler and its switches). Over the ocean it could be PBL or microphysics that start it. It's usually hard to track down.
dcvz
 
Posts: 205
Joined: Tue Apr 15, 2008 12:02 am

Re: WOULD GO OFF TOP: KF

Postby hnlim » Thu Jul 02, 2009 11:45 pm

I had ran many cases over the same regions but slightly different coverage, ie larger or smaller regions but with the same resolution and this problem arises at different time step over different areas.
It seems its not always over the same point.

I had checked the possible causes suggested in previous posts and they look fine. Any recommendations to resolving this issue or putting a trace to the problem.
hnlim
 
Posts: 74
Joined: Wed Apr 16, 2008 11:51 am

Re: WOULD GO OFF TOP: KF

Postby dcvz » Fri Jul 03, 2009 12:57 am

It depends how far you want to go to fix the problem. If the problem is reproducible (it goes off the top at the same point at the same time step when you rerun the case), then you could try a restart. Once you have a restart file that will produce the problem, you can do various things with the WRF code to track it down, such as run it serially with a bunch of print statements or recompile WRF with flags that cause the program to stop when it creates a NaN.

Another thing to try is to use a different PBL or microphysics. From your description it seems the problem isn't in KF, but somewhere else. KF is just where the problem first becomes noticable.
dcvz
 
Posts: 205
Joined: Tue Apr 15, 2008 12:02 am

Next

Return to Runtime Problems

Who is online

Users browsing this forum: Google [Bot] and 3 guests