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

Unknown reason for difference between idealized runs in x- and y- directions

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
To whom it may concern,

I am trying to implement a new surface drag method in WRF, so I want to check the symmetry in x- and y- directions.

The point I started at is the default WRF (no new code implemented), 2d idealized bell shaped mountain case (WRF/test/em_hill2d_x). I changed the default namelist.input to higher resolution, and changed the related part of code in dyn_em/module_initialize_ideal.F, namelist.input, and input_sounding to get a symmetric run in y-direction. Surprisingly, the two results are not the same.

Then I tried to test the asymmetry I saw above, I changed the run from 2d to 3d. The mountain is still bell shaped, and totally symmetric in x- and y- directions. The only difference between my two runs are the input_sounding files, the winds are kept at 10m/s and potential temperatures are kept at 273K at all levels, the only difference is the wind is from west/south. Picture attached is drawn by ncview and you can see the obvious asymmetry between the two runs (U field in the left pic and V field in the right one, same color bar).

I am not sure what to do now, do you have any idea why there's the asymmetry between two directions?

Besides the picture, namelist.input is attached here. 3D test runs last for 5 minutes, resolutions are 40m, and runs are set to be open boundaries.




  • 800m_symmetric.png
    324.7 KB · Views: 551
  • namelist.input
    3.6 KB · Views: 48
Your namelist.input looks fine and I don't find anything wrong. Now my question is, how did you change the code and the sounding?
I would suggest that you change those stuff one by one:
(1) Just change the sounding and see whether you can get the expected results;
(2) Change the code and use the default sounding, see what results you can get.
This will help to narrow down to the possible reasons for the asymmetric output.