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

Line-shaped perturbation in idealized WRF simulations

hanl

New member
Hi,

I am conducting an idealized simulation on Derecho. However, there are many strange, large perturbations appearing at the east and west boundaries after 9 hours integration (Fig. 1). In addition, there are also some line-shaped perturbations in the later stage (Fig. 2).

The attachments contain the corresponding screenshot for this issue, namelist.input I used. I have also updated a file “debug_wrf_file.tar.gz” in the Nextcloud storage, which contains my wrfinput_d01, wrfbdy_d01, and some wrfout file.

I would be grateful if you could provide me some advice on how to remove this perturbation.

Thanks
 

Attachments

  • Fig1-screenshot-w-9h.png
    Fig1-screenshot-w-9h.png
    223.5 KB · Views: 6
  • Fig2-screenshot-w-48h.png
    Fig2-screenshot-w-48h.png
    200.2 KB · Views: 7
  • namelist.input
    7.4 KB · Views: 2
Hi,
First I'd like to apologize for the long delay in response. Members of the support team have been out of the office a lot over the past month. Can you let us know if you are still experiencing this issue? If so, will you let us know which idealized case you're running and which version of WRF? Thanks!
 
Hi,
First I'd like to apologize for the long delay in response. Members of the support team have been out of the office a lot over the past month. Can you let us know if you are still experiencing this issue? If so, will you let us know which idealized case you're running and which version of WRF? Thanks!
Hi Kwerner,

Thanks for the response.

Yes, I’m still experiencing this issue. I am conducting an idealized experiment involving a cold low and a large-scale low-level cyclonic circulation using WRF version 3.9. The file "debug_wrf_file.tar.gz" containing my namelist.input, wrfinput_d01, wrfbdy_d01, and some wrfout files can be downloaded from the following link:


Thanks!
 
Thank you for sharing that. Which of the following idealized cases is yours based on?

em_b_wave
em_convrad
em_esmf_exp
em_fire
em_grav2d_x
em_heldsuarez
em_hill2d_x
em_les
em_quarter_ss
em_real
em_scm_xy
em_seabreeze2d_x
em_squall2d_x
em_squall2d_y
em_tropical_cyclone

Did you make modifications to the code, or just to the namelist?
Can you try this with the latest version of WRF (V4.6) to see if the problem still exists?
 
Thank you for sharing that. Which of the following idealized cases is yours based on?

em_b_wave
em_convrad
em_esmf_exp
em_fire
em_grav2d_x
em_heldsuarez
em_hill2d_x
em_les
em_quarter_ss
em_real
em_scm_xy
em_seabreeze2d_x
em_squall2d_x
em_squall2d_y
em_tropical_cyclone

Did you make modifications to the code, or just to the namelist?
Can you try this with the latest version of WRF (V4.6) to see if the problem still exists?
Thanks for your suggestion. I am using em_real and have not changed the WRF code, only the namelist.

I have tried these experiments with the precompiled version 4.5 of WRF on Derecho previously. It did make the perturbations near the boundaries absent, but new different shaped perturbations appeared in the who domain(as shown in the attached figures).

I will try using version 4.6 to see if this improves. Thanks!
WRFV4.5_Screenshot_w.png
WRFV4.5.jpg
 
Thank you for sharing that. Which of the following idealized cases is yours based on?

em_b_wave
em_convrad
em_esmf_exp
em_fire
em_grav2d_x
em_heldsuarez
em_hill2d_x
em_les
em_quarter_ss
em_real
em_scm_xy
em_seabreeze2d_x
em_squall2d_x
em_squall2d_y
em_tropical_cyclone

Did you make modifications to the code, or just to the namelist?
Can you try this with the latest version of WRF (V4.6) to see if the problem still exists?
Hi Kwerner,

I also tried to use precompiled version 4.6 of WRF on Derecho. However, there are still many perturbations similar to those occur when using the version 4.5 of WRF. I would appreciate it if you could give me some more advice. Thanks!

WRFV4.6_Screenshot_w.png
 
I guess I'm confused about how you're running an idealized case with a real-data compile (i.e. not one of the idealized cases). What is being modified to make this case idealized, as opposed to a standard real-data case?

Based on your namelist, it also looks like you may be running a vortex-following case. Did you choose the vortex-following nesting option when you compiled?

If you don't mind sharing your derecho running directory, I can take a look at the files a little closer.
 
I guess I'm confused about how you're running an idealized case with a real-data compile (i.e. not one of the idealized cases). What is being modified to make this case idealized, as opposed to a standard real-data case?

Based on your namelist, it also looks like you may be running a vortex-following case. Did you choose the vortex-following nesting option when you compiled?

If you don't mind sharing your derecho running directory, I can take a look at the files a little closer.
Thank you so much for your response! Currently, I am using a single-domain experiment for testing. During compilation, I used the vortex-following option, but I have not applied the related settings in the current experiments.

The address for WRFV3.9 that I am using is:
/glade/work/hanli/model/WRFV3.9_intel_dmpar/onlyCL_CL500

The address for the test WRFV4.6 that I am using is:
/glade/derecho/scratch/hanli/test_version4.6/wrfv4.6.0/onlyCL_CL500

Many thanks in advance for your time and efforts!
 
Thanks for sharing that. I would suggest that if you aren't using the vortex-following mechanism, you should not compile with vortex-following for those cases. I looked at your configure.wrf file for V4.6, and it doesn't look like you did for that one, so that's good.

As for the odd lines around the edges, I see those, as well, but then notice that they are only there for a time, and then go away by the end of the simulation. Is that correct? If so, then it's probably okay. Another thing I notice is that you are using input that is only available once every 24 hours. This is an extremely coarse temporal resolution, and it would definitely be better if you were able to use an input data type that was available more often - every 3-6 hours would be ideal.
 
Top