real.exe processes was killed

[PROFY]

starting wrf task 0 of 1
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

I encountered the following error message while running real.exe. I did not find any significant differences and modified the center coordinates to run again, but still reported the error grid% tsk unreasonable. I hope to seek help.thanks.

 

[PROFY]

ERA5 hourly data on pressure/single levels from 1940 to present data was used

 

[PROFY]

WRF version 4.3

 

[William.Hatheway]

ERA5 hourly data on pressure/single levels from 1940 to present data was used

So it looks like you are doing the proper steps with the two different ungribs. One for 3D data and the other for SFC data.

However looking at your namelist file it shows this:

 geog_data_res = 'default','default',
 dx = 900,
 dy = 900,

dx and dy are set for 900m. If I remember correctly ERA5 is approximately 9km grid spacing. So you are attempting a 1:10 ratio for input data to grid spacing.

WRF prefers 1:3 or 1:5 ratio.

I would wait until @kwerner confirms my thoughts but I am pretty certain this is the cause of it to fail.

I would also look at this page for best practices:

WRF namelist.wps Best Prac

WRF Namelist.input Best Prac

 

[kwerner]

@PROFY,

The error message you're getting is

-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:    2998
grid%tsk unreasonable
-------------------------------------------

It could be related to a few different things, but first I would like to address both the issue that is mentioned by William, above, and the number of processors you're using. Your WRF DX/DY should be no more than about a 5:1 ratio between the input data resolution and the domain resolution, and the same goes for the ratios between your WRF domains. So you likely will need to set up your domains in a manner that then allows you to nest down to the desired resolution.

Additionally, you may need to use additional processors to run real.exe, and you definitely will need to use more to run wrf.exe. Sometimes real.exe is able to run with much fewer processors than wrf, but your d03 is 652x601 grid spaces, and that's probably too much for a single processor.

If you modify your set-up and you're still getting the same error during real.exe, do a search in this forum to find solutions others have used when getting this error with ERA5 data.

 

[zhaneden]

Hello,

I have the same issue while running real.exe and cannot solve the problem. Please help me. WRF version 4.6.1 (compiled with 15. (dmpar) INTEL(ifort/ice); 1.basic).
I used ERA5 hourly data on pressure & single levels. After successfully generating and link the met_em files to em_real directory, ./real.exe and got response
starting wrf task 0 of 1
killed

only wrfinput_d01 and wrfbdy_d01 were generated. No wrfinput_d02 (since i set input_from_file = .true., .true.,).
When i look through the rsl.out.0000 or rsl.error.0000 files, i found no error message (no FALTAL CALLED). It seems ./real.exe just stopped suddenly after finishing processing the domain 1. I tried to set input_from_file = .true., .false., and i got the SUCCESS message which confirms that it is able to process the data of domain 1 to create the initial boundary conditions that model needs, but somehow doesn't work for domain 2.
I tried to recompile wrf since someone did that before, but it didn't work.

I attached the namelist.input and rsl.error.0000 below, and also the met_em files to test.

I hope experts could help me. Thank you.

​

 

[zhaneden]

Hi,
Although you are also getting an error when running real.exe, it looks like the error is different than the one in the original thread here. To keep the threads simple and easier to read, please post your inquiry as a new thread and we will address it there. Make sure to attach the files again. Thanks, and apologies for the inconvenience.

Hello, I solved it. the problem was not related to WRF itself. I used more CPU and MPI processes and it worked. Thank you again.

 

[William.Hatheway]

Hello, I solved it. the problem was not related to WRF itself. I used more CPU and MPI processes and it worked. Thank you again.

sometimes it's the simplest things that always stump us. I'm glad you were able to solve it!