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

WRF errors

rjhall

New member
I am running the WRF model at a low resolution (Dx=75000), having run at higher resolutions with success (DX=10000,27000). However, the wrf output file is only 37MB. It seems to be stopping at the first timestep. I attach the nameless file and a copy of the rsl.out file. I'm not really sure what is wrong here. I am pretty inexperienced!
 

Attachments

  • namelist.input
    3.7 KB · Views: 5
  • rsl.txt
    2.8 KB · Views: 5
Hello! It looks like you're running into CFL errors immediately. Essentially, the model may become unstable when the Courant number (C) is greater than one, where C is:
C = (velocity*dt)/(dx).

The velocity here would be the wind. What happens when CFL is violated and C > 1 is that information from one gridpoint is travelling past the surrounding gridpoints in a single time step, which dynamic systems are not prepared to handle. This can happen if your time step is too large, or if there is especially strong wind in your simulation (including because of complex terrain).

The first thing to modify for CFL errors is typically the time step. It looks like your time step is set to 360. I would personally reduce that in steps of 30 or so and rerun until you find a time step that allows the simulation to complete. If that doesn't happen, or the functional time step is too small for your purposes, I would take a look at some of the various smoothing parameters. There are a few ways to control how waves are damped or even to smooth your terrain, but first you should probably take look at the time step.

One other error that someone new may run into is having incorrect boundary conditions, either from not running real.exe or having something go wrong upstream in WPS. If the boundary conditions are from the incorrect date or for the wrong domain, the extreme gradients at the boundary can sometimes cause CFL to be violated.
 
Thank you. I decreased the time steps in steps of 30 as you suggested. Setting a timestep 0f 240 removed the CFL errors but the run still terminated almost immediately. (See attached rsl.out). So I am none the wiser and not sure where or what the smoothing parameters are. real.exe is run and the domain seems OK.
 

Attachments

  • rsl_modified.txt
    2.3 KB · Views: 3
Looks like the additional smoothing won't be necessary, then! As for the new issue, I'd also like to see the rsl.error file if you have that available. I'd also re-run real.exe, if you haven't done that yet, and see if that changes anything.

A couple additional questions:

1) Are you getting any output files?
2) If you are running wrf by submitting a job to a cluster using a scheduler (like slurm), do you have output/error files from those jobs?
3) On a related note, is it possible that you are running out of memory for your job? If you can, try running with an increased number of cores or increasing your memory allocation.
 
Hi
Thanks for your efforts with this. Running real.exe again makes no difference. I get an output file but it is only 37MB, and it doesn't run long enough to get the wrfrst files.
The rsh. error files look the same to me but I attach one. From the job script output it looks like the job is being killed for some reason. I have tried different numbers of cpus.
 

Attachments

  • rsl_error.txt
    2.3 KB · Views: 2
  • jobscript_outputfile.txt
    5.8 KB · Views: 1
Hi
Thanks for your efforts with this. Running real.exe again makes no difference. I get an output file but it is only 37MB, and it doesn't run long enough to get the wrfrst files.
The rsh. error files look the same to me but I attach one. From the job script output it looks like the job is being killed for some reason. I have tried different numbers of cpus.
Can you attach all your rsl.out and rsl.error files after you run ./real.exe
 
The model crashed immediately after wrf.exe started, which often indicates that something is wrong in your input data.
Can you clarify what data did you use to drive this case?
 
Last edited:
The input data is ERA5, with OI SST regridded to match the ERA5 grid. The data have worked well at higher resolution, with successful outputs. The data are at hourly resolution but METGRID converts to 3-hourly met_em files. Attached are the rsh files from running real.exe
 

Attachments

  • rsl_out.txt
    522.9 KB · Views: 0
  • rsl_error.txt
    206.2 KB · Views: 1
I am suspicious that something went wrong during the remap of OI SST to ERA5 grids, especially that the landsea mask is quite different between OI SST and ERA5........
 
Top