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

troubles, could not find trapping x locations

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

J

JCollins

New member
I am running a simulation of one year (365 days) with NCEP/NCAR reanalysis data.

When I run real.exe, the following error is printed:
Code: 
troubles, could not find trapping x locations

What I do not get to understand is because the simulation runs successfully for 30 days, for 60, but from day 70 it fails (day 70 runs successful, day 71 error).

I can not understand what is happening. I attach the namelist.
 

Attachments

  • namelist.input
    2.9 KB · Views: 74
Hello again. I tried several possible solutions but none worked. I also tried to change dates and fail with different temporary spaces. For example, I had the simulation begin on 07/01/18 and in this case for 64 days, real runs successfully, but for 65 days it prints the bug mentioned above. I can't move forward, any ideas?
 
I am suspicious this is a problem in NNRP data.
Please let me know where you download the GFS data, and at which time REAL stopped. It will also be helpful to send me your namelist.wps and let me know which version of WPS/WRF you are running.
 
I am downloading the data from the following url: https://rda.ucar.edu/datasets/ds090.0/

I downloaded the pgb.f00 and grb2d data, from November 2017 to December 2018. I attached an rsl file so you can see the error and the time it stops. Anyway, if you change the start date it stops at a different time.The version I use for both WPS and WRF is 4.1. I also attach the namelist.wps.
 

Attachments

  • rsl.error.0000.txt
    174.2 KB · Views: 84
  • namelist.wps
    746 bytes · Views: 84
I did a test over a short period covering the time when the trouble occurred. The code works just fine. This confirms that the data is fine, and something else caused the problem. I am not sure whether it is a problem related to MPI, or it is a bug in the code. We will look into this issue and keep you updated if we figure out something.

Meanwhile, would you please tell me the size of wrfbdy before REAL crashed?
 
I also did shorter tests including the period where real crashes, and it works correctly. Real.exe stops in that particular period if the simulation starts on January 1, 2018. If the start date changes to a different one, real crashes into a different period. As an example, if the starting day is July 1, 2018, real crashes at 65 days. What I could see is that the error occurs with simulations over 65-70 days, depending on the start date, but it does not follow a fixed pattern, so I am lost.

The size of wrfbdy at the moment real crashes is 1.2G.
 
I have run a test case to process 421 times of GFS data. REAL finished successfully.
This makes me believe that the code should be fine. Unfortunately I have no explanation why you have the problem to process data over longer period.

Note that I only run over a domain of 86 x 75 grids for the test. The size of my wrfbdy-d01 is 2.4GB.
 
I tried to run for the same domains and days with GFS data and I have no problem. I only have a problem with the NCEP/NCAR reanalysis data.
 
Is it possible that you do a simulation with the data of the NCEP/NCAR for a period greater than 71 days? It is not necessary to run WRF, since it fails in REAL and does not take much time. I am very lost and I can't find the solution.

Thanks a lot.
 
Hi,
I want to tell that I didn't forget this issue. I have downloaded three months of NNRP data, covering the period 2017-11-01 to 2018-01-30.
The supercomputer in NCAR is down this week for CESM tutorial. I will run REAL and hope I can repeat the problem.
Thanks for your patience.
 
Hi,

Here is the update about the REAL and NNRP data issue:

(1) I download NNRP data for the period of 2017-11-01_00 to 2018-01-30_18, ungrib them, and run REAL for 90 days. The program is done successfully. Somehow I cannot repeat the problem you experienced.

(2) I talked to a colleague who is working on climate simulation. He told me that he did experience a problem similar to yours, i.e., REAl stopped somewhere before the end of the integration period. He reduced the number of processors and his job was done successfully. I consulted our experts in computer center, and I was told that this might be an MPI problem.

(3) I would suggest you run REAL with as small as possible number of processors (but please make sure the memory is still sufficient), and see how the program works.

I am sorry that I cannot provide an immediate solution to the problem. I don't think it is a code problem.If it is indeed a MPI issue, we will need assistance of experts in computer science.
 
Hello everyone.

I am also trying to run a simulation with this data and I have the same problem. I always run REAL in serial, in a single core, and it stops with the same message. I tried to run REAL with MPI and I also have the same error.

JCollins, could you solve the error?
 
Hi Saszalez.

I still have the same error, I couldn't fix it. I followed Ming Chen's instructions, but I didn't succeed with the tests.
 
I routinely use NCEP data (ds090.0) and without errors. The most notable difference is that the domain has a complex topography (Himalayas). Checking the rsl files I find a NaN error:
Code: 
rsl.out.0000: column of pressure and value =             NaN   9.037395
I tried several possible solutions (increase vertical levels, reduce p_top, etc.) but the error is not fixed. Any way to fix NaN? I understand that this is the reason why the error TROUBLES, COULD NOT FIND TRAPPING X LOCATIONS is printed.
 
I managed to eliminate the NaN with this option, but I don't understand exactly why the error was fixed, any ideas?
Code: 
interp_type = 1,
 
I have had the same error again with other domains in another part of the world. I have fixed the error again with the option mentioned in the previous message. What is the difference between setting a 1 and a 2? In both options, the levels are usually at the same height, but thanks to option 1 I can solve the problem.
 
Hi,
I'm glad to hear that you were able to find a solution for the problem. The difference in options 1 and 2 are:
1: interpolate in pressure
2: interpolate in LOG pressure

Thank you for posting the fix that helped you. It may help someone else in the future!
 
You must log in or register to reply here.
Top