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

Abnormal Spatial Patterns in Fine Grid WRF and CMAQ Simulations

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.


New member
Abnormal striated patterns were detected in the simulated meteorological fields from the Weather Research and Forecasting (WRF) regional modeling system over the San Francisco Bay Area with 1-km resolution. These spatial abnormalities appeared not only in the 2-dimensional fields, such as temperature at 2 meters, wind at 10 meters and planetary boundary layer (PBL) height, but also in 3-dimensional fields extended to around 1300 meter in the upper levels. Similar abnormal spatial patterns were also found in air pollutant concentrations simulated by the Community Multi-Scale Air Quality (CMAQ) model using these WRF meteorological inputs. We used WRF version 3.8. We were not clear what caused these striated abnormalities. So we tried the following sensitivity tests:

1. Set diff_opt=2 (previously diff_opt=1), coupled with km_opt=4
2. Adjusted diff_6th_factor
3. Set sf_sfclay_physics=99 (previously sf_sfclay_physics=1)
4. Replaced PX-ACM2 with Noah-YSU

The above tests which were made in WRF version 3.8 had little impacts on the abnormal spatial patterns. However, the WRF model results were improved significantly and abnormalities in the simulated meteorological fields were minimized when using updates to WRF version 4.0.1 with the same namelist options (please see the attachment) as those in version 3.8. The abnormalities in CMAQ simulated air pollution concentrations were also mitigated.

Would you offer us insights on what caused these abnormal patterns and what updates in WRF version 4.0.1 helped “removed” these abnormalities? We were quite impressed with the significant improvement on the WRF v4.0.1 model performance, and the following CMAQ results. But we are really puzzled with the why. Hope your expertise and experience can help us solve the puzzle! What we have found and learned from WRF can also benefit the CMAQ modeling work.

Attached, please find the namlist file from WRF version 4.0.1. The namelist file of version 3.8 is almost identical with this one, except that there’re no parameters of force_use_old_data and hybrid_opt.

The attached plots show the PBL and total PM2.5 from the run using version 3.8 (left) and the run using version 4.0.1 (right).


  • plots.docx
    150.1 KB · Views: 90
  • namelist.input.txt
    11.8 KB · Views: 75
I want to provide a response so that you know we aren't overlooking this post. I have been asking around to various members of the development team to determine why this may have been corrected with V4.0.1, but so far, no one is aware of anything significant (especially since you are turning off the hybrid option for V401). We will continue to look into this, but it could take a bit of time to track down.
Thanks for the reply! I wonder if you want to replicate the problem. I can provide you the input files. Thanks!
Yes, thanks - that would be great! If the files are too large to attach here, take a look at the forum home page for information regarding submitting large files.
Sorry for the delay! I have trouble uploading the "large" files. Even I grouped them into three tar files (1.5 to 2.5GB each), it still took forever to upload them! So far only one tar file was uploaded. I am trying to upload the four large wrffdda files one by one. But I'm afraid wrffdda_d04 with 2.1GB is still too large to upload. If that's the case, you may turn off the FDDA on the 4th domain.

All files have the suffix "forum_Tian1Qi4"

Or You may download the files from my Dropbox link

All files were uploaded! Here're the files:


Please let me know if you can get them ok. Thanks!
Thank you for sending those. I was able to grab them all and will start to try to run this soon. We are busy with the WRF/MPAS Workshop this week, but I'll try to get to it during down-times, if possible. Thank you for your patience.
Can you let me know if it's necessary that I run the full 6 days to see the odd patterns? If not, I'd like to shorten the runs in an effort to run these faster and save CPU's. Thanks!
The abnormal patterns show at 22GMT Feb. 11. I think 3 days simulation is enough, 2016-02-09_12 to 2016-02-12_12. Thanks!
I just wanted to let you know that I haven't forgotten about you. I've gotten a bit behind while traveling, having our super computer out of commission for a week and 1/2, and then prepping for our WRF tutorial happening this week. I apologize for the delay. I have been able to reproduce what you're seeing in V3.8, vs. not seeing in V4.0.1. Unfortunately I keep running into problems when running on any of the 3.9 versions. I'm trying to get those figured out, so that I can narrow down the version when this problem was corrected. I'll continue to keep you posted, and please let me know if you figure anything out in the meantime. Thanks!
Thanks for working on the problem! I was tied up with other work and didn't make much progress. But I did try the version 3.9 and the results showed there's NO abnormal "stripes". Please see the attached plot.


  • pbl.v39.png
    35.3 KB · Views: 2,907
Thanks! That's good to know. Since you're not having problems running the 3.9* versions, would it be possible to also try this with V3.9 to see if you see the problem there? If not, then we can at least track it down to some change between 3.8.1 and 3.9.
When you were running any of the versions, did you ever get errors that looked like:
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:     425
  RIBX never exceeds RIC, RIB(i,kte) =               NaN  THETAV(i,1) =               NaN  MOL=              NaN  TCONV =    0.00000000      WST =               NaN  KMIX =            2  UST =               NaN  TST =               NaN  U,V =               NaN              NaN  I,J=           1           1

If so, do you recall how you corrected this? I am unable to test any versions of the code past V3.8.1 because of this error. I'm not sure what changed that is causing this, but I haven't found a solution yet. Thanks!
I vaguely remember that I had this error before, if I used sf_surface_physics = 7 (PX LSM) AND sf_sfclay_physics = 7. The model run ok if sf_surface_physics = 7 (PX LSM) with sf_sfclay_physics = 1. The namelist I gave you should have the later combination.
If using version 4, there's NO this error even I used sf_surface_physics = 7 (PX LSM) with sf_sfclay_physics = 7