UPP temporarily causing error

[SRUDY_78]

Hello,

I actually got a problem during creating grib1 data from WRF modeloutput.

At first I show the error I got from unipost.exe which is stated in the logfile.


GRIBIT: 2 SHUELL MEAN SLP 102 0 0
calculating radar ref for non-Ferrier/non-Zhao schemes
IICE= 1
At line 584 of file MDLFLD.f
Fortran runtime error: Index '40' of dimension 3 of array 'zmid' above upper bound of 39

Error termination. Backtrace:
#0 0x7fa10b6c12ed in ???
#1 0x7fa10b6c1ed5 in ???
#2 0x7fa10b6c22a7 in ???
#3 0x5610ef84c0e5 in mdlfld_
at /home/dy/Build_WRF/UPPV4.1/sorc/ncep_post.fd/MDLFLD.f:584
#4 0x5610ef8de481 in process_
at /home/dy/Build_WRF/UPPV4.1/sorc/ncep_post.fd/PROCESS.f:81
#5 0x5610ef9e10a1 in wrfpost
at /home/dy/Build_WRF/UPPV4.1/sorc/ncep_post.fd/WRFPOST.f:830
#6 0x5610ef9e273d in main
at /home/dy/Build_WRF/UPPV4.1/sorc/ncep_post.fd/WRFPOST.f:134


I use UPPV4.1 together with the latest WRF - Version 4.2.2 which is modified in the Registry. I need precipitation rate as parameter as well.
What I actually observe is that using a not modified registry causes no error in UPP. Also, a small area, dimension of approx. 1X1 degree and resolution of about 2 km causes no error when modified. However, I resently tried a bigger area and a resolution of 4km and the error occured, but only in the first domain.

For both, I used the same setting in namelist.input / namelist.wps except all horizontal values, that means e_sn, truelat and so on.

The WRF System is part of a python runtime script, performing postprocessing while WRF is running. Therefore, I don't use the unipost bash scripts but directly the unipost.exe command with the itag.

I attached the namelist.input and the logfiles. The error can be found in d01. I hope someone can help.
Best regards
Sebastian

 

[SRUDY_78]

Hello,

I have some more information to add.

First:

I changed the following in Registry.EM_COMMON
RAINCV, RAINNCV from r to rhdu Variables are needed for further processing.

Second:

I did serveral tests today to figure out the problem, but haven't catch it yet. I checked the MDLFLD.f file where the error occured and modified afterwards the Registry parts HTOP, CUTOP to get the parameters stated in MDLFLD.f . The tests afterwards showed that UPP completed the conversion to grid1 but now I got the following error at the end of the file.

ENDING DATE-TIME FEB 10,2021 16:00:27.223 41 WEN 2459256
PROGRAM UNIFIED_POST HAS ENDED.
* . * . * . * . * . * . * . * . * . * . * . * . * . * . * . * . * . * . * . * .
*****************RESOURCE STATISTICS*******************************
The total amount of wall time = 5.490733
The total amount of time in user mode = 5.308509
The total amount of time in sys mode = 0.116104
The maximum resident set size (KB) = 71656
Number of page faults without I/O activity = 12922
Number of page faults with I/O activity = 26
Number of times filesystem performed INPUT = 2584
Number of times filesystem performed OUTPUT = 3016
Number of Voluntary Context Switches = 44
Number of InVoluntary Context Switches = 1305
*****************END OF RESOURCE STATISTICS*************************


===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 20029 RUNNING AT dy-HP
= EXIT CODE: 134
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Aborted (signal 6)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions

All I know is, that it occures on domain 1.

It also looks like being dependant from weather situation. I used GFS data and could see that on one half of the day all data are ok and the after part was not. The day was 2021-01-29 from 00 UTC to 0 UTC next day.

But I have really no idea why.

Best regards
Sebastian

 

[SRUDY_78]

Hello,

I'm still trying to figure out my problem, hoping someone can help. Today, I worked on this problem the whole day. What I did was a lot off print outs from UPP. Due to the errors yesterday I added, beside raincv, rainncv, the variables htop and hbot (cubot and cutop as well).

As far as I noticed, when switching off cu_physics (0) the error disappear. No problem. But when it is switched on, I got an error and unipost stopped.

At present, the error seams to be shifted to the calculation in CLDRAD.f. I put some print at the corresponding areas in INITPOST.f, MDLFLD.f and CLDRAD.f. What I can see is, that hbot got zeros out of WRF. Due to the calculation in INITPOST -> float(LM)-dummy(i,j) + 1.0 the value is 40.0. In my case of course. However, the max index for ZMID, located in CLDRAD seams to be 39 and not 40.

It looks like the same problem, but on a different location in UPP. Is this a bug? Or am I doing something wrong?
Is it really neccessary to have htop and hbot params as input when requesting precipitation rate?

I attached the last logs from unipost as well as namelists from WRF. The kind of cu_physics used is stated in the filename.

Thanks in advance.
Best regards
Sebastian

 

[lcarson]

Hi Sebastian - while I have not duplicated your error, this fix should avoid the issue of the index going beyond the model top level,
Add a limit in MDLFLD.f, at the line where the error first occurred

change:
Lctop=NINT(HTOP(I,J)) !--- Cu cld top level

to:
Lctop=MIN(NINT(HTOP(I,J)) , LM) !--- Cu cld top level

That should eliminate this index going outside of the array dimensions.

Laurie

 

[SRUDY_78]

Hello,

thanks for your help. Now it works.

Best regards
Sebastian