Change in spec_zone of lateral boundary conditions during runtime

Topics related to the dynamics/numerics of the WRF model
Post Reply
CWeiss
Posts: 5
Joined: Fri Dec 11, 2020 4:59 pm

Change in spec_zone of lateral boundary conditions during runtime

Post by CWeiss » Fri Dec 11, 2020 5:32 pm

Dear all,

I've a question concerning the lateral boundary conditions for a real case run.

I'm running WRF Verion 4.1 on a distributed memory HPC system.

My region of interest is the Great Rift Valley in Ethiopia.

While running wrf.exe, my lateral boundary conditions changed in the spec_zone. If I understood the documentation (https://www2.mmm.ucar.edu/wrf/users/doc ... 5.htm#Phys -> Lateral Boundary Condition Options d) ), that's usually the region defined and fixed by the input data. I use the HRES analysis from the ECMWF as input data.

After more than 24h runtime, the values for some variables are completely off in the spec_zone. One example is the skin temperature. I'll get values up to 372 K whereas the input data shows values up to 320 K at the same time and area. So the boundary conditions seem to be adapted although they should be fixed.

Does anyone has an idea what happened here?

I'm not in an urgent need but rather interested.
I actually solved it with increasing the layer top from 40hPa to 20hPa (what I should have done in the first place), but still wondering what could be reason for the adaption in the boundary conditions before. I thought of a reflection at the model top or something like this.
Furthermore, it seems that the spec_zone is not fixed after real.exe.

I'll attach my namelist, However, for my "successful" run I changed some more things than just the model top.
I'll also attach a plot generated with ncview that shows in the left hand side (western lateral boundary condition) the abrupt increase of the skin temperature

If more information is needed I'll be happy to provide anything I can.

Looking forward to an answer!
Cheers,
Cornelius
Attachments
namelist.input
(5.78 KiB) Downloaded 11 times
skintemp.png

davegill
Posts: 90
Joined: Mon Apr 23, 2018 9:03 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by davegill » Fri Dec 11, 2020 10:00 pm

This is will a back and forth process.

The lateral boundary conditions do not directly control the physics fields, such as the skin temperature. The lateral boundary conditions in WRF control the dynamics fields that require horizontal differencing to advance the state. It is absolutely possible that one (some / all) of these dynamic fields is (are) having a bad influence on your physics variables.

Look at horizontal (in eta space) plots of the dynamics fields (such as U, V, W, T, PH, QVAPOR, MU). Do the boundaries look discontinuously incorrect? Perhaps you could post a few for us to see. For the 3d fields, look at k=1, k=the top-most-valid-layer, and a middle layer.
Dave Gill
NCAR/MMM

CWeiss
Posts: 5
Joined: Fri Dec 11, 2020 4:59 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by CWeiss » Mon Dec 14, 2020 1:51 pm

Thanks for your reply and sorry for posting the wrong variable.

As you recommended I had a look at some dynamic fields. Some of them exhibit a discontinuously behavior as well. However, just in the lower layers close to the surface for the 3D fields (k=1 or 2).
I'll get for example a negative water vapor mixing ration (QVAPOR) or pretty high geopotential perturbations (PH). I'll attach some plots for those and for perturbation of Theta (T), x-wind component (U, which could be realistic) and perturbation of dry air mass in a column (MU).
Attachments
U.png
T.png
QVAPOR.png
PH.png
MU.png

davegill
Posts: 90
Joined: Mon Apr 23, 2018 9:03 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by davegill » Mon Dec 14, 2020 4:55 pm

OK, we are getting somewhere! As you indicate, there is a unphysical discontinuity for the T field on th western side of your domain. The PH and MU fields look suspect, but they could just be responding to the T field. We are going to focus on the T field (almost a potential temperature field).

We want to compare a vertical profile from an appropriate grid point of the input data (from metgrid) with a vertical profile from the output of the real program (wrfinput_d01). The real program is responsible for the generation of the lateral boundaries and the initial conditions. What we want to see is where the problem is occurring. Is the data bad in metgrid originally? Does valid data come in from metgrid, and it gets messed up by real?

1. On the western side of your domain (preferably in an area of high pressure), pick a point that is as close to zero elevation as possible. If you have an ocean point, great. If not, as low as you can go is preferred.
Q: Why the western side of the domain?
A: Your discontinuities look really bad on the western side.

2. Get a vertical profile of temperaure from metgrid. My toy domain has an ocean point on the eastern boundary. Instead of my point "(73,10)", you would use "(1,some-j-value-that-is-appropriate)".

Code: Select all

ncdump -v TT -f f -b f met_em.d01.2000-01-24_12:00:00.nc | grep "(73,10,"
    296.4829,  // TT(73,10,1,1)
    295.6098,  // TT(73,10,2,1)
    294.3799,  // TT(73,10,3,1)
    292.8598,  // TT(73,10,4,1)
    291.2932,  // TT(73,10,5,1)
    289.7114,  // TT(73,10,6,1)
    288.0058,  // TT(73,10,7,1)
    286.2832,  // TT(73,10,8,1)
    282.7404,  // TT(73,10,9,1)
    278.875,  // TT(73,10,10,1)
    277.48,  // TT(73,10,11,1)
    275.3341,  // TT(73,10,12,1)
    272.1397,  // TT(73,10,13,1)
    267.4374,  // TT(73,10,14,1)
    261.7483,  // TT(73,10,15,1)
    255.4195,  // TT(73,10,16,1)
    248.2741,  // TT(73,10,17,1)
    240.3512,  // TT(73,10,18,1)
    231.5113,  // TT(73,10,19,1)
    221.683,  // TT(73,10,20,1)
    216.7149,  // TT(73,10,21,1)
    212.6502,  // TT(73,10,22,1)
    210.5441,  // TT(73,10,23,1)
    209.2305,  // TT(73,10,24,1)
    207.7082,  // TT(73,10,25,1)
    206.8458,  // TT(73,10,26,1)
3. We want to be able to compute with this data, so we are going to use a few linux commands to strip the information down to just the data we want. Here is what my output would look like:

Code: Select all

ncdump -v TT -f f -b f met_em.d01.2000-01-24_12:00:00.nc | grep "(73,10," | cut -d "," -f1 | awk '{print $1}'
296.4829
295.6098
294.3799
292.8598
291.2932
289.7114
288.0058
286.2832
282.7404
278.875
277.48
275.3341
272.1397
267.4374
261.7483
255.4195
248.2741
240.3512
231.5113
221.683
216.7149
212.6502
210.5441
209.2305
207.7082
206.8458
4. Once this works, we want the output of that column of both temperature and pressure from metgrid, each saved to a file:

Code: Select all

ncdump -v TT -f f -b f met_em.d01.2000-01-24_12:00:00.nc | grep "(73,10," | cut -d "," -f1 | awk '{print $1}' > TT.txt
ncdump -v PRES -f f -b f met_em.d01.2000-01-24_12:00:00.nc | grep "(73,10," | cut -d "," -f1 | awk '{print $1}' > PRES.txt
5. Now, using the same western-side-of-the-domain grid point, repeat this process of collecting a column of data for three fields from the output from the real program. The metgrid program has temperature, so we added the pressure output to be able to compute the potential temperature. For the wrfinput_d01 file, the output potential temperature is available (just offset by 300 K).

Code: Select all

ncdump -v T -f f -b f wrfinput_d01 | grep "(73,10," | cut -d "," -f1 | awk '{print $1}'
-4.753143
-4.557922
-4.288544
-3.8927
-3.412537
-2.958038
-2.422546
-1.736786
-0.9671631
-0.07070923
1.016449
2.023224
4.61618
8.804413
12.51184
15.55624
17.65451
19.3934
21.11127
22.73032
24.45306
26.3429
28.56573
32.21539
41.23279
55.6489
72.1694
90.11481
109.3546
129.6359
151.2271
174.2253
The first value, about -4.75 means a potential temperature of 300 -4.75 = 295.25 K. We want this theta-offset field and the two fields that can be used to reconstruct the pressure: P (perturbation) and PB (reference state). The total pressure at any location is the sum of P and PB.

Code: Select all

ncdump -v T -f f -b f wrfinput_d01 | grep "(73,10," | cut -d "," -f1 | awk '{print $1}' > T.txt
ncdump -v PB -f f -b f wrfinput_d01 | grep "(73,10," | cut -d "," -f1 | awk '{print $1}' > PB.txt
ncdump -v P -f f -b f wrfinput_d01 | grep "(73,10," | cut -d "," -f1 | awk '{print $1}' > P.txt
Again, for all of the above examples, I have used the point (73,10). You will choose an appropriate location on the western edge of your domain.

6. Use your favorite plotting package to look at those vertical columns of data. What we want to know is: are the potential temperatures from metgrid (at the specific pressure surface) about the same as the real program (at similar surfaces)? Do not be concerned that the level closest to the ground is off by several hPa, as we asked for data at the half levels. That is probably about 20 m different, and 2-3 hPa lower for the output from real.

7. I picked a few easy vertical locations to check in my data: about 1000, 900, 500, 300, 100 hPa for both metgrid and real. For some of the real locations I gave two surrounding points.
Screen Shot 2020-12-14 at 9.49.28 AM.png
Screen Shot 2020-12-14 at 9.49.28 AM.png (12.18 KiB) Viewed 473 times
Dave Gill
NCAR/MMM

CWeiss
Posts: 5
Joined: Fri Dec 11, 2020 4:59 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by CWeiss » Sat Jan 23, 2021 4:38 pm

Hi and sorry for my very late response!!

I compared now the potential temperature from the met_em file and the wrfinput file as you suggested.
I picked a point at the very boudary (i=1) and at a possible low elevation (in my case now 196.2m).
The look pretty similar and I think, the error does not arise from one of the preprocessing steps but rather during runtime of the model itself.
After 30h runtime the suspicious values occur. I checked also the met_em file from this time as is influences the boundary conditions but it looks quite normal.

Any ideas, how the boundary could possibly be changed during runtime? Or what else could be the reason for that whole issue?
Thanks a lot for your help!
Cheers,
Cornelius
Attachments
TABLE.txt
(390 Bytes) Downloaded 10 times
potTemp_met_and_input.pdf
(17.83 KiB) Downloaded 9 times

CWeiss
Posts: 5
Joined: Fri Dec 11, 2020 4:59 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by CWeiss » Sat Jan 23, 2021 4:52 pm

Sorry, an addition to the above listed post:

I meant i = 0, so really at the boundary.
Furthermore, I attach the according plot of the wrfout at this point (i=0, j = 373) after 30h runtime when the weird values at the boundary occur.
Attachments
Screenshot from 2021-01-23 17-45-21.png

davegill
Posts: 90
Joined: Mon Apr 23, 2018 9:03 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by davegill » Thu Jan 28, 2021 8:29 pm

The fields from the physics schemes are influenced by lateral boundaries, since fields that are forced by the lateral boundaries (loosely: u, v, t, q, height, pressure) are all input the physics schemes. However, a field such as skin temperature does not get nudged directly via a boundary condition.

Is there a problem in the data at a particular time? You have mentioned that the troubles start at 30 h. Let us call this T30.
  • If you start the model at T24, do you still see troubles at 6-h into the forecast, at T30?
  • If you start the model at T36, does the problem show up?
Dave Gill
NCAR/MMM

CWeiss
Posts: 5
Joined: Fri Dec 11, 2020 4:59 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by CWeiss » Tue Feb 02, 2021 3:26 pm

Thanks for you reply!
So I tried different start times but ran in similar problems/fields. After some runtime the model crashed.
Independent from the start time. Eg. for T6 as well as for T-6. I have not tried times after T30. However, as far as I remember, the runtime differed until the model crashed. It was not always 30hours. But also not always at the the same "real" time. So for example, once it crashed for 15.1. 12 UTC and once for 14.1. 23UTC.
So neither the runtime nor the "real" time revealed a pattern.
I also checked the input data (EC HRES Analysis with 6h intervall), but that looked fine.

davegill
Posts: 90
Joined: Mon Apr 23, 2018 9:03 pm

Re: Change in spec_zone of lateral boundary conditions during runtime

Post by davegill » Tue Feb 02, 2021 5:59 pm

For a sanity check, are you able to get access to a different global data set?

Here is a web site at NCAR:
0.25 degree GFS
Dave Gill
NCAR/MMM

Post Reply

Return to “Dynamics and Numerics”