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!
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
WRF errors
- Thread starter rjhall
- Start date
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.
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
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.
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.
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
William.Hatheway
Active member
Can you attach all your rsl.out and rsl.error files after you run ./real.exeHi
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.
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