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

During wrf.exe, stuck/burst at "HALO_EM_THEAM_inline.inc" at noon (~14.00 UTC) in the log (strong CB occurrences in the area).

Basher

New member
Hİ,
I'm using GFS 0.25 data, I ran it with 0.25 degrees, no problem. I got this problem when I run it with 01, adap. I applied time step and could not solve the problem. from the first my area was large. It was a larger longitude (except almost all of Europe-Turkiye) rectangle covering latitudes 25-65. I reduced the field to adriatic to see if maybe the overly variable dx length is causing the problem. but I guess that's not the problem. why is it like this, is conus causing a problem? And as additional information; 20230803 op. If I start the model with the data on the 3rd or 4th of the month, the model explodes at noon on the 4th. so the problem seems to be different from swelling/filling. I'm confused.

namelist.input ; "namelist.input"
debug100 = "Screenshot from 2023-08-05 20-10-02.png"
debug50 = "Screenshot from 2023-08-05 20-25-43.png"
have a nice day.
 
Hi,

1) First, please set debug_level back to 0. Turning this on is very seldom useful and typically just adds additional junk to the error/output files, making them more difficult to read.

2) What do you mean by "...I run it with 01...?" What is 01? For clarification, are you saying that you originally ran this identical case, but without adaptive time-stepping, and it worked fine, but when you set use_adaptive_time_step = .true., you got the problem?

3) I see your domain dimensions are 150x85. You should not use a domain size any smaller than 100 grid spaces in either direction. Take a look at this Best Practices page for additional explanation.

4) After modifying the set-up as indicated above, please run it again, and if you still receive an error, or if the model stops unexpectedly, will you please attach the full error log(s), as opposed to a screen shot. If you are running in dmpar mode, please combine all the rsl.error.* files into a single *.tar file and attach that.

Thanks!
 
You're right, I wrote a little badly. First, I ran it to output 0.25 degrees of data in a very large area with a resolution of 0.25 degrees, and there was no problem. Afterwards, I tried to run 0.1(~10 km) degrees for a better resolution output. When I got an error, I used adaptive time adjustment, but it didn't work like the images I sent. I shrunk my area to cover the Adriatic periphery, again nothing changed and the model exploded at approximately the same time.

Now I ran it again by doing what you said and my model exploded at the same time.
 

Attachments

  • all_rsl.zip
    48.3 KB · Views: 1
  • namelist.input
    4.3 KB · Views: 2
  • namelist.wps
    492 bytes · Views: 1
Can you try to run this again, without using adaptive time-step, so I can see what the error is then? Afterward, please send the rsl files and modified namelist again, as you've done before. Thanks!
 
By the way, server's situation info after wrf stuck:
Filesystem Size Used Avail Use% Mounted on
/dev/root 97G 87G 9.8G 90% /
 

Attachments

  • all_rsl_without_adap_time_step.zip
    52.7 KB · Views: 1
  • namelist.input
    4.3 KB · Views: 1
Hi,
I just tested your case, using GFS 0.25 degree data and your namelist.input file. It runs without any problems. Is it possible that you're running out of space on your disk, and that when the output file reaches a specific size, the model is crashing? Have you made any modifications to the WRF code, or is it out-of-the-box code?
 
Top