vert_refine_method and hybrid_opt

[rdumais63]

Dear WRF Users,

I have been executing WRF-LES simulations using one-way interactive multinesting from mesoscale to LES (150m finest nest) for several months. The model will execute with setting vert_refine_method=2 (vertical nesting) and with hybrid_opt=2 and etac=0.2. Although interior results usually look believable there is always suspicious gradients of the fields that are within or just outside the edges of my lateral boundary buffer zone. I have tried many things to alleviate this in the lateral buffer zone but it is persistent regardless of vertical resolution I throw at it. I now think the issue might be that vertical nesting may not be advisable to use with the hybrid_opt=2 option. Perhaps vertical nesting is designed to work best with hybrid_opt=0 (original terrain following coordinate)? I have noticed others doing WRF-LES with vertical nesting also select hybrid_opt=0 and seem to not have such a boundary zone issue (unless they just do not show these boundary zone results in their analyses and plots). Is there some guidance that cautions about vertical nesting with the hybrid vertical coordinate? Thanks. I am middle of doing a simulation test now to see if this fixes my issue with the lateral boundary zone gradients.

 

[rdumais63]

Also.. i've seen a namelist variable "rebalance" associated with vert_refine_method. If I set vert_refine_method=2 does the code automatically set rebalance=1?

 

[MLandreau]

Hi,
I am also a new WRF user using vert_refine_method. According to the run/README.namelist file, rebalance must be set to 1 when using vert_refine_method = 1 or 2.
I think the vert_refine_method hasn't been available in WRF for a long time since I found some articles from ~2015 in which they said that vertical nesting was impossible in WRF. Then I would be surprised if the vertical nesting doesn't work with hybrid_opt=2
What kind of gradients do you have ?
Mathieu

 

[rdumais63]

Hi Mathieu,

Below are just a few examples from some recent runs multinested down to 150m and 127m LES (or really more like VLES), These are just sample plots taken across two different configurations and for different times of day over southern NM just to share the effect I keep seeing. I have tried boundary zones of 5 and 11 in these runs and in some ways the effect has looked worse the wider the zone I use. It clearly effects most fields and most model levels on the zones and maybe even just beyond the zone extent. On the otherhand, the figures I attached show the plotting intervals on the top label so you can see in terms of change in absolute value of the variable across they are small but the gradients are very noticeable. In order to really see the effects stand out I often have to plot the variable with a very fine plotting interval however. Below I show examples of TC, Press Pert, w, and u (with model level showed on label). I am using a number of vertical levels on my inner LES domains so this should not be an issue.

However, yesterday I stumbled onto rebalance in the same README you mentioned. Reading through Meghan Daniels et al original vertical nesting paper it is clear that this rebalancing step is critical for the lateral boundaries between nests. I have never set it in my namelist so assume in the registry it may be set by default to 0. This means I have ben using vert_refine_method=2 throughout all my past runs with rebalance=0! This may be the total source of my issue but I'll need to wait until my new model run completes further to confirm this. I wil come back and post when it does. Last night I tried with vert_refine_method=2, rebalance=0, and hybrid_opt=0 and the same effect occurs (I had been using with hybrid_opt=2 for some time) . So..I assume now after last night that the hybrid_opt choice was never the true issue. Maybe the vertical nesting does work fine with either hybrid_opt=0 or 2? However, I am running now with hybrid_opt=2, etac=0.25, vert_refine_method=0,2,2,2 (I have 4 nests) , and rebalance=1. Hopefully the additional namelist setting of rebalance= 1 removes this effect in the zones. Fingers crossed. If I succeed I will also share my entire namelist for others.

 

[rdumais63]

Here is a link to Megan et al's paper in case you are interested:
https://www.researchgate.net/public...he_Weather_Research_and_Forecasting_WRF_Model

 

[MLandreau]

Thank you,

I ran a quick test few days ago and notice the same issue. The attached picture comes from this test. It represent
- horizontal wind speed magnitude
- on my 10th vertical level
- on my d04 : 1st LES domain and 1st vertically nested domain with vert_refine_method=2
- rebalance = 1
- Dx = 351m
- with 5 "boundary cells"
However, it is only 2h after the start of this domain so we might need more spin-up time.

Have you tried to run the same case without vertical nesting, using the same vertical grid as your RANS domains ?

Mathieu

 

[rdumais63]

Hmmm.. did you use hybrid_opt=0 or hybrid_opt=2? I am still waiting for my run using hybrid_opt=2, rebalance=1 and vert_fine_method=2 to start from the HPC queue. You seem to show that even if using rebalance=1 this zone effect still appears which is curious. Maybe you used hybrid_opt=2 in your setup? If so, you may try with hybrid_opt=0? I tried yesterday with hybrid_opt=0 and saw the same zone effect but that still had rebalance=0. Maybe with rebalance=1 and hybrid_opt=0 together this will work better? I wonder if some issues are from the switch between mesoscale nest and LES nest since physics (at least for turbulence) will be different? I have also tried tossing a prayer by switching to interp_method_type=1 rather than the default of 2 but this didn't matter much (since I do use a 7:1 grid nest ratio between my inner and next innermost nest). I have attached the namelist I am using for my most recent experiment now. Note I am using alot of extra vertical resolution on d04 just to ensure my aspect ratio delta(z)/delta(x,y) remains less than 1 all the way up to 50 hPa. I am also using very conservative timesteps for each nest as runtime is not a concern for me right now

 

[rdumais63]

Oh..since my domain covers pretty rugged topography over NM I have not tried using the same vertical grid across all nests (due to slope concerns and CFL). I try to keep my finest LES domain more in the valley rather than up the steep slopes of the San Andres and Organ Mountains. I have run for many years without vertical nesting and using multinesting (one way) and have never seen this. Another thing I have tried to play with on d04 is placing model levels below 10 mAGL for nighttime stable conditions (much like the Penn State group of Nelson Seaman& Dave Stauffer et al- https://journals.ametsoc.org/view/journals/mwre/140/3/mwr-d-11-00061.1.xml ). But these darn boundary zone gradients are always around.

 

[rdumais63]

One more thing Mathieu- which version are you currently running?

 

[rdumais63]

We should also confirm that vertical nesting now works with the other radiation schemes other than RRTM. At one time early after vertical nesting was introduced only RRTM/RRTMG could be used.

 

[MLandreau]

I am using v4.5.1, hybrid_opt=2, RRTMG scheme for both LW and SW radiations

I see from your namelist that you are using a different vertical mesh for all your domains. Do you have the same issue in your d03 ? If not, it might indicate that the problem is linked to the use of LES or to the nesting between RANS and LES as you mentioned.

I will investigate further in my case next week.

 

[rdumais63]

Hi Mathieu,

My two simulations started on Friday completed and they are using the same namelist I attached here already except that: (1) one uses hybrid_opt=0, vert_refine_method=2 and rebalance=1 and (2) the other uses hybrid_opt=1, etac=0,25, vert_refine_method=2, and rebalance=1. The results are not terribly diferent but I think that perhaps option 2 is slightly better with the zones. Both still show generally the same boundary zone artifacts we have discussed before, however. My next thought is to try one with hybrid_opt=0 and vert_refine_method=0 and maybe use the vert level structure I now have for either d02 or d03 in my existing namelist for all nests. I could also try another with hybrid_opt=1 and vert_refine_method=0 as well. I do note that I see some of the boundary zone effect in all nests (even a little in nest 1) which I find interesting. I may need to revisit really looking closely at wrfinp fields again. I think we can largely rule out the idea that it is the change of physics between one nest and another (mesoscale to LES) that is a primary driver of this behavior we are seeing or that in my case the use of a 7:1 jump between a mesoscale parametrized turbulence nest and LES nest is the main culprit. Could there be something in the vertical nesting and rebalancing codes that are just introducing (perhaps through a code bug) something undesirable to the lateral boundary tendencies of nests?

 

[rdumais63]

Mathieu- curious if you have had any new things to report from last week's investigations?

 

[MLandreau]

Hi again,

I tried a simulation without vertical nesting, with 52 vertical levels on each 5 domains. The two figures attached here represent the horizontal wind speed on my domains d03, d04, d05 on the right hand side compared with a zoom of their parents domain result (d02, d03, d04) on the left hand side. The colorbar is the same on all plots with velocities from 0 to 6 m/s. The 1st figure (iz2) is plotted on the 3rd cell from the ground and the second picture (iz10) on the 11th cell.
To remind d01, d02 and d03 are RANS and d04, d05 are LES. The namelist is attached for more details.

In 3rd cell level figure, right-hand side plots, we can observe no clear gradient near d02-d03 boundary, a clear gradient zone near d03-d04 boundary and a less evident but still present gradient zone near d04-d05 boundary.
Thanks to left-hand side plots, we can confirm that this gradient is due to an interpolation between parents values on "external boundaries" and nest values on "internal boundaries" which is I think the normal behavior of these 5-cells horizontal zone. Since there is no vertical nesting, this is not the cause of that gradient in my case.
We can also see that when looking at higher levels, this gradient is less sharp.

So why do I get this stronger gradient in my d03-d04 boundary than in d02-d03 and d04-d05 ? Here few possible reasons :
- at this time, d03 has started 15 hours ago, d04, 3 hours ago and d05, 1 hour ago. Aerodynamic fields (air velocity, temp, ...) is initialized from parent but soil fields (TSLB, SMOIS, ...) are initialized from my coarse ERA5 dataset. Soil quantities in d04 and d05 didn't have a sufficient time to spin-up and have a significantly different value than in d03.
- The turbulence modeling is different between d03 and d04. It might suddenly increase drag at the inlet and be responsible for these lower velocities in d04 than in d03.

 

[rdumais63]

Hi again. I have tested a number of new runs including some with no vertical nesting and even no vertical nesting with no hybrid option. They all tend to develop the same behavior we have seen in the lateral zone areas. These seem most evident on the inner nests where I use LES vs PBL scheme and up closer to the top of the model (50 mb - 200 mb range). Most evident in w field at the edges and sometimes both P and PRESSURE. At/nearthe surface the sometimes wind and T show similar behavior in the zone. The thing is, I can sometimes see them on outer nests as well but they are just not as obvious. The use of no vertical nesting and no hybrid option seems to yield the least of this effect but it not without them. The thing is, prior to recently I can not recall seeing these effects to such a degree. I was still testing runs to 1 km or even less but using PBL schemes and not LES. I will next test a setup at night that uses PBL all the way from 9 km and 111 m and with strict 3:1 nest ratios.