[Met_help] [rt.rap.ucar.edu #68461] History for vertical interpolation
John Halley Gotway via RT
met_help at ucar.edu
Thu Apr 16 15:10:46 MDT 2015
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I recently had a conversation with John (pasted below) about
vertical interpolation. He suggested that I use a larger vertical range
because my small range didn't have enough levels for interpolation.
Since I am only interested in the mpr files I used the entire range of
levels (z0-1500). Now when I get the results, the observations look
fine but the forecasted fields look terrible (see attached picture).
Any idea what is going on?
Do note, I am using temperature on constant HEIGHT fields and comparing
it to virtual temperature for this demonstration. Using temperature of
constant PRESSURE fields does not have this problem (the forecasted
field looks smooth)
All files needed to reproduce this problem are in
ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
Thanks,
Travis
####################################3
Travis,
Let me start by telling you how Point-Stat does vertical interpolation.
For a range of pressure levels (specified with a letter P, like P250-350),
the vertical interpolation is done linear in the log of pressure. For a
range of any other level type (like Z250-350 for height), it's done
linearly by height.
I took a look at the data you sent and ran the same case for which you sent
me output. I'm reproducing the numbers you're getting identically. To
narrow things down, I reran for just one range:
level = [ "12/P250-350", "12/Z250-350" ]
Here I'm saying to verify virtual temperature between 250 and 350 millibars
(P250-350) and verify it between 250 and 350 meters above ground
(Z250-350). Running point_stat at verbosity level 2, I see the following
output:
DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0 climatology
levels.
...
DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0 climatology
levels.
For the range P250-350, it found data for pressure levels 250, 300, and
350. But for the range Z250-350, it only found data for a single level 300
meters above ground.
When doing vertical interpolation on pressure levels, since we found 3
forecast levels, there's always a pressure level above/below each
observation. So the vertical interpolation can be done smoothly.
But when doing vertical interpolation on height levels, there's only a
single level in that range. So all the observations are matched to that
single level.
I think the problem here is a poor choice of levels for verification.
Based on your settings, it looks like you want to verify using observations
in bands of 100 meters. I'd suggest setting up the level for the forecast
and observation fields a little differently. You could try this:
fcst = {
wind_thresh = [ NA ];
field = [
{
name = "VTMP";
level = [ "Z200-400" ];
cat_thresh = [];
}
];
};
obs = {
field = [
{
name = "VTMP";
level = [ "Z250-350" ];
cat_thresh = [];
}
];
};
This tells point_stat to extract levels 200, 300, and 400 m from the
forecast file and use it for this verification task. But only use
observations falling between 250 and 350 m. That will give point_stat
forecast level data to use for the vertical interpolation above/below each
observation value. But it'll only use the obs falling in your requested
range. And that should enable the vertical interpolation to be done more
smoothly.
I do realize this is confusing. Hopefully that helps clarify.
Thanks,
John
On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<met_help at ucar.edu>
wrote:
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
Hi Randy,
I appreciate the help. I uploaded everything to
/incoming/irap/met_help/wilson_data so you can reproduce the problem if
need be. Thanks!
Travis Wilson
UCLA Atmospheric and Oceanic Sciences
model viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
-----Original Message-----
From: Randy Bullock via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, June 17, 2014 10:02 AM
To:Wilson0028 at ucla.edu
Subject: Re: [rt.rap.ucar.edu #67713] interpolation using constant height
fields
Travis -
I had a look at the code and also a few old met_help questions in order to
get a handle on this. As far as I can tell, interpolation should be
happening. The only times when vertical interpolation doesn't happen is
when you're dealing with surface fields, but it looks from your config file
that that's not the case here.
I'll talk this over with John when gets back from vacation next week, and
see if he has any insights on this.
Randy
On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<met_help at ucar.edu>
wrote:
> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
> Transaction: Ticket created byWilson0028 at ucla.edu
> Queue: met_help
> Subject: interpolation using constant height fields
> Owner: Nobody
> Requestors:Wilson0028 at ucla.edu
> Status: new
> Ticket <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
> Hi John,
> When I use temperature (on constant pressure fields made by
> UPP) to verify the vertical profile, the foretasted field gets
interpolated to
the observation height. Everything looks very smooth (see
constant_pressure_field.png).
Now when I use temperature (on constant height fields made by
UPP), my foretasted field does not get interpolated (see
constant_height_field.png).
I am assuming this has something to do with the fact that the fields
with constant height are in the same grib file that has fields of
constant pressure (and the native coordinate in the UPP grib file is
pressure, not sure how to make it height). my wgrib is below. Any
idea on how to interpolate the forecast fields?
Thanks,
Travis
(note: I am using VTMP)
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
imeU=1:50
mb:anl:NAve=0
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
TimeU=1:100
mb:anl:NAve=0
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
:TimeU=1:150
mb:anl:NAve=0
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
:TimeU=1:200
mb:anl:NAve=0
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
:TimeU=1:250
mb:anl:NAve=0
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
0:TimeU=1:300
mb:anl:NAve=0
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
0:TimeU=1:350
mb:anl:NAve=0
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
0:TimeU=1:400
mb:anl:NAve=0
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
0:TimeU=1:450
mb:anl:NAve=0
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
0:TimeU=1:500
mb:anl:NAve=0
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
0:TimeU=1:550
mb:anl:NAve=0
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
0:TimeU=1:600
mb:anl:NAve=0
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
0:TimeU=1:650
mb:anl:NAve=0
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
0:TimeU=1:700
mb:anl:NAve=0
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
0:TimeU=1:750
mb:anl:NAve=0
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
0:TimeU=1:775
mb:anl:NAve=0
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
0:TimeU=1:800
mb:anl:NAve=0
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
0:TimeU=1:825
mb:anl:NAve=0
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
0:TimeU=1:850
mb:anl:NAve=0
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
0:TimeU=1:875
mb:anl:NAve=0
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
0:TimeU=1:900
mb:anl:NAve=0
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
0:TimeU=1:910
mb:anl:NAve=0
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
0:TimeU=1:920
mb:anl:NAve=0
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
0:TimeU=1:930
mb:anl:NAve=0
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
0:TimeU=1:940
mb:anl:NAve=0
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
0:TimeU=1:950
mb:anl:NAve=0
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
=0:TimeU=1:960
mb:anl:NAve=0
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
=0:TimeU=1:970
mb:anl:NAve=0
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
=0:TimeU=1:980
mb:anl:NAve=0
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
=0:TimeU=1:990
mb:anl:NAve=0
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
2=0:TimeU=1:1000
mb:anl:NAve=0
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
0:TimeU=1:30
m above MSL:anl:NAve=0
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
0:TimeU=1:80
m above MSL:anl:NAve=0
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
=0:TimeU=1:140
m above MSL:anl:NAve=0
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
=0:TimeU=1:200
m above MSL:anl:NAve=0
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
=0:TimeU=1:300
m above MSL:anl:NAve=0
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
=0:TimeU=1:400
m above MSL:anl:NAve=0
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
=0:TimeU=1:500
m above MSL:anl:NAve=0
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
=0:TimeU=1:600
m above MSL:anl:NAve=0
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
=0:TimeU=1:700
m above MSL:anl:NAve=0
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
=0:TimeU=1:800
m above MSL:anl:NAve=0
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
=0:TimeU=1:900
m above MSL:anl:NAve=0
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
2=0:TimeU=1:1000
m above MSL:anl:NAve=0
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
2=0:TimeU=1:1200
m above MSL:anl:NAve=0
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
2=0:TimeU=1:1400
m above MSL:anl:NAve=0
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
2=0:TimeU=1:1600
m above MSL:anl:NAve=0
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
2=0:TimeU=1:1800
m above MSL:anl:NAve=0
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: vertical interpolation
From: John Halley Gotway
Time: Thu Jul 31 12:00:22 2014
Travis,
Sorry for the delay in getting back to you. Thanks for sending your
data.
I took a look in the MPR file you sent
(point_stat_680000L_20110106_200000V_mpr.txt) and noticed an immediate
problem in the first matched pair line. The interpolated forecast
value is
-4552.55954. Of the 246 MPR lines in that file, 5 of them have bogus
forecast values like that:
cat point_stat_680000L_20110106_200000V_mpr.txt | awk '{print $29}'
|
sort -nr
...
FCST
-3422.92840
-4552.55954
-4957.70470
-9793.49776
-9896.13442
After some debugging, I see that the problem is in how we're doing the
vertical interpolation. We compute a forecast value for the levels
above
and below the observation, but fail to check for bad data prior to
doing
the vertical interpolation. The problem is that one them is bad data
since
one of the MSL temperatures is below ground. The fix is to check for
bad
data prior to doing the vertical interpolation and skip this
observation.
That fixes this problem and you'll see the debug level 3 output from
Point-Stat "Rejected: bad fcst value" rejection count increase each
time
this happens.
I'll work up a patch for METv4.1 and post it to the MET website.
I also noticed a pretty bogus observation value for the station named
SACCA
on line 55 of that mpr.txt file:
OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
CLIMO
SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
999999.00000 NA
There isn't any range checking of observation values in MET, but I
just
thought I'd point it out to you.
As for the actual reason you wrote, I'm not sure. What did you use to
create that image you sent? If it's some script that would be easy
for me
to run here, please pass it along. That might help me in debugging
this
further.
Thanks,
John
On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT
<met_help at ucar.edu>
wrote:
>
> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
> Transaction: Ticket created by Wilson0028 at ucla.edu
> Queue: met_help
> Subject: vertical interpolation
> Owner: Nobody
> Requestors: Wilson0028 at ucla.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>
>
> Hi,
> I recently had a conversation with John (pasted below) about
> vertical interpolation. He suggested that I use a larger vertical
range
> because my small range didn't have enough levels for interpolation.
> Since I am only interested in the mpr files I used the entire range
of
> levels (z0-1500). Now when I get the results, the observations look
> fine but the forecasted fields look terrible (see attached picture).
> Any idea what is going on?
>
> Do note, I am using temperature on constant HEIGHT fields and
comparing
> it to virtual temperature for this demonstration. Using temperature
of
> constant PRESSURE fields does not have this problem (the forecasted
> field looks smooth)
>
> All files needed to reproduce this problem are in
> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>
> Thanks,
> Travis
>
>
> ####################################3
>
> Travis,
>
> Let me start by telling you how Point-Stat does vertical
interpolation.
> For a range of pressure levels (specified with a letter P, like
P250-350),
> the vertical interpolation is done linear in the log of pressure.
For a
> range of any other level type (like Z250-350 for height), it's done
> linearly by height.
>
> I took a look at the data you sent and ran the same case for which
you sent
> me output. I'm reproducing the numbers you're getting identically.
To
> narrow things down, I reran for just one range:
> level = [ "12/P250-350", "12/Z250-350" ]
>
> Here I'm saying to verify virtual temperature between 250 and 350
millibars
> (P250-350) and verify it between 250 and 350 meters above ground
> (Z250-350). Running point_stat at verbosity level 2, I see the
following
> output:
> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
climatology
> levels.
> ...
> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
climatology
> levels.
>
> For the range P250-350, it found data for pressure levels 250, 300,
and
> 350. But for the range Z250-350, it only found data for a single
level 300
> meters above ground.
>
> When doing vertical interpolation on pressure levels, since we found
3
> forecast levels, there's always a pressure level above/below each
> observation. So the vertical interpolation can be done smoothly.
>
> But when doing vertical interpolation on height levels, there's only
a
> single level in that range. So all the observations are matched to
that
> single level.
>
> I think the problem here is a poor choice of levels for
verification.
> Based on your settings, it looks like you want to verify using
observations
> in bands of 100 meters. I'd suggest setting up the level for the
forecast
> and observation fields a little differently. You could try this:
>
> fcst = {
> wind_thresh = [ NA ];
>
> field = [
> {
> name = "VTMP";
> level = [ "Z200-400" ];
> cat_thresh = [];
> }
>
> ];
> };
> obs = {
>
> field = [
> {
> name = "VTMP";
> level = [ "Z250-350" ];
> cat_thresh = [];
> }
>
> ];
> };
>
> This tells point_stat to extract levels 200, 300, and 400 m from the
> forecast file and use it for this verification task. But only use
> observations falling between 250 and 350 m. That will give
point_stat
> forecast level data to use for the vertical interpolation
above/below each
> observation value. But it'll only use the obs falling in your
requested
> range. And that should enable the vertical interpolation to be done
more
> smoothly.
>
> I do realize this is confusing. Hopefully that helps clarify.
>
> Thanks,
> John
>
>
>
>
> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via
RT<met_help at ucar.edu>
> wrote:
>
> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
>
> Hi Randy,
> I appreciate the help. I uploaded everything to
> /incoming/irap/met_help/wilson_data so you can reproduce the problem
if
> need be. Thanks!
>
> Travis Wilson
> UCLA Atmospheric and Oceanic Sciences
> model viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>
>
> -----Original Message-----
> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, June 17, 2014 10:02 AM
> To:Wilson0028 at ucla.edu
> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using constant
height
> fields
>
> Travis -
>
> I had a look at the code and also a few old met_help questions in
order to
> get a handle on this. As far as I can tell, interpolation should be
> happening. The only times when vertical interpolation doesn't
happen is
> when you're dealing with surface fields, but it looks from your
config file
> that that's not the case here.
>
> I'll talk this over with John when gets back from vacation next
week, and
> see if he has any insights on this.
>
> Randy
>
>
> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via
RT<met_help at ucar.edu>
> wrote:
>
> > Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
> > Transaction: Ticket created byWilson0028 at ucla.edu
> > Queue: met_help
> > Subject: interpolation using constant height fields
> > Owner: Nobody
> > Requestors:Wilson0028 at ucla.edu
> > Status: new
> > Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
> > Hi John,
> > When I use temperature (on constant pressure fields made
by
> > UPP) to verify the vertical profile, the foretasted field gets
>
> interpolated to
>
> the observation height. Everything looks very smooth (see
> constant_pressure_field.png).
>
> Now when I use temperature (on constant height fields made
by
> UPP), my foretasted field does not get interpolated (see
> constant_height_field.png).
>
> I am assuming this has something to do with the fact that the fields
> with constant height are in the same grib file that has fields of
> constant pressure (and the native coordinate in the UPP grib file is
> pressure, not sure how to make it height). my wgrib is below. Any
> idea on how to interpolate the forecast fields?
>
> Thanks,
> Travis
>
> (note: I am using VTMP)
>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
> imeU=1:50
> mb:anl:NAve=0
>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
> TimeU=1:100
> mb:anl:NAve=0
>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
> :TimeU=1:150
> mb:anl:NAve=0
>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
> :TimeU=1:200
> mb:anl:NAve=0
>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
> :TimeU=1:250
> mb:anl:NAve=0
>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
> 0:TimeU=1:300
> mb:anl:NAve=0
>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
> 0:TimeU=1:350
> mb:anl:NAve=0
>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
> 0:TimeU=1:400
> mb:anl:NAve=0
>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
> 0:TimeU=1:450
> mb:anl:NAve=0
>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
> 0:TimeU=1:500
> mb:anl:NAve=0
>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
> 0:TimeU=1:550
> mb:anl:NAve=0
>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
> 0:TimeU=1:600
> mb:anl:NAve=0
>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
> 0:TimeU=1:650
> mb:anl:NAve=0
>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
> 0:TimeU=1:700
> mb:anl:NAve=0
>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
> 0:TimeU=1:750
> mb:anl:NAve=0
>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
> 0:TimeU=1:775
> mb:anl:NAve=0
>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
> 0:TimeU=1:800
> mb:anl:NAve=0
>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
> 0:TimeU=1:825
> mb:anl:NAve=0
>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
> 0:TimeU=1:850
> mb:anl:NAve=0
>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
> 0:TimeU=1:875
> mb:anl:NAve=0
>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
> 0:TimeU=1:900
> mb:anl:NAve=0
>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
> 0:TimeU=1:910
> mb:anl:NAve=0
>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
> 0:TimeU=1:920
> mb:anl:NAve=0
>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
> 0:TimeU=1:930
> mb:anl:NAve=0
>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
> 0:TimeU=1:940
> mb:anl:NAve=0
>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
> 0:TimeU=1:950
> mb:anl:NAve=0
>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
> =0:TimeU=1:960
> mb:anl:NAve=0
>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
> =0:TimeU=1:970
> mb:anl:NAve=0
>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
> =0:TimeU=1:980
> mb:anl:NAve=0
>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
> =0:TimeU=1:990
> mb:anl:NAve=0
>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
> 2=0:TimeU=1:1000
> mb:anl:NAve=0
>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
> 0:TimeU=1:30
> m above MSL:anl:NAve=0
>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
> 0:TimeU=1:80
> m above MSL:anl:NAve=0
>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
> =0:TimeU=1:140
> m above MSL:anl:NAve=0
>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
> =0:TimeU=1:200
> m above MSL:anl:NAve=0
>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
> =0:TimeU=1:300
> m above MSL:anl:NAve=0
>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
> =0:TimeU=1:400
> m above MSL:anl:NAve=0
>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
> =0:TimeU=1:500
> m above MSL:anl:NAve=0
>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
> =0:TimeU=1:600
> m above MSL:anl:NAve=0
>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
> =0:TimeU=1:700
> m above MSL:anl:NAve=0
>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
> =0:TimeU=1:800
> m above MSL:anl:NAve=0
>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
> =0:TimeU=1:900
> m above MSL:anl:NAve=0
>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
> 2=0:TimeU=1:1000
> m above MSL:anl:NAve=0
>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
> 2=0:TimeU=1:1200
> m above MSL:anl:NAve=0
>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
> 2=0:TimeU=1:1400
> m above MSL:anl:NAve=0
>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
> 2=0:TimeU=1:1600
> m above MSL:anl:NAve=0
>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
> 2=0:TimeU=1:1800
> m above MSL:anl:NAve=0
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #68461] vertical interpolation
From: Travis Wilson
Time: Thu Jul 31 12:18:15 2014
Hi John,
I forgot to mention that the picture was showing station CCLCA. I
was aware of the bad forecast fields but that is because they are
below
ground. I assume those bad observations would affect the first level
or
two but not all the way up the profile.
I'll send you the script I use to make these plots in another email (I
need to simplify it first). It may be easiest just to look at the
forecast field of CCLCA in the mpr file. You will see that the
temperature increases/decreases/increases/decrease all the way up the
profile. If you recompute this using a range like P1000-850, the
temperature profile looks fine.
On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
> Travis,
>
> Sorry for the delay in getting back to you. Thanks for sending your
data.
> I took a look in the MPR file you sent
> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
> problem in the first matched pair line. The interpolated forecast
value is
> -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
> forecast values like that:
>
> cat point_stat_680000L_20110106_200000V_mpr.txt | awk '{print
$29}' |
> sort -nr
> ...
> FCST
> -3422.92840
> -4552.55954
> -4957.70470
> -9793.49776
> -9896.13442
>
> After some debugging, I see that the problem is in how we're doing
the
> vertical interpolation. We compute a forecast value for the levels
above
> and below the observation, but fail to check for bad data prior to
doing
> the vertical interpolation. The problem is that one them is bad
data since
> one of the MSL temperatures is below ground. The fix is to check
for bad
> data prior to doing the vertical interpolation and skip this
observation.
> That fixes this problem and you'll see the debug level 3 output from
> Point-Stat "Rejected: bad fcst value" rejection count increase each
time
> this happens.
>
> I'll work up a patch for METv4.1 and post it to the MET website.
>
> I also noticed a pretty bogus observation value for the station
named SACCA
> on line 55 of that mpr.txt file:
> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
> CLIMO
> SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
999999.00000 NA
>
> There isn't any range checking of observation values in MET, but I
just
> thought I'd point it out to you.
>
> As for the actual reason you wrote, I'm not sure. What did you use
to
> create that image you sent? If it's some script that would be easy
for me
> to run here, please pass it along. That might help me in debugging
this
> further.
>
> Thanks,
> John
>
>
>
>
>
>
>
> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT
<met_help at ucar.edu>
> wrote:
>
>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
>> Transaction: Ticket created by Wilson0028 at ucla.edu
>> Queue: met_help
>> Subject: vertical interpolation
>> Owner: Nobody
>> Requestors: Wilson0028 at ucla.edu
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>
>>
>> Hi,
>> I recently had a conversation with John (pasted below) about
>> vertical interpolation. He suggested that I use a larger vertical
range
>> because my small range didn't have enough levels for interpolation.
>> Since I am only interested in the mpr files I used the entire range
of
>> levels (z0-1500). Now when I get the results, the observations
look
>> fine but the forecasted fields look terrible (see attached
picture).
>> Any idea what is going on?
>>
>> Do note, I am using temperature on constant HEIGHT fields and
comparing
>> it to virtual temperature for this demonstration. Using
temperature of
>> constant PRESSURE fields does not have this problem (the forecasted
>> field looks smooth)
>>
>> All files needed to reproduce this problem are in
>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>>
>> Thanks,
>> Travis
>>
>>
>> ####################################3
>>
>> Travis,
>>
>> Let me start by telling you how Point-Stat does vertical
interpolation.
>> For a range of pressure levels (specified with a letter P, like
P250-350),
>> the vertical interpolation is done linear in the log of pressure.
For a
>> range of any other level type (like Z250-350 for height), it's done
>> linearly by height.
>>
>> I took a look at the data you sent and ran the same case for which
you sent
>> me output. I'm reproducing the numbers you're getting identically.
To
>> narrow things down, I reran for just one range:
>> level = [ "12/P250-350", "12/Z250-350" ]
>>
>> Here I'm saying to verify virtual temperature between 250 and 350
millibars
>> (P250-350) and verify it between 250 and 350 meters above ground
>> (Z250-350). Running point_stat at verbosity level 2, I see the
following
>> output:
>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
climatology
>> levels.
>> ...
>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
climatology
>> levels.
>>
>> For the range P250-350, it found data for pressure levels 250, 300,
and
>> 350. But for the range Z250-350, it only found data for a single
level 300
>> meters above ground.
>>
>> When doing vertical interpolation on pressure levels, since we
found 3
>> forecast levels, there's always a pressure level above/below each
>> observation. So the vertical interpolation can be done smoothly.
>>
>> But when doing vertical interpolation on height levels, there's
only a
>> single level in that range. So all the observations are matched to
that
>> single level.
>>
>> I think the problem here is a poor choice of levels for
verification.
>> Based on your settings, it looks like you want to verify using
observations
>> in bands of 100 meters. I'd suggest setting up the level for the
forecast
>> and observation fields a little differently. You could try this:
>>
>> fcst = {
>> wind_thresh = [ NA ];
>>
>> field = [
>> {
>> name = "VTMP";
>> level = [ "Z200-400" ];
>> cat_thresh = [];
>> }
>>
>> ];
>> };
>> obs = {
>>
>> field = [
>> {
>> name = "VTMP";
>> level = [ "Z250-350" ];
>> cat_thresh = [];
>> }
>>
>> ];
>> };
>>
>> This tells point_stat to extract levels 200, 300, and 400 m from
the
>> forecast file and use it for this verification task. But only use
>> observations falling between 250 and 350 m. That will give
point_stat
>> forecast level data to use for the vertical interpolation
above/below each
>> observation value. But it'll only use the obs falling in your
requested
>> range. And that should enable the vertical interpolation to be
done more
>> smoothly.
>>
>> I do realize this is confusing. Hopefully that helps clarify.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via
RT<met_help at ucar.edu>
>> wrote:
>>
>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
>>
>> Hi Randy,
>> I appreciate the help. I uploaded everything to
>> /incoming/irap/met_help/wilson_data so you can reproduce the
problem if
>> need be. Thanks!
>>
>> Travis Wilson
>> UCLA Atmospheric and Oceanic Sciences
>> model viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>>
>>
>> -----Original Message-----
>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
>> Sent: Tuesday, June 17, 2014 10:02 AM
>> To:Wilson0028 at ucla.edu
>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using constant
height
>> fields
>>
>> Travis -
>>
>> I had a look at the code and also a few old met_help questions in
order to
>> get a handle on this. As far as I can tell, interpolation should
be
>> happening. The only times when vertical interpolation doesn't
happen is
>> when you're dealing with surface fields, but it looks from your
config file
>> that that's not the case here.
>>
>> I'll talk this over with John when gets back from vacation next
week, and
>> see if he has any insights on this.
>>
>> Randy
>>
>>
>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via
RT<met_help at ucar.edu>
>> wrote:
>>
>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
>>> Transaction: Ticket created byWilson0028 at ucla.edu
>>> Queue: met_help
>>> Subject: interpolation using constant height fields
>>> Owner: Nobody
>>> Requestors:Wilson0028 at ucla.edu
>>> Status: new
>>> Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>>> Hi John,
>>> When I use temperature (on constant pressure fields made
by
>>> UPP) to verify the vertical profile, the foretasted field gets
>> interpolated to
>>
>> the observation height. Everything looks very smooth (see
>> constant_pressure_field.png).
>>
>> Now when I use temperature (on constant height fields
made by
>> UPP), my foretasted field does not get interpolated (see
>> constant_height_field.png).
>>
>> I am assuming this has something to do with the fact that the
fields
>> with constant height are in the same grib file that has fields of
>> constant pressure (and the native coordinate in the UPP grib file
is
>> pressure, not sure how to make it height). my wgrib is below. Any
>> idea on how to interpolate the forecast fields?
>>
>> Thanks,
>> Travis
>>
>> (note: I am using VTMP)
>>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
>> imeU=1:50
>> mb:anl:NAve=0
>>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
>> TimeU=1:100
>> mb:anl:NAve=0
>>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
>> :TimeU=1:150
>> mb:anl:NAve=0
>>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
>> :TimeU=1:200
>> mb:anl:NAve=0
>>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
>> :TimeU=1:250
>> mb:anl:NAve=0
>>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
>> 0:TimeU=1:300
>> mb:anl:NAve=0
>>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
>> 0:TimeU=1:350
>> mb:anl:NAve=0
>>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
>> 0:TimeU=1:400
>> mb:anl:NAve=0
>>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
>> 0:TimeU=1:450
>> mb:anl:NAve=0
>>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
>> 0:TimeU=1:500
>> mb:anl:NAve=0
>>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
>> 0:TimeU=1:550
>> mb:anl:NAve=0
>>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
>> 0:TimeU=1:600
>> mb:anl:NAve=0
>>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
>> 0:TimeU=1:650
>> mb:anl:NAve=0
>>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
>> 0:TimeU=1:700
>> mb:anl:NAve=0
>>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
>> 0:TimeU=1:750
>> mb:anl:NAve=0
>>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
>> 0:TimeU=1:775
>> mb:anl:NAve=0
>>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
>> 0:TimeU=1:800
>> mb:anl:NAve=0
>>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
>> 0:TimeU=1:825
>> mb:anl:NAve=0
>>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
>> 0:TimeU=1:850
>> mb:anl:NAve=0
>>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
>> 0:TimeU=1:875
>> mb:anl:NAve=0
>>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
>> 0:TimeU=1:900
>> mb:anl:NAve=0
>>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
>> 0:TimeU=1:910
>> mb:anl:NAve=0
>>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
>> 0:TimeU=1:920
>> mb:anl:NAve=0
>>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
>> 0:TimeU=1:930
>> mb:anl:NAve=0
>>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
>> 0:TimeU=1:940
>> mb:anl:NAve=0
>>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
>> 0:TimeU=1:950
>> mb:anl:NAve=0
>>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
>> =0:TimeU=1:960
>> mb:anl:NAve=0
>>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
>> =0:TimeU=1:970
>> mb:anl:NAve=0
>>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
>> =0:TimeU=1:980
>> mb:anl:NAve=0
>>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
>> =0:TimeU=1:990
>> mb:anl:NAve=0
>>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
>> 2=0:TimeU=1:1000
>> mb:anl:NAve=0
>>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
>> 0:TimeU=1:30
>> m above MSL:anl:NAve=0
>>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
>> 0:TimeU=1:80
>> m above MSL:anl:NAve=0
>>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
>> =0:TimeU=1:140
>> m above MSL:anl:NAve=0
>>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
>> =0:TimeU=1:200
>> m above MSL:anl:NAve=0
>>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
>> =0:TimeU=1:300
>> m above MSL:anl:NAve=0
>>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
>> =0:TimeU=1:400
>> m above MSL:anl:NAve=0
>>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
>> =0:TimeU=1:500
>> m above MSL:anl:NAve=0
>>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
>> =0:TimeU=1:600
>> m above MSL:anl:NAve=0
>>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
>> =0:TimeU=1:700
>> m above MSL:anl:NAve=0
>>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
>> =0:TimeU=1:800
>> m above MSL:anl:NAve=0
>>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
>> =0:TimeU=1:900
>> m above MSL:anl:NAve=0
>>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
>> 2=0:TimeU=1:1000
>> m above MSL:anl:NAve=0
>>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
>> 2=0:TimeU=1:1200
>> m above MSL:anl:NAve=0
>>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
>> 2=0:TimeU=1:1400
>> m above MSL:anl:NAve=0
>>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
>> 2=0:TimeU=1:1600
>> m above MSL:anl:NAve=0
>>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
>> 2=0:TimeU=1:1800
>> m above MSL:anl:NAve=0
>>
>>
>>
>>
------------------------------------------------
Subject: vertical interpolation
From: Travis Wilson
Time: Thu Jul 31 13:00:29 2014
Hi John,
The following commands will reproduce the plots. Run the script
in
the same directory as the mpr file. The scripts require bash, perl,
and
gnuplot.
bash run_graph_aircraft_mpr.sh
bash plot_vert.sh
On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
> Travis,
>
> Sorry for the delay in getting back to you. Thanks for sending your
data.
> I took a look in the MPR file you sent
> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
> problem in the first matched pair line. The interpolated forecast
value is
> -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
> forecast values like that:
>
> cat point_stat_680000L_20110106_200000V_mpr.txt | awk '{print
$29}' |
> sort -nr
> ...
> FCST
> -3422.92840
> -4552.55954
> -4957.70470
> -9793.49776
> -9896.13442
>
> After some debugging, I see that the problem is in how we're doing
the
> vertical interpolation. We compute a forecast value for the levels
above
> and below the observation, but fail to check for bad data prior to
doing
> the vertical interpolation. The problem is that one them is bad
data since
> one of the MSL temperatures is below ground. The fix is to check
for bad
> data prior to doing the vertical interpolation and skip this
observation.
> That fixes this problem and you'll see the debug level 3 output from
> Point-Stat "Rejected: bad fcst value" rejection count increase each
time
> this happens.
>
> I'll work up a patch for METv4.1 and post it to the MET website.
>
> I also noticed a pretty bogus observation value for the station
named SACCA
> on line 55 of that mpr.txt file:
> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
> CLIMO
> SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
999999.00000 NA
>
> There isn't any range checking of observation values in MET, but I
just
> thought I'd point it out to you.
>
> As for the actual reason you wrote, I'm not sure. What did you use
to
> create that image you sent? If it's some script that would be easy
for me
> to run here, please pass it along. That might help me in debugging
this
> further.
>
> Thanks,
> John
>
>
>
>
>
>
>
> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT
<met_help at ucar.edu>
> wrote:
>
>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
>> Transaction: Ticket created by Wilson0028 at ucla.edu
>> Queue: met_help
>> Subject: vertical interpolation
>> Owner: Nobody
>> Requestors: Wilson0028 at ucla.edu
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>
>>
>> Hi,
>> I recently had a conversation with John (pasted below) about
>> vertical interpolation. He suggested that I use a larger vertical
range
>> because my small range didn't have enough levels for interpolation.
>> Since I am only interested in the mpr files I used the entire range
of
>> levels (z0-1500). Now when I get the results, the observations
look
>> fine but the forecasted fields look terrible (see attached
picture).
>> Any idea what is going on?
>>
>> Do note, I am using temperature on constant HEIGHT fields and
comparing
>> it to virtual temperature for this demonstration. Using
temperature of
>> constant PRESSURE fields does not have this problem (the forecasted
>> field looks smooth)
>>
>> All files needed to reproduce this problem are in
>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>>
>> Thanks,
>> Travis
>>
>>
>> ####################################3
>>
>> Travis,
>>
>> Let me start by telling you how Point-Stat does vertical
interpolation.
>> For a range of pressure levels (specified with a letter P, like
P250-350),
>> the vertical interpolation is done linear in the log of pressure.
For a
>> range of any other level type (like Z250-350 for height), it's done
>> linearly by height.
>>
>> I took a look at the data you sent and ran the same case for which
you sent
>> me output. I'm reproducing the numbers you're getting identically.
To
>> narrow things down, I reran for just one range:
>> level = [ "12/P250-350", "12/Z250-350" ]
>>
>> Here I'm saying to verify virtual temperature between 250 and 350
millibars
>> (P250-350) and verify it between 250 and 350 meters above ground
>> (Z250-350). Running point_stat at verbosity level 2, I see the
following
>> output:
>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
climatology
>> levels.
>> ...
>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
climatology
>> levels.
>>
>> For the range P250-350, it found data for pressure levels 250, 300,
and
>> 350. But for the range Z250-350, it only found data for a single
level 300
>> meters above ground.
>>
>> When doing vertical interpolation on pressure levels, since we
found 3
>> forecast levels, there's always a pressure level above/below each
>> observation. So the vertical interpolation can be done smoothly.
>>
>> But when doing vertical interpolation on height levels, there's
only a
>> single level in that range. So all the observations are matched to
that
>> single level.
>>
>> I think the problem here is a poor choice of levels for
verification.
>> Based on your settings, it looks like you want to verify using
observations
>> in bands of 100 meters. I'd suggest setting up the level for the
forecast
>> and observation fields a little differently. You could try this:
>>
>> fcst = {
>> wind_thresh = [ NA ];
>>
>> field = [
>> {
>> name = "VTMP";
>> level = [ "Z200-400" ];
>> cat_thresh = [];
>> }
>>
>> ];
>> };
>> obs = {
>>
>> field = [
>> {
>> name = "VTMP";
>> level = [ "Z250-350" ];
>> cat_thresh = [];
>> }
>>
>> ];
>> };
>>
>> This tells point_stat to extract levels 200, 300, and 400 m from
the
>> forecast file and use it for this verification task. But only use
>> observations falling between 250 and 350 m. That will give
point_stat
>> forecast level data to use for the vertical interpolation
above/below each
>> observation value. But it'll only use the obs falling in your
requested
>> range. And that should enable the vertical interpolation to be
done more
>> smoothly.
>>
>> I do realize this is confusing. Hopefully that helps clarify.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via
RT<met_help at ucar.edu>
>> wrote:
>>
>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
>>
>> Hi Randy,
>> I appreciate the help. I uploaded everything to
>> /incoming/irap/met_help/wilson_data so you can reproduce the
problem if
>> need be. Thanks!
>>
>> Travis Wilson
>> UCLA Atmospheric and Oceanic Sciences
>> model viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>>
>>
>> -----Original Message-----
>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
>> Sent: Tuesday, June 17, 2014 10:02 AM
>> To:Wilson0028 at ucla.edu
>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using constant
height
>> fields
>>
>> Travis -
>>
>> I had a look at the code and also a few old met_help questions in
order to
>> get a handle on this. As far as I can tell, interpolation should
be
>> happening. The only times when vertical interpolation doesn't
happen is
>> when you're dealing with surface fields, but it looks from your
config file
>> that that's not the case here.
>>
>> I'll talk this over with John when gets back from vacation next
week, and
>> see if he has any insights on this.
>>
>> Randy
>>
>>
>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via
RT<met_help at ucar.edu>
>> wrote:
>>
>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
>>> Transaction: Ticket created byWilson0028 at ucla.edu
>>> Queue: met_help
>>> Subject: interpolation using constant height fields
>>> Owner: Nobody
>>> Requestors:Wilson0028 at ucla.edu
>>> Status: new
>>> Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>>> Hi John,
>>> When I use temperature (on constant pressure fields made
by
>>> UPP) to verify the vertical profile, the foretasted field gets
>> interpolated to
>>
>> the observation height. Everything looks very smooth (see
>> constant_pressure_field.png).
>>
>> Now when I use temperature (on constant height fields
made by
>> UPP), my foretasted field does not get interpolated (see
>> constant_height_field.png).
>>
>> I am assuming this has something to do with the fact that the
fields
>> with constant height are in the same grib file that has fields of
>> constant pressure (and the native coordinate in the UPP grib file
is
>> pressure, not sure how to make it height). my wgrib is below. Any
>> idea on how to interpolate the forecast fields?
>>
>> Thanks,
>> Travis
>>
>> (note: I am using VTMP)
>>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
>> imeU=1:50
>> mb:anl:NAve=0
>>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
>> TimeU=1:100
>> mb:anl:NAve=0
>>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
>> :TimeU=1:150
>> mb:anl:NAve=0
>>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
>> :TimeU=1:200
>> mb:anl:NAve=0
>>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
>> :TimeU=1:250
>> mb:anl:NAve=0
>>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
>> 0:TimeU=1:300
>> mb:anl:NAve=0
>>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
>> 0:TimeU=1:350
>> mb:anl:NAve=0
>>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
>> 0:TimeU=1:400
>> mb:anl:NAve=0
>>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
>> 0:TimeU=1:450
>> mb:anl:NAve=0
>>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
>> 0:TimeU=1:500
>> mb:anl:NAve=0
>>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
>> 0:TimeU=1:550
>> mb:anl:NAve=0
>>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
>> 0:TimeU=1:600
>> mb:anl:NAve=0
>>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
>> 0:TimeU=1:650
>> mb:anl:NAve=0
>>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
>> 0:TimeU=1:700
>> mb:anl:NAve=0
>>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
>> 0:TimeU=1:750
>> mb:anl:NAve=0
>>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
>> 0:TimeU=1:775
>> mb:anl:NAve=0
>>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
>> 0:TimeU=1:800
>> mb:anl:NAve=0
>>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
>> 0:TimeU=1:825
>> mb:anl:NAve=0
>>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
>> 0:TimeU=1:850
>> mb:anl:NAve=0
>>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
>> 0:TimeU=1:875
>> mb:anl:NAve=0
>>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
>> 0:TimeU=1:900
>> mb:anl:NAve=0
>>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
>> 0:TimeU=1:910
>> mb:anl:NAve=0
>>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
>> 0:TimeU=1:920
>> mb:anl:NAve=0
>>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
>> 0:TimeU=1:930
>> mb:anl:NAve=0
>>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
>> 0:TimeU=1:940
>> mb:anl:NAve=0
>>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
>> 0:TimeU=1:950
>> mb:anl:NAve=0
>>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
>> =0:TimeU=1:960
>> mb:anl:NAve=0
>>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
>> =0:TimeU=1:970
>> mb:anl:NAve=0
>>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
>> =0:TimeU=1:980
>> mb:anl:NAve=0
>>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
>> =0:TimeU=1:990
>> mb:anl:NAve=0
>>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
>> 2=0:TimeU=1:1000
>> mb:anl:NAve=0
>>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
>> 0:TimeU=1:30
>> m above MSL:anl:NAve=0
>>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
>> 0:TimeU=1:80
>> m above MSL:anl:NAve=0
>>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
>> =0:TimeU=1:140
>> m above MSL:anl:NAve=0
>>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
>> =0:TimeU=1:200
>> m above MSL:anl:NAve=0
>>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
>> =0:TimeU=1:300
>> m above MSL:anl:NAve=0
>>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
>> =0:TimeU=1:400
>> m above MSL:anl:NAve=0
>>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
>> =0:TimeU=1:500
>> m above MSL:anl:NAve=0
>>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
>> =0:TimeU=1:600
>> m above MSL:anl:NAve=0
>>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
>> =0:TimeU=1:700
>> m above MSL:anl:NAve=0
>>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
>> =0:TimeU=1:800
>> m above MSL:anl:NAve=0
>>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
>> =0:TimeU=1:900
>> m above MSL:anl:NAve=0
>>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
>> 2=0:TimeU=1:1000
>> m above MSL:anl:NAve=0
>>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
>> 2=0:TimeU=1:1200
>> m above MSL:anl:NAve=0
>>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
>> 2=0:TimeU=1:1400
>> m above MSL:anl:NAve=0
>>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
>> 2=0:TimeU=1:1600
>> m above MSL:anl:NAve=0
>>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
>> 2=0:TimeU=1:1800
>> m above MSL:anl:NAve=0
>>
>>
>>
>>
------------------------------------------------
Subject: vertical interpolation
From: John Halley Gotway
Time: Thu Jul 31 14:08:23 2014
Travis,
I just posted a bugfix for that vertical interpolation problem...
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
Sorry for the hassle, but thanks for making us aware of the issue!
I'll look more into your original question now.
Thanks,
John
On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>
> Hi John,
> The following commands will reproduce the plots. Run the
script in
> the same directory as the mpr file. The scripts require bash, perl,
and
> gnuplot.
>
> bash run_graph_aircraft_mpr.sh
> bash plot_vert.sh
>
> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
> > Travis,
> >
> > Sorry for the delay in getting back to you. Thanks for sending
your
> data.
> > I took a look in the MPR file you sent
> > (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
> > problem in the first matched pair line. The interpolated forecast
value
> is
> > -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
> > forecast values like that:
> >
> > cat point_stat_680000L_20110106_200000V_mpr.txt | awk '{print
$29}' |
> > sort -nr
> > ...
> > FCST
> > -3422.92840
> > -4552.55954
> > -4957.70470
> > -9793.49776
> > -9896.13442
> >
> > After some debugging, I see that the problem is in how we're doing
the
> > vertical interpolation. We compute a forecast value for the
levels above
> > and below the observation, but fail to check for bad data prior to
doing
> > the vertical interpolation. The problem is that one them is bad
data
> since
> > one of the MSL temperatures is below ground. The fix is to check
for bad
> > data prior to doing the vertical interpolation and skip this
observation.
> > That fixes this problem and you'll see the debug level 3 output
from
> > Point-Stat "Rejected: bad fcst value" rejection count increase
each time
> > this happens.
> >
> > I'll work up a patch for METv4.1 and post it to the MET website.
> >
> > I also noticed a pretty bogus observation value for the station
named
> SACCA
> > on line 55 of that mpr.txt file:
> > OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
> > CLIMO
> > SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
> 999999.00000 NA
> >
> > There isn't any range checking of observation values in MET, but I
just
> > thought I'd point it out to you.
> >
> > As for the actual reason you wrote, I'm not sure. What did you
use to
> > create that image you sent? If it's some script that would be
easy for
> me
> > to run here, please pass it along. That might help me in
debugging this
> > further.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
> >> Transaction: Ticket created by Wilson0028 at ucla.edu
> >> Queue: met_help
> >> Subject: vertical interpolation
> >> Owner: Nobody
> >> Requestors: Wilson0028 at ucla.edu
> >> Status: new
> >> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
> >
> >>
> >>
> >> Hi,
> >> I recently had a conversation with John (pasted below)
about
> >> vertical interpolation. He suggested that I use a larger
vertical range
> >> because my small range didn't have enough levels for
interpolation.
> >> Since I am only interested in the mpr files I used the entire
range of
> >> levels (z0-1500). Now when I get the results, the observations
look
> >> fine but the forecasted fields look terrible (see attached
picture).
> >> Any idea what is going on?
> >>
> >> Do note, I am using temperature on constant HEIGHT fields and
comparing
> >> it to virtual temperature for this demonstration. Using
temperature of
> >> constant PRESSURE fields does not have this problem (the
forecasted
> >> field looks smooth)
> >>
> >> All files needed to reproduce this problem are in
> >> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
> >>
> >> Thanks,
> >> Travis
> >>
> >>
> >> ####################################3
> >>
> >> Travis,
> >>
> >> Let me start by telling you how Point-Stat does vertical
interpolation.
> >> For a range of pressure levels (specified with a letter P, like
> P250-350),
> >> the vertical interpolation is done linear in the log of pressure.
For a
> >> range of any other level type (like Z250-350 for height), it's
done
> >> linearly by height.
> >>
> >> I took a look at the data you sent and ran the same case for
which you
> sent
> >> me output. I'm reproducing the numbers you're getting
identically. To
> >> narrow things down, I reran for just one range:
> >> level = [ "12/P250-350", "12/Z250-350" ]
> >>
> >> Here I'm saying to verify virtual temperature between 250 and 350
> millibars
> >> (P250-350) and verify it between 250 and 350 meters above ground
> >> (Z250-350). Running point_stat at verbosity level 2, I see the
> following
> >> output:
> >> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
> climatology
> >> levels.
> >> ...
> >> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
> climatology
> >> levels.
> >>
> >> For the range P250-350, it found data for pressure levels 250,
300, and
> >> 350. But for the range Z250-350, it only found data for a single
level
> 300
> >> meters above ground.
> >>
> >> When doing vertical interpolation on pressure levels, since we
found 3
> >> forecast levels, there's always a pressure level above/below each
> >> observation. So the vertical interpolation can be done smoothly.
> >>
> >> But when doing vertical interpolation on height levels, there's
only a
> >> single level in that range. So all the observations are matched
to that
> >> single level.
> >>
> >> I think the problem here is a poor choice of levels for
verification.
> >> Based on your settings, it looks like you want to verify using
> observations
> >> in bands of 100 meters. I'd suggest setting up the level for the
> forecast
> >> and observation fields a little differently. You could try this:
> >>
> >> fcst = {
> >> wind_thresh = [ NA ];
> >>
> >> field = [
> >> {
> >> name = "VTMP";
> >> level = [ "Z200-400" ];
> >> cat_thresh = [];
> >> }
> >>
> >> ];
> >> };
> >> obs = {
> >>
> >> field = [
> >> {
> >> name = "VTMP";
> >> level = [ "Z250-350" ];
> >> cat_thresh = [];
> >> }
> >>
> >> ];
> >> };
> >>
> >> This tells point_stat to extract levels 200, 300, and 400 m from
the
> >> forecast file and use it for this verification task. But only
use
> >> observations falling between 250 and 350 m. That will give
point_stat
> >> forecast level data to use for the vertical interpolation
above/below
> each
> >> observation value. But it'll only use the obs falling in your
requested
> >> range. And that should enable the vertical interpolation to be
done
> more
> >> smoothly.
> >>
> >> I do realize this is confusing. Hopefully that helps clarify.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >>
> >> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
> met_help at ucar.edu>
> >> wrote:
> >>
> >> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
> >>
> >> Hi Randy,
> >> I appreciate the help. I uploaded everything to
> >> /incoming/irap/met_help/wilson_data so you can reproduce the
problem if
> >> need be. Thanks!
> >>
> >> Travis Wilson
> >> UCLA Atmospheric and Oceanic Sciences
> >> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
> >>
> >>
> >> -----Original Message-----
> >> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
> >> Sent: Tuesday, June 17, 2014 10:02 AM
> >> To:Wilson0028 at ucla.edu
> >> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
> height
> >> fields
> >>
> >> Travis -
> >>
> >> I had a look at the code and also a few old met_help questions in
order
> to
> >> get a handle on this. As far as I can tell, interpolation should
be
> >> happening. The only times when vertical interpolation doesn't
happen is
> >> when you're dealing with surface fields, but it looks from your
config
> file
> >> that that's not the case here.
> >>
> >> I'll talk this over with John when gets back from vacation next
week,
> and
> >> see if he has any insights on this.
> >>
> >> Randy
> >>
> >>
> >> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via
RT<met_help at ucar.edu
> >
> >> wrote:
> >>
> >>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
> >>> Transaction: Ticket created byWilson0028 at ucla.edu
> >>> Queue: met_help
> >>> Subject: interpolation using constant height fields
> >>> Owner: Nobody
> >>> Requestors:Wilson0028 at ucla.edu
> >>> Status: new
> >>> Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
> >>> Hi John,
> >>> When I use temperature (on constant pressure fields
made by
> >>> UPP) to verify the vertical profile, the foretasted field gets
> >> interpolated to
> >>
> >> the observation height. Everything looks very smooth (see
> >> constant_pressure_field.png).
> >>
> >> Now when I use temperature (on constant height fields
made by
> >> UPP), my foretasted field does not get interpolated (see
> >> constant_height_field.png).
> >>
> >> I am assuming this has something to do with the fact that the
fields
> >> with constant height are in the same grib file that has fields of
> >> constant pressure (and the native coordinate in the UPP grib file
is
> >> pressure, not sure how to make it height). my wgrib is below.
Any
> >> idea on how to interpolate the forecast fields?
> >>
> >> Thanks,
> >> Travis
> >>
> >> (note: I am using VTMP)
> >>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
> >> imeU=1:50
> >> mb:anl:NAve=0
> >>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
> >> TimeU=1:100
> >> mb:anl:NAve=0
> >>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
> >> :TimeU=1:150
> >> mb:anl:NAve=0
> >>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
> >> :TimeU=1:200
> >> mb:anl:NAve=0
> >>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
> >> :TimeU=1:250
> >> mb:anl:NAve=0
> >>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
> >> 0:TimeU=1:300
> >> mb:anl:NAve=0
> >>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
> >> 0:TimeU=1:350
> >> mb:anl:NAve=0
> >>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
> >> 0:TimeU=1:400
> >> mb:anl:NAve=0
> >>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
> >> 0:TimeU=1:450
> >> mb:anl:NAve=0
> >>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
> >> 0:TimeU=1:500
> >> mb:anl:NAve=0
> >>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
> >> 0:TimeU=1:550
> >> mb:anl:NAve=0
> >>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
> >> 0:TimeU=1:600
> >> mb:anl:NAve=0
> >>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
> >> 0:TimeU=1:650
> >> mb:anl:NAve=0
> >>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
> >> 0:TimeU=1:700
> >> mb:anl:NAve=0
> >>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
> >> 0:TimeU=1:750
> >> mb:anl:NAve=0
> >>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
> >> 0:TimeU=1:775
> >> mb:anl:NAve=0
> >>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
> >> 0:TimeU=1:800
> >> mb:anl:NAve=0
> >>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
> >> 0:TimeU=1:825
> >> mb:anl:NAve=0
> >>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
> >> 0:TimeU=1:850
> >> mb:anl:NAve=0
> >>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
> >> 0:TimeU=1:875
> >> mb:anl:NAve=0
> >>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
> >> 0:TimeU=1:900
> >> mb:anl:NAve=0
> >>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
> >> 0:TimeU=1:910
> >> mb:anl:NAve=0
> >>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
> >> 0:TimeU=1:920
> >> mb:anl:NAve=0
> >>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
> >> 0:TimeU=1:930
> >> mb:anl:NAve=0
> >>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
> >> 0:TimeU=1:940
> >> mb:anl:NAve=0
> >>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
> >> 0:TimeU=1:950
> >> mb:anl:NAve=0
> >>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
> >> =0:TimeU=1:960
> >> mb:anl:NAve=0
> >>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
> >> =0:TimeU=1:970
> >> mb:anl:NAve=0
> >>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
> >> =0:TimeU=1:980
> >> mb:anl:NAve=0
> >>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
> >> =0:TimeU=1:990
> >> mb:anl:NAve=0
> >>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
> >> 2=0:TimeU=1:1000
> >> mb:anl:NAve=0
> >>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
> >> 0:TimeU=1:30
> >> m above MSL:anl:NAve=0
> >>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
> >> 0:TimeU=1:80
> >> m above MSL:anl:NAve=0
> >>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
> >> =0:TimeU=1:140
> >> m above MSL:anl:NAve=0
> >>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
> >> =0:TimeU=1:200
> >> m above MSL:anl:NAve=0
> >>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
> >> =0:TimeU=1:300
> >> m above MSL:anl:NAve=0
> >>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
> >> =0:TimeU=1:400
> >> m above MSL:anl:NAve=0
> >>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
> >> =0:TimeU=1:500
> >> m above MSL:anl:NAve=0
> >>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
> >> =0:TimeU=1:600
> >> m above MSL:anl:NAve=0
> >>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
> >> =0:TimeU=1:700
> >> m above MSL:anl:NAve=0
> >>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
> >> =0:TimeU=1:800
> >> m above MSL:anl:NAve=0
> >>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
> >> =0:TimeU=1:900
> >> m above MSL:anl:NAve=0
> >>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
> >> 2=0:TimeU=1:1000
> >> m above MSL:anl:NAve=0
> >>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
> >> 2=0:TimeU=1:1200
> >> m above MSL:anl:NAve=0
> >>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
> >> 2=0:TimeU=1:1400
> >> m above MSL:anl:NAve=0
> >>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
> >> 2=0:TimeU=1:1600
> >> m above MSL:anl:NAve=0
> >>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
> >> 2=0:TimeU=1:1800
> >> m above MSL:anl:NAve=0
> >>
> >>
> >>
> >>
>
>
>
------------------------------------------------
Subject: vertical interpolation
From: John Halley Gotway
Time: Thu Jul 31 15:46:21 2014
Travis,
I tried running the gnuplot script you sent but I got errors. So I
just
plotted it in R quickly. I just ran over CCLCA using both vertical
and
pressure levels. The attached image has 3 lines - observations (red),
forecast on pressure levels (dashed black), and forecast on vertical
levels
(solid black).
Just so I'm crystal clear... is the question, why does the solid black
line
zig-zag back and forth?
Thanks,
John
On Thu, Jul 31, 2014 at 2:07 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Travis,
>
> I just posted a bugfix for that vertical interpolation problem...
>
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Sorry for the hassle, but thanks for making us aware of the issue!
>
> I'll look more into your original question now.
>
> Thanks,
> John
>
>
> On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>
>> Hi John,
>> The following commands will reproduce the plots. Run the
script in
>> the same directory as the mpr file. The scripts require bash,
perl, and
>> gnuplot.
>>
>> bash run_graph_aircraft_mpr.sh
>> bash plot_vert.sh
>>
>> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
>> > Travis,
>> >
>> > Sorry for the delay in getting back to you. Thanks for sending
your
>> data.
>> > I took a look in the MPR file you sent
>> > (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
>> > problem in the first matched pair line. The interpolated
forecast
>> value is
>> > -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
>> > forecast values like that:
>> >
>> > cat point_stat_680000L_20110106_200000V_mpr.txt | awk '{print
$29}'
>> |
>> > sort -nr
>> > ...
>> > FCST
>> > -3422.92840
>> > -4552.55954
>> > -4957.70470
>> > -9793.49776
>> > -9896.13442
>> >
>> > After some debugging, I see that the problem is in how we're
doing the
>> > vertical interpolation. We compute a forecast value for the
levels
>> above
>> > and below the observation, but fail to check for bad data prior
to doing
>> > the vertical interpolation. The problem is that one them is bad
data
>> since
>> > one of the MSL temperatures is below ground. The fix is to check
for
>> bad
>> > data prior to doing the vertical interpolation and skip this
>> observation.
>> > That fixes this problem and you'll see the debug level 3 output
from
>> > Point-Stat "Rejected: bad fcst value" rejection count increase
each time
>> > this happens.
>> >
>> > I'll work up a patch for METv4.1 and post it to the MET website.
>> >
>> > I also noticed a pretty bogus observation value for the station
named
>> SACCA
>> > on line 55 of that mpr.txt file:
>> > OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
>> > CLIMO
>> > SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
>> 999999.00000 NA
>> >
>> > There isn't any range checking of observation values in MET, but
I just
>> > thought I'd point it out to you.
>> >
>> > As for the actual reason you wrote, I'm not sure. What did you
use to
>> > create that image you sent? If it's some script that would be
easy for
>> me
>> > to run here, please pass it along. That might help me in
debugging this
>> > further.
>> >
>> > Thanks,
>> > John
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT <
>> met_help at ucar.edu>
>> > wrote:
>> >
>> >> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
>> >> Transaction: Ticket created by Wilson0028 at ucla.edu
>> >> Queue: met_help
>> >> Subject: vertical interpolation
>> >> Owner: Nobody
>> >> Requestors: Wilson0028 at ucla.edu
>> >> Status: new
>> >> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
>> >
>> >>
>> >>
>> >> Hi,
>> >> I recently had a conversation with John (pasted below)
about
>> >> vertical interpolation. He suggested that I use a larger
vertical
>> range
>> >> because my small range didn't have enough levels for
interpolation.
>> >> Since I am only interested in the mpr files I used the entire
range of
>> >> levels (z0-1500). Now when I get the results, the observations
look
>> >> fine but the forecasted fields look terrible (see attached
picture).
>> >> Any idea what is going on?
>> >>
>> >> Do note, I am using temperature on constant HEIGHT fields and
comparing
>> >> it to virtual temperature for this demonstration. Using
temperature of
>> >> constant PRESSURE fields does not have this problem (the
forecasted
>> >> field looks smooth)
>> >>
>> >> All files needed to reproduce this problem are in
>> >> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>> >>
>> >> Thanks,
>> >> Travis
>> >>
>> >>
>> >> ####################################3
>> >>
>> >> Travis,
>> >>
>> >> Let me start by telling you how Point-Stat does vertical
interpolation.
>> >> For a range of pressure levels (specified with a letter P, like
>> P250-350),
>> >> the vertical interpolation is done linear in the log of
pressure. For
>> a
>> >> range of any other level type (like Z250-350 for height), it's
done
>> >> linearly by height.
>> >>
>> >> I took a look at the data you sent and ran the same case for
which you
>> sent
>> >> me output. I'm reproducing the numbers you're getting
identically. To
>> >> narrow things down, I reran for just one range:
>> >> level = [ "12/P250-350", "12/Z250-350" ]
>> >>
>> >> Here I'm saying to verify virtual temperature between 250 and
350
>> millibars
>> >> (P250-350) and verify it between 250 and 350 meters above ground
>> >> (Z250-350). Running point_stat at verbosity level 2, I see the
>> following
>> >> output:
>> >> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
>> climatology
>> >> levels.
>> >> ...
>> >> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
>> climatology
>> >> levels.
>> >>
>> >> For the range P250-350, it found data for pressure levels 250,
300, and
>> >> 350. But for the range Z250-350, it only found data for a
single
>> level 300
>> >> meters above ground.
>> >>
>> >> When doing vertical interpolation on pressure levels, since we
found 3
>> >> forecast levels, there's always a pressure level above/below
each
>> >> observation. So the vertical interpolation can be done
smoothly.
>> >>
>> >> But when doing vertical interpolation on height levels, there's
only a
>> >> single level in that range. So all the observations are matched
to
>> that
>> >> single level.
>> >>
>> >> I think the problem here is a poor choice of levels for
verification.
>> >> Based on your settings, it looks like you want to verify using
>> observations
>> >> in bands of 100 meters. I'd suggest setting up the level for
the
>> forecast
>> >> and observation fields a little differently. You could try
this:
>> >>
>> >> fcst = {
>> >> wind_thresh = [ NA ];
>> >>
>> >> field = [
>> >> {
>> >> name = "VTMP";
>> >> level = [ "Z200-400" ];
>> >> cat_thresh = [];
>> >> }
>> >>
>> >> ];
>> >> };
>> >> obs = {
>> >>
>> >> field = [
>> >> {
>> >> name = "VTMP";
>> >> level = [ "Z250-350" ];
>> >> cat_thresh = [];
>> >> }
>> >>
>> >> ];
>> >> };
>> >>
>> >> This tells point_stat to extract levels 200, 300, and 400 m from
the
>> >> forecast file and use it for this verification task. But only
use
>> >> observations falling between 250 and 350 m. That will give
point_stat
>> >> forecast level data to use for the vertical interpolation
above/below
>> each
>> >> observation value. But it'll only use the obs falling in your
>> requested
>> >> range. And that should enable the vertical interpolation to be
done
>> more
>> >> smoothly.
>> >>
>> >> I do realize this is confusing. Hopefully that helps clarify.
>> >>
>> >> Thanks,
>> >> John
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
>> met_help at ucar.edu>
>> >> wrote:
>> >>
>> >> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
>> >>
>> >> Hi Randy,
>> >> I appreciate the help. I uploaded everything to
>> >> /incoming/irap/met_help/wilson_data so you can reproduce the
problem if
>> >> need be. Thanks!
>> >>
>> >> Travis Wilson
>> >> UCLA Atmospheric and Oceanic Sciences
>> >> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
>> >> Sent: Tuesday, June 17, 2014 10:02 AM
>> >> To:Wilson0028 at ucla.edu
>> >> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
>> height
>> >> fields
>> >>
>> >> Travis -
>> >>
>> >> I had a look at the code and also a few old met_help questions
in
>> order to
>> >> get a handle on this. As far as I can tell, interpolation
should be
>> >> happening. The only times when vertical interpolation doesn't
happen
>> is
>> >> when you're dealing with surface fields, but it looks from your
config
>> file
>> >> that that's not the case here.
>> >>
>> >> I'll talk this over with John when gets back from vacation next
week,
>> and
>> >> see if he has any insights on this.
>> >>
>> >> Randy
>> >>
>> >>
>> >> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<
>> met_help at ucar.edu>
>> >> wrote:
>> >>
>> >>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
>> >>> Transaction: Ticket created byWilson0028 at ucla.edu
>> >>> Queue: met_help
>> >>> Subject: interpolation using constant height fields
>> >>> Owner: Nobody
>> >>> Requestors:Wilson0028 at ucla.edu
>> >>> Status: new
>> >>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>> >>> Hi John,
>> >>> When I use temperature (on constant pressure fields
made by
>> >>> UPP) to verify the vertical profile, the foretasted field gets
>> >> interpolated to
>> >>
>> >> the observation height. Everything looks very smooth (see
>> >> constant_pressure_field.png).
>> >>
>> >> Now when I use temperature (on constant height fields
made by
>> >> UPP), my foretasted field does not get interpolated (see
>> >> constant_height_field.png).
>> >>
>> >> I am assuming this has something to do with the fact that the
fields
>> >> with constant height are in the same grib file that has fields
of
>> >> constant pressure (and the native coordinate in the UPP grib
file is
>> >> pressure, not sure how to make it height). my wgrib is below.
Any
>> >> idea on how to interpolate the forecast fields?
>> >>
>> >> Thanks,
>> >> Travis
>> >>
>> >> (note: I am using VTMP)
>> >>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
>> >> imeU=1:50
>> >> mb:anl:NAve=0
>> >>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
>> >> TimeU=1:100
>> >> mb:anl:NAve=0
>> >>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
>> >> :TimeU=1:150
>> >> mb:anl:NAve=0
>> >>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
>> >> :TimeU=1:200
>> >> mb:anl:NAve=0
>> >>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
>> >> :TimeU=1:250
>> >> mb:anl:NAve=0
>> >>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
>> >> 0:TimeU=1:300
>> >> mb:anl:NAve=0
>> >>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
>> >> 0:TimeU=1:350
>> >> mb:anl:NAve=0
>> >>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
>> >> 0:TimeU=1:400
>> >> mb:anl:NAve=0
>> >>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
>> >> 0:TimeU=1:450
>> >> mb:anl:NAve=0
>> >>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
>> >> 0:TimeU=1:500
>> >> mb:anl:NAve=0
>> >>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
>> >> 0:TimeU=1:550
>> >> mb:anl:NAve=0
>> >>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
>> >> 0:TimeU=1:600
>> >> mb:anl:NAve=0
>> >>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
>> >> 0:TimeU=1:650
>> >> mb:anl:NAve=0
>> >>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
>> >> 0:TimeU=1:700
>> >> mb:anl:NAve=0
>> >>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
>> >> 0:TimeU=1:750
>> >> mb:anl:NAve=0
>> >>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
>> >> 0:TimeU=1:775
>> >> mb:anl:NAve=0
>> >>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
>> >> 0:TimeU=1:800
>> >> mb:anl:NAve=0
>> >>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
>> >> 0:TimeU=1:825
>> >> mb:anl:NAve=0
>> >>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
>> >> 0:TimeU=1:850
>> >> mb:anl:NAve=0
>> >>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
>> >> 0:TimeU=1:875
>> >> mb:anl:NAve=0
>> >>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
>> >> 0:TimeU=1:900
>> >> mb:anl:NAve=0
>> >>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
>> >> 0:TimeU=1:910
>> >> mb:anl:NAve=0
>> >>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
>> >> 0:TimeU=1:920
>> >> mb:anl:NAve=0
>> >>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
>> >> 0:TimeU=1:930
>> >> mb:anl:NAve=0
>> >>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
>> >> 0:TimeU=1:940
>> >> mb:anl:NAve=0
>> >>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
>> >> 0:TimeU=1:950
>> >> mb:anl:NAve=0
>> >>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
>> >> =0:TimeU=1:960
>> >> mb:anl:NAve=0
>> >>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
>> >> =0:TimeU=1:970
>> >> mb:anl:NAve=0
>> >>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
>> >> =0:TimeU=1:980
>> >> mb:anl:NAve=0
>> >>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
>> >> =0:TimeU=1:990
>> >> mb:anl:NAve=0
>> >>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1000
>> >> mb:anl:NAve=0
>> >>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
>> >> 0:TimeU=1:30
>> >> m above MSL:anl:NAve=0
>> >>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
>> >> 0:TimeU=1:80
>> >> m above MSL:anl:NAve=0
>> >>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
>> >> =0:TimeU=1:140
>> >> m above MSL:anl:NAve=0
>> >>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
>> >> =0:TimeU=1:200
>> >> m above MSL:anl:NAve=0
>> >>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
>> >> =0:TimeU=1:300
>> >> m above MSL:anl:NAve=0
>> >>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
>> >> =0:TimeU=1:400
>> >> m above MSL:anl:NAve=0
>> >>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
>> >> =0:TimeU=1:500
>> >> m above MSL:anl:NAve=0
>> >>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
>> >> =0:TimeU=1:600
>> >> m above MSL:anl:NAve=0
>> >>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
>> >> =0:TimeU=1:700
>> >> m above MSL:anl:NAve=0
>> >>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
>> >> =0:TimeU=1:800
>> >> m above MSL:anl:NAve=0
>> >>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
>> >> =0:TimeU=1:900
>> >> m above MSL:anl:NAve=0
>> >>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1000
>> >> m above MSL:anl:NAve=0
>> >>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1200
>> >> m above MSL:anl:NAve=0
>> >>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1400
>> >> m above MSL:anl:NAve=0
>> >>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1600
>> >> m above MSL:anl:NAve=0
>> >>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
>> >> 2=0:TimeU=1:1800
>> >> m above MSL:anl:NAve=0
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #68461] vertical interpolation
From: Travis Wilson
Time: Thu Jul 31 15:56:26 2014
Yes, why does the soil black line zig-zag?
On 07/31/2014 02:46 PM, John Halley Gotway via RT wrote:
> Travis,
>
> I tried running the gnuplot script you sent but I got errors. So I
just
> plotted it in R quickly. I just ran over CCLCA using both vertical
and
> pressure levels. The attached image has 3 lines - observations
(red),
> forecast on pressure levels (dashed black), and forecast on vertical
levels
> (solid black).
>
> Just so I'm crystal clear... is the question, why does the solid
black line
> zig-zag back and forth?
>
> Thanks,
> John
>
>
> On Thu, Jul 31, 2014 at 2:07 PM, John Halley Gotway
<johnhg at ucar.edu> wrote:
>
>> Travis,
>>
>> I just posted a bugfix for that vertical interpolation problem...
>>
>>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>>
>> Sorry for the hassle, but thanks for making us aware of the issue!
>>
>> I'll look more into your original question now.
>>
>> Thanks,
>> John
>>
>>
>> On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>>
>>> Hi John,
>>> The following commands will reproduce the plots. Run the
script in
>>> the same directory as the mpr file. The scripts require bash,
perl, and
>>> gnuplot.
>>>
>>> bash run_graph_aircraft_mpr.sh
>>> bash plot_vert.sh
>>>
>>> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
>>>> Travis,
>>>>
>>>> Sorry for the delay in getting back to you. Thanks for sending
your
>>> data.
>>>> I took a look in the MPR file you sent
>>>> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
>>>> problem in the first matched pair line. The interpolated
forecast
>>> value is
>>>> -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
>>>> forecast values like that:
>>>>
>>>> cat point_stat_680000L_20110106_200000V_mpr.txt | awk
'{print $29}'
>>> |
>>>> sort -nr
>>>> ...
>>>> FCST
>>>> -3422.92840
>>>> -4552.55954
>>>> -4957.70470
>>>> -9793.49776
>>>> -9896.13442
>>>>
>>>> After some debugging, I see that the problem is in how we're
doing the
>>>> vertical interpolation. We compute a forecast value for the
levels
>>> above
>>>> and below the observation, but fail to check for bad data prior
to doing
>>>> the vertical interpolation. The problem is that one them is bad
data
>>> since
>>>> one of the MSL temperatures is below ground. The fix is to check
for
>>> bad
>>>> data prior to doing the vertical interpolation and skip this
>>> observation.
>>>> That fixes this problem and you'll see the debug level 3 output
from
>>>> Point-Stat "Rejected: bad fcst value" rejection count increase
each time
>>>> this happens.
>>>>
>>>> I'll work up a patch for METv4.1 and post it to the MET website.
>>>>
>>>> I also noticed a pretty bogus observation value for the station
named
>>> SACCA
>>>> on line 55 of that mpr.txt file:
>>>> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST
OBS
>>>> CLIMO
>>>> SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
>>> 999999.00000 NA
>>>> There isn't any range checking of observation values in MET, but
I just
>>>> thought I'd point it out to you.
>>>>
>>>> As for the actual reason you wrote, I'm not sure. What did you
use to
>>>> create that image you sent? If it's some script that would be
easy for
>>> me
>>>> to run here, please pass it along. That might help me in
debugging this
>>>> further.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT <
>>> met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
>>>>> Transaction: Ticket created by Wilson0028 at ucla.edu
>>>>> Queue: met_help
>>>>> Subject: vertical interpolation
>>>>> Owner: Nobody
>>>>> Requestors: Wilson0028 at ucla.edu
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
>>>>>
>>>>> Hi,
>>>>> I recently had a conversation with John (pasted below)
about
>>>>> vertical interpolation. He suggested that I use a larger
vertical
>>> range
>>>>> because my small range didn't have enough levels for
interpolation.
>>>>> Since I am only interested in the mpr files I used the entire
range of
>>>>> levels (z0-1500). Now when I get the results, the observations
look
>>>>> fine but the forecasted fields look terrible (see attached
picture).
>>>>> Any idea what is going on?
>>>>>
>>>>> Do note, I am using temperature on constant HEIGHT fields and
comparing
>>>>> it to virtual temperature for this demonstration. Using
temperature of
>>>>> constant PRESSURE fields does not have this problem (the
forecasted
>>>>> field looks smooth)
>>>>>
>>>>> All files needed to reproduce this problem are in
>>>>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>>>>>
>>>>> Thanks,
>>>>> Travis
>>>>>
>>>>>
>>>>> ####################################3
>>>>>
>>>>> Travis,
>>>>>
>>>>> Let me start by telling you how Point-Stat does vertical
interpolation.
>>>>> For a range of pressure levels (specified with a letter P, like
>>> P250-350),
>>>>> the vertical interpolation is done linear in the log of
pressure. For
>>> a
>>>>> range of any other level type (like Z250-350 for height), it's
done
>>>>> linearly by height.
>>>>>
>>>>> I took a look at the data you sent and ran the same case for
which you
>>> sent
>>>>> me output. I'm reproducing the numbers you're getting
identically. To
>>>>> narrow things down, I reran for just one range:
>>>>> level = [ "12/P250-350", "12/Z250-350" ]
>>>>>
>>>>> Here I'm saying to verify virtual temperature between 250 and
350
>>> millibars
>>>>> (P250-350) and verify it between 250 and 350 meters above ground
>>>>> (Z250-350). Running point_stat at verbosity level 2, I see the
>>> following
>>>>> output:
>>>>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
>>> climatology
>>>>> levels.
>>>>> ...
>>>>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
>>> climatology
>>>>> levels.
>>>>>
>>>>> For the range P250-350, it found data for pressure levels 250,
300, and
>>>>> 350. But for the range Z250-350, it only found data for a
single
>>> level 300
>>>>> meters above ground.
>>>>>
>>>>> When doing vertical interpolation on pressure levels, since we
found 3
>>>>> forecast levels, there's always a pressure level above/below
each
>>>>> observation. So the vertical interpolation can be done
smoothly.
>>>>>
>>>>> But when doing vertical interpolation on height levels, there's
only a
>>>>> single level in that range. So all the observations are matched
to
>>> that
>>>>> single level.
>>>>>
>>>>> I think the problem here is a poor choice of levels for
verification.
>>>>> Based on your settings, it looks like you want to verify using
>>> observations
>>>>> in bands of 100 meters. I'd suggest setting up the level for
the
>>> forecast
>>>>> and observation fields a little differently. You could try
this:
>>>>>
>>>>> fcst = {
>>>>> wind_thresh = [ NA ];
>>>>>
>>>>> field = [
>>>>> {
>>>>> name = "VTMP";
>>>>> level = [ "Z200-400" ];
>>>>> cat_thresh = [];
>>>>> }
>>>>>
>>>>> ];
>>>>> };
>>>>> obs = {
>>>>>
>>>>> field = [
>>>>> {
>>>>> name = "VTMP";
>>>>> level = [ "Z250-350" ];
>>>>> cat_thresh = [];
>>>>> }
>>>>>
>>>>> ];
>>>>> };
>>>>>
>>>>> This tells point_stat to extract levels 200, 300, and 400 m from
the
>>>>> forecast file and use it for this verification task. But only
use
>>>>> observations falling between 250 and 350 m. That will give
point_stat
>>>>> forecast level data to use for the vertical interpolation
above/below
>>> each
>>>>> observation value. But it'll only use the obs falling in your
>>> requested
>>>>> range. And that should enable the vertical interpolation to be
done
>>> more
>>>>> smoothly.
>>>>>
>>>>> I do realize this is confusing. Hopefully that helps clarify.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
>>> met_help at ucar.edu>
>>>>> wrote:
>>>>>
>>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713 >
>>>>>
>>>>> Hi Randy,
>>>>> I appreciate the help. I uploaded everything to
>>>>> /incoming/irap/met_help/wilson_data so you can reproduce the
problem if
>>>>> need be. Thanks!
>>>>>
>>>>> Travis Wilson
>>>>> UCLA Atmospheric and Oceanic Sciences
>>>>> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
>>>>> Sent: Tuesday, June 17, 2014 10:02 AM
>>>>> To:Wilson0028 at ucla.edu
>>>>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
>>> height
>>>>> fields
>>>>>
>>>>> Travis -
>>>>>
>>>>> I had a look at the code and also a few old met_help questions
in
>>> order to
>>>>> get a handle on this. As far as I can tell, interpolation
should be
>>>>> happening. The only times when vertical interpolation doesn't
happen
>>> is
>>>>> when you're dealing with surface fields, but it looks from your
config
>>> file
>>>>> that that's not the case here.
>>>>>
>>>>> I'll talk this over with John when gets back from vacation next
week,
>>> and
>>>>> see if he has any insights on this.
>>>>>
>>>>> Randy
>>>>>
>>>>>
>>>>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<
>>> met_help at ucar.edu>
>>>>> wrote:
>>>>>
>>>>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
>>>>>> Transaction: Ticket created byWilson0028 at ucla.edu
>>>>>> Queue: met_help
>>>>>> Subject: interpolation using constant height fields
>>>>>> Owner: Nobody
>>>>>> Requestors:Wilson0028 at ucla.edu
>>>>>> Status: new
>>>>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>>>>>> Hi John,
>>>>>> When I use temperature (on constant pressure fields
made by
>>>>>> UPP) to verify the vertical profile, the foretasted field gets
>>>>> interpolated to
>>>>>
>>>>> the observation height. Everything looks very smooth (see
>>>>> constant_pressure_field.png).
>>>>>
>>>>> Now when I use temperature (on constant height fields
made by
>>>>> UPP), my foretasted field does not get interpolated (see
>>>>> constant_height_field.png).
>>>>>
>>>>> I am assuming this has something to do with the fact that the
fields
>>>>> with constant height are in the same grib file that has fields
of
>>>>> constant pressure (and the native coordinate in the UPP grib
file is
>>>>> pressure, not sure how to make it height). my wgrib is below.
Any
>>>>> idea on how to interpolate the forecast fields?
>>>>>
>>>>> Thanks,
>>>>> Travis
>>>>>
>>>>> (note: I am using VTMP)
>>>>>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
>>>>> imeU=1:50
>>>>> mb:anl:NAve=0
>>>>>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
>>>>> TimeU=1:100
>>>>> mb:anl:NAve=0
>>>>>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
>>>>> :TimeU=1:150
>>>>> mb:anl:NAve=0
>>>>>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
>>>>> :TimeU=1:200
>>>>> mb:anl:NAve=0
>>>>>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
>>>>> :TimeU=1:250
>>>>> mb:anl:NAve=0
>>>>>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:300
>>>>> mb:anl:NAve=0
>>>>>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:350
>>>>> mb:anl:NAve=0
>>>>>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:400
>>>>> mb:anl:NAve=0
>>>>>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:450
>>>>> mb:anl:NAve=0
>>>>>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:500
>>>>> mb:anl:NAve=0
>>>>>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:550
>>>>> mb:anl:NAve=0
>>>>>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:600
>>>>> mb:anl:NAve=0
>>>>>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:650
>>>>> mb:anl:NAve=0
>>>>>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:700
>>>>> mb:anl:NAve=0
>>>>>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:750
>>>>> mb:anl:NAve=0
>>>>>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:775
>>>>> mb:anl:NAve=0
>>>>>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:800
>>>>> mb:anl:NAve=0
>>>>>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:825
>>>>> mb:anl:NAve=0
>>>>>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:850
>>>>> mb:anl:NAve=0
>>>>>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:875
>>>>> mb:anl:NAve=0
>>>>>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:900
>>>>> mb:anl:NAve=0
>>>>>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:910
>>>>> mb:anl:NAve=0
>>>>>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:920
>>>>> mb:anl:NAve=0
>>>>>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:930
>>>>> mb:anl:NAve=0
>>>>>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:940
>>>>> mb:anl:NAve=0
>>>>>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:950
>>>>> mb:anl:NAve=0
>>>>>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
>>>>> =0:TimeU=1:960
>>>>> mb:anl:NAve=0
>>>>>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
>>>>> =0:TimeU=1:970
>>>>> mb:anl:NAve=0
>>>>>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
>>>>> =0:TimeU=1:980
>>>>> mb:anl:NAve=0
>>>>>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
>>>>> =0:TimeU=1:990
>>>>> mb:anl:NAve=0
>>>>>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1000
>>>>> mb:anl:NAve=0
>>>>>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:30
>>>>> m above MSL:anl:NAve=0
>>>>>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
>>>>> 0:TimeU=1:80
>>>>> m above MSL:anl:NAve=0
>>>>>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
>>>>> =0:TimeU=1:140
>>>>> m above MSL:anl:NAve=0
>>>>>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
>>>>> =0:TimeU=1:200
>>>>> m above MSL:anl:NAve=0
>>>>>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
>>>>> =0:TimeU=1:300
>>>>> m above MSL:anl:NAve=0
>>>>>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
>>>>> =0:TimeU=1:400
>>>>> m above MSL:anl:NAve=0
>>>>>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
>>>>> =0:TimeU=1:500
>>>>> m above MSL:anl:NAve=0
>>>>>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
>>>>> =0:TimeU=1:600
>>>>> m above MSL:anl:NAve=0
>>>>>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
>>>>> =0:TimeU=1:700
>>>>> m above MSL:anl:NAve=0
>>>>>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
>>>>> =0:TimeU=1:800
>>>>> m above MSL:anl:NAve=0
>>>>>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
>>>>> =0:TimeU=1:900
>>>>> m above MSL:anl:NAve=0
>>>>>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1000
>>>>> m above MSL:anl:NAve=0
>>>>>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1200
>>>>> m above MSL:anl:NAve=0
>>>>>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1400
>>>>> m above MSL:anl:NAve=0
>>>>>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1600
>>>>> m above MSL:anl:NAve=0
>>>>>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
>>>>> 2=0:TimeU=1:1800
>>>>> m above MSL:anl:NAve=0
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
------------------------------------------------
Subject: vertical interpolation
From: John Halley Gotway
Time: Thu Jul 31 17:33:01 2014
Travis,
Wow, that was pretty difficult to track down!
You've uncovered a very simple but very serious but. When doing
vertical
interpolation linearly by height, the weights for the two values were
reversed. So a point 10% of the way between values 1 and 2, was
getting
10% of value 1 and 90% of value 2, when that should be reversed.
Observation heights close to one of the forecast level heights were
greatly
affected by this bug, while those close to the middle were not
affected
much. That led to the zigzag pattern in that plot.
I reran with a bugfix and redid the vertical level image. It shows
more
consistent behavior.
This one's a doozy, and I'm glad you looked closely enough at your
data to
uncover it!
Here's the link to the bugfix:
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
Thanks,
John
On Thu, Jul 31, 2014 at 3:56 PM, Travis Wilson via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>
> Yes, why does the soil black line zig-zag?
>
>
> On 07/31/2014 02:46 PM, John Halley Gotway via RT wrote:
> > Travis,
> >
> > I tried running the gnuplot script you sent but I got errors. So
I just
> > plotted it in R quickly. I just ran over CCLCA using both
vertical and
> > pressure levels. The attached image has 3 lines - observations
(red),
> > forecast on pressure levels (dashed black), and forecast on
vertical
> levels
> > (solid black).
> >
> > Just so I'm crystal clear... is the question, why does the solid
black
> line
> > zig-zag back and forth?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jul 31, 2014 at 2:07 PM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
> >
> >> Travis,
> >>
> >> I just posted a bugfix for that vertical interpolation problem...
> >>
> >>
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
> >>
> >> Sorry for the hassle, but thanks for making us aware of the
issue!
> >>
> >> I'll look more into your original question now.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT <
> met_help at ucar.edu>
> >> wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
> >>>
> >>> Hi John,
> >>> The following commands will reproduce the plots. Run the
script
> in
> >>> the same directory as the mpr file. The scripts require bash,
perl,
> and
> >>> gnuplot.
> >>>
> >>> bash run_graph_aircraft_mpr.sh
> >>> bash plot_vert.sh
> >>>
> >>> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
> >>>> Travis,
> >>>>
> >>>> Sorry for the delay in getting back to you. Thanks for sending
your
> >>> data.
> >>>> I took a look in the MPR file you sent
> >>>> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
> >>>> problem in the first matched pair line. The interpolated
forecast
> >>> value is
> >>>> -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
> >>>> forecast values like that:
> >>>>
> >>>> cat point_stat_680000L_20110106_200000V_mpr.txt | awk
'{print
> $29}'
> >>> |
> >>>> sort -nr
> >>>> ...
> >>>> FCST
> >>>> -3422.92840
> >>>> -4552.55954
> >>>> -4957.70470
> >>>> -9793.49776
> >>>> -9896.13442
> >>>>
> >>>> After some debugging, I see that the problem is in how we're
doing the
> >>>> vertical interpolation. We compute a forecast value for the
levels
> >>> above
> >>>> and below the observation, but fail to check for bad data prior
to
> doing
> >>>> the vertical interpolation. The problem is that one them is
bad data
> >>> since
> >>>> one of the MSL temperatures is below ground. The fix is to
check for
> >>> bad
> >>>> data prior to doing the vertical interpolation and skip this
> >>> observation.
> >>>> That fixes this problem and you'll see the debug level 3 output
from
> >>>> Point-Stat "Rejected: bad fcst value" rejection count increase
each
> time
> >>>> this happens.
> >>>>
> >>>> I'll work up a patch for METv4.1 and post it to the MET
website.
> >>>>
> >>>> I also noticed a pretty bogus observation value for the station
named
> >>> SACCA
> >>>> on line 55 of that mpr.txt file:
> >>>> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST
OBS
> >>>> CLIMO
> >>>> SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
> >>> 999999.00000 NA
> >>>> There isn't any range checking of observation values in MET,
but I
> just
> >>>> thought I'd point it out to you.
> >>>>
> >>>> As for the actual reason you wrote, I'm not sure. What did you
use to
> >>>> create that image you sent? If it's some script that would be
easy
> for
> >>> me
> >>>> to run here, please pass it along. That might help me in
debugging
> this
> >>>> further.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT <
> >>> met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
> >>>>> Transaction: Ticket created by Wilson0028 at ucla.edu
> >>>>> Queue: met_help
> >>>>> Subject: vertical interpolation
> >>>>> Owner: Nobody
> >>>>> Requestors: Wilson0028 at ucla.edu
> >>>>> Status: new
> >>>>> Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
> >>>>>
> >>>>> Hi,
> >>>>> I recently had a conversation with John (pasted below)
about
> >>>>> vertical interpolation. He suggested that I use a larger
vertical
> >>> range
> >>>>> because my small range didn't have enough levels for
interpolation.
> >>>>> Since I am only interested in the mpr files I used the entire
range
> of
> >>>>> levels (z0-1500). Now when I get the results, the
observations look
> >>>>> fine but the forecasted fields look terrible (see attached
picture).
> >>>>> Any idea what is going on?
> >>>>>
> >>>>> Do note, I am using temperature on constant HEIGHT fields and
> comparing
> >>>>> it to virtual temperature for this demonstration. Using
temperature
> of
> >>>>> constant PRESSURE fields does not have this problem (the
forecasted
> >>>>> field looks smooth)
> >>>>>
> >>>>> All files needed to reproduce this problem are in
> >>>>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
> >>>>>
> >>>>> Thanks,
> >>>>> Travis
> >>>>>
> >>>>>
> >>>>> ####################################3
> >>>>>
> >>>>> Travis,
> >>>>>
> >>>>> Let me start by telling you how Point-Stat does vertical
> interpolation.
> >>>>> For a range of pressure levels (specified with a letter P,
like
> >>> P250-350),
> >>>>> the vertical interpolation is done linear in the log of
pressure.
> For
> >>> a
> >>>>> range of any other level type (like Z250-350 for height), it's
done
> >>>>> linearly by height.
> >>>>>
> >>>>> I took a look at the data you sent and ran the same case for
which
> you
> >>> sent
> >>>>> me output. I'm reproducing the numbers you're getting
identically.
> To
> >>>>> narrow things down, I reran for just one range:
> >>>>> level = [ "12/P250-350", "12/Z250-350" ]
> >>>>>
> >>>>> Here I'm saying to verify virtual temperature between 250 and
350
> >>> millibars
> >>>>> (P250-350) and verify it between 250 and 350 meters above
ground
> >>>>> (Z250-350). Running point_stat at verbosity level 2, I see
the
> >>> following
> >>>>> output:
> >>>>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and 0
> >>> climatology
> >>>>> levels.
> >>>>> ...
> >>>>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and 0
> >>> climatology
> >>>>> levels.
> >>>>>
> >>>>> For the range P250-350, it found data for pressure levels 250,
300,
> and
> >>>>> 350. But for the range Z250-350, it only found data for a
single
> >>> level 300
> >>>>> meters above ground.
> >>>>>
> >>>>> When doing vertical interpolation on pressure levels, since we
found
> 3
> >>>>> forecast levels, there's always a pressure level above/below
each
> >>>>> observation. So the vertical interpolation can be done
smoothly.
> >>>>>
> >>>>> But when doing vertical interpolation on height levels,
there's only
> a
> >>>>> single level in that range. So all the observations are
matched to
> >>> that
> >>>>> single level.
> >>>>>
> >>>>> I think the problem here is a poor choice of levels for
verification.
> >>>>> Based on your settings, it looks like you want to verify using
> >>> observations
> >>>>> in bands of 100 meters. I'd suggest setting up the level for
the
> >>> forecast
> >>>>> and observation fields a little differently. You could try
this:
> >>>>>
> >>>>> fcst = {
> >>>>> wind_thresh = [ NA ];
> >>>>>
> >>>>> field = [
> >>>>> {
> >>>>> name = "VTMP";
> >>>>> level = [ "Z200-400" ];
> >>>>> cat_thresh = [];
> >>>>> }
> >>>>>
> >>>>> ];
> >>>>> };
> >>>>> obs = {
> >>>>>
> >>>>> field = [
> >>>>> {
> >>>>> name = "VTMP";
> >>>>> level = [ "Z250-350" ];
> >>>>> cat_thresh = [];
> >>>>> }
> >>>>>
> >>>>> ];
> >>>>> };
> >>>>>
> >>>>> This tells point_stat to extract levels 200, 300, and 400 m
from the
> >>>>> forecast file and use it for this verification task. But only
use
> >>>>> observations falling between 250 and 350 m. That will give
> point_stat
> >>>>> forecast level data to use for the vertical interpolation
above/below
> >>> each
> >>>>> observation value. But it'll only use the obs falling in your
> >>> requested
> >>>>> range. And that should enable the vertical interpolation to
be done
> >>> more
> >>>>> smoothly.
> >>>>>
> >>>>> I do realize this is confusing. Hopefully that helps clarify.
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
> >>> met_help at ucar.edu>
> >>>>> wrote:
> >>>>>
> >>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>
> >>>>>
> >>>>> Hi Randy,
> >>>>> I appreciate the help. I uploaded everything to
> >>>>> /incoming/irap/met_help/wilson_data so you can reproduce the
problem
> if
> >>>>> need be. Thanks!
> >>>>>
> >>>>> Travis Wilson
> >>>>> UCLA Atmospheric and Oceanic Sciences
> >>>>> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
> >>>>> Sent: Tuesday, June 17, 2014 10:02 AM
> >>>>> To:Wilson0028 at ucla.edu
> >>>>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
> >>> height
> >>>>> fields
> >>>>>
> >>>>> Travis -
> >>>>>
> >>>>> I had a look at the code and also a few old met_help questions
in
> >>> order to
> >>>>> get a handle on this. As far as I can tell, interpolation
should be
> >>>>> happening. The only times when vertical interpolation doesn't
happen
> >>> is
> >>>>> when you're dealing with surface fields, but it looks from
your
> config
> >>> file
> >>>>> that that's not the case here.
> >>>>>
> >>>>> I'll talk this over with John when gets back from vacation
next week,
> >>> and
> >>>>> see if he has any insights on this.
> >>>>>
> >>>>> Randy
> >>>>>
> >>>>>
> >>>>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<
> >>> met_help at ucar.edu>
> >>>>> wrote:
> >>>>>
> >>>>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
> >>>>>> Transaction: Ticket created byWilson0028 at ucla.edu
> >>>>>> Queue: met_help
> >>>>>> Subject: interpolation using constant height fields
> >>>>>> Owner: Nobody
> >>>>>> Requestors:Wilson0028 at ucla.edu
> >>>>>> Status: new
> >>>>>> Ticket <URL:
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
> >>>>>> Hi John,
> >>>>>> When I use temperature (on constant pressure
fields made
> by
> >>>>>> UPP) to verify the vertical profile, the foretasted field
gets
> >>>>> interpolated to
> >>>>>
> >>>>> the observation height. Everything looks very smooth (see
> >>>>> constant_pressure_field.png).
> >>>>>
> >>>>> Now when I use temperature (on constant height
fields
> made by
> >>>>> UPP), my foretasted field does not get interpolated (see
> >>>>> constant_height_field.png).
> >>>>>
> >>>>> I am assuming this has something to do with the fact that the
fields
> >>>>> with constant height are in the same grib file that has fields
of
> >>>>> constant pressure (and the native coordinate in the UPP grib
file is
> >>>>> pressure, not sure how to make it height). my wgrib is below.
Any
> >>>>> idea on how to interpolate the forecast fields?
> >>>>>
> >>>>> Thanks,
> >>>>> Travis
> >>>>>
> >>>>> (note: I am using VTMP)
> >>>>>
>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
> >>>>> imeU=1:50
> >>>>> mb:anl:NAve=0
> >>>>>
>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
> >>>>> TimeU=1:100
> >>>>> mb:anl:NAve=0
> >>>>>
>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
> >>>>> :TimeU=1:150
> >>>>> mb:anl:NAve=0
> >>>>>
>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
> >>>>> :TimeU=1:200
> >>>>> mb:anl:NAve=0
> >>>>>
>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
> >>>>> :TimeU=1:250
> >>>>> mb:anl:NAve=0
> >>>>>
>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:300
> >>>>> mb:anl:NAve=0
> >>>>>
>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:350
> >>>>> mb:anl:NAve=0
> >>>>>
>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:400
> >>>>> mb:anl:NAve=0
> >>>>>
>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:450
> >>>>> mb:anl:NAve=0
> >>>>>
>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:500
> >>>>> mb:anl:NAve=0
> >>>>>
>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:550
> >>>>> mb:anl:NAve=0
> >>>>>
>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:600
> >>>>> mb:anl:NAve=0
> >>>>>
>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:650
> >>>>> mb:anl:NAve=0
> >>>>>
>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:700
> >>>>> mb:anl:NAve=0
> >>>>>
>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:750
> >>>>> mb:anl:NAve=0
> >>>>>
>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:775
> >>>>> mb:anl:NAve=0
> >>>>>
>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:800
> >>>>> mb:anl:NAve=0
> >>>>>
>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:825
> >>>>> mb:anl:NAve=0
> >>>>>
>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:850
> >>>>> mb:anl:NAve=0
> >>>>>
>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:875
> >>>>> mb:anl:NAve=0
> >>>>>
>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:900
> >>>>> mb:anl:NAve=0
> >>>>>
>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:910
> >>>>> mb:anl:NAve=0
> >>>>>
>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:920
> >>>>> mb:anl:NAve=0
> >>>>>
>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:930
> >>>>> mb:anl:NAve=0
> >>>>>
>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:940
> >>>>> mb:anl:NAve=0
> >>>>>
>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:950
> >>>>> mb:anl:NAve=0
> >>>>>
>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:960
> >>>>> mb:anl:NAve=0
> >>>>>
>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:970
> >>>>> mb:anl:NAve=0
> >>>>>
>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:980
> >>>>> mb:anl:NAve=0
> >>>>>
>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:990
> >>>>> mb:anl:NAve=0
> >>>>>
>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1000
> >>>>> mb:anl:NAve=0
> >>>>>
>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:30
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
> >>>>> 0:TimeU=1:80
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:140
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:200
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:300
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:400
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:500
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:600
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:700
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:800
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
> >>>>> =0:TimeU=1:900
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1000
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1200
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1400
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1600
> >>>>> m above MSL:anl:NAve=0
> >>>>>
>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
> >>>>> 2=0:TimeU=1:1800
> >>>>> m above MSL:anl:NAve=0
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
>
>
>
------------------------------------------------
Subject: vertical interpolation
From: Travis Wilson
Time: Fri Aug 01 10:54:33 2014
Hi All,
John recently fixed a bug in MET regarding vertical interpolation (see
attached pictures). I still see a couple things that are wrong (that
is
not necessarily the DTC's problem) that we need to be aware of.
First, we are comparing forecasted temperature to virtual temperature.
To my understanding, acoustic profilers are based on the speed of
sound
which is dependent on the ratio of pressure to density, which changes
via temperature and moisture (i.e. virtual temperature)...but not
height. Since they can only measure virtual temperature it would make
sense that we add virtual temperature to UPP. My version of UPP does
VTMP but it would be nice to get this in the official release. If you
guys don't control this perhaps you could point me in the right
direction.
Secondly, and much more importantly, the native coordinate of
profilers
is height. "If the user selects pressure as the vertical coordinate,
the heights are converted to pressure using the U.S. Standard
Atmosphere
calculation." (http://madis.noaa.gov/map_variable_list.html). This
becomes a problem under conditions that differ from the "standard
atmosphere". Under high pressure you can get the sharp inversions, so
a
shift in the profile (which can be seen in the "fixed" image) can
cause
a big change in your verification. In this image, the observations (I
believe) actually shift (though it looks like the forecast does)
because
one time we are verifying forecasted temperature on pressure surfaces
to
virtual tempearture on pressure surface (converted with the standard
atmpshere) which is wrong. Then John plotted everything on the
profiler
pressure coordinate. The "Vertical Levels" compare the forecasted
temperature on height coordinates to the virtual temperature on height
coordinates (which is right). Then we ploted everything on the
profiler
pressure coordinate (which is wrong, but gives the illusion that the
forecasted temperature changed...which I really hope it didn't,
otherwise that is another bug :-) ). So in your verification, just be
aware of the native coordinate of the observation and how it is
converted to the coordinate you are using.
-Travis
On 07/31/2014 04:33 PM, John Halley Gotway via RT wrote:
> Travis,
>
> Wow, that was pretty difficult to track down!
>
> You've uncovered a very simple but very serious but. When doing
vertical
> interpolation linearly by height, the weights for the two values
were
> reversed. So a point 10% of the way between values 1 and 2, was
getting
> 10% of value 1 and 90% of value 2, when that should be reversed.
> Observation heights close to one of the forecast level heights were
greatly
> affected by this bug, while those close to the middle were not
affected
> much. That led to the zigzag pattern in that plot.
>
> I reran with a bugfix and redid the vertical level image. It shows
more
> consistent behavior.
>
> This one's a doozy, and I'm glad you looked closely enough at your
data to
> uncover it!
>
> Here's the link to the bugfix:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Thanks,
> John
>
>
>
> On Thu, Jul 31, 2014 at 3:56 PM, Travis Wilson via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>
>> Yes, why does the soil black line zig-zag?
>>
>>
>> On 07/31/2014 02:46 PM, John Halley Gotway via RT wrote:
>>> Travis,
>>>
>>> I tried running the gnuplot script you sent but I got errors. So
I just
>>> plotted it in R quickly. I just ran over CCLCA using both
vertical and
>>> pressure levels. The attached image has 3 lines - observations
(red),
>>> forecast on pressure levels (dashed black), and forecast on
vertical
>> levels
>>> (solid black).
>>>
>>> Just so I'm crystal clear... is the question, why does the solid
black
>> line
>>> zig-zag back and forth?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On Thu, Jul 31, 2014 at 2:07 PM, John Halley Gotway
<johnhg at ucar.edu>
>> wrote:
>>>> Travis,
>>>>
>>>> I just posted a bugfix for that vertical interpolation problem...
>>>>
>>>>
>>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>>>> Sorry for the hassle, but thanks for making us aware of the
issue!
>>>>
>>>> I'll look more into your original question now.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT <
>> met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>>>>>
>>>>> Hi John,
>>>>> The following commands will reproduce the plots. Run the
script
>> in
>>>>> the same directory as the mpr file. The scripts require bash,
perl,
>> and
>>>>> gnuplot.
>>>>>
>>>>> bash run_graph_aircraft_mpr.sh
>>>>> bash plot_vert.sh
>>>>>
>>>>> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
>>>>>> Travis,
>>>>>>
>>>>>> Sorry for the delay in getting back to you. Thanks for sending
your
>>>>> data.
>>>>>> I took a look in the MPR file you sent
>>>>>> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
immediate
>>>>>> problem in the first matched pair line. The interpolated
forecast
>>>>> value is
>>>>>> -4552.55954. Of the 246 MPR lines in that file, 5 of them have
bogus
>>>>>> forecast values like that:
>>>>>>
>>>>>> cat point_stat_680000L_20110106_200000V_mpr.txt | awk
'{print
>> $29}'
>>>>> |
>>>>>> sort -nr
>>>>>> ...
>>>>>> FCST
>>>>>> -3422.92840
>>>>>> -4552.55954
>>>>>> -4957.70470
>>>>>> -9793.49776
>>>>>> -9896.13442
>>>>>>
>>>>>> After some debugging, I see that the problem is in how we're
doing the
>>>>>> vertical interpolation. We compute a forecast value for the
levels
>>>>> above
>>>>>> and below the observation, but fail to check for bad data prior
to
>> doing
>>>>>> the vertical interpolation. The problem is that one them is
bad data
>>>>> since
>>>>>> one of the MSL temperatures is below ground. The fix is to
check for
>>>>> bad
>>>>>> data prior to doing the vertical interpolation and skip this
>>>>> observation.
>>>>>> That fixes this problem and you'll see the debug level 3 output
from
>>>>>> Point-Stat "Rejected: bad fcst value" rejection count increase
each
>> time
>>>>>> this happens.
>>>>>>
>>>>>> I'll work up a patch for METv4.1 and post it to the MET
website.
>>>>>>
>>>>>> I also noticed a pretty bogus observation value for the station
named
>>>>> SACCA
>>>>>> on line 55 of that mpr.txt file:
>>>>>> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST
OBS
>>>>>> CLIMO
>>>>>> SACCA 38.30000 -121.42000 998.74115 121.00000 274.06344
>>>>> 999999.00000 NA
>>>>>> There isn't any range checking of observation values in MET,
but I
>> just
>>>>>> thought I'd point it out to you.
>>>>>>
>>>>>> As for the actual reason you wrote, I'm not sure. What did you
use to
>>>>>> create that image you sent? If it's some script that would be
easy
>> for
>>>>> me
>>>>>> to run here, please pass it along. That might help me in
debugging
>> this
>>>>>> further.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT <
>>>>> met_help at ucar.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
>>>>>>> Transaction: Ticket created by Wilson0028 at ucla.edu
>>>>>>> Queue: met_help
>>>>>>> Subject: vertical interpolation
>>>>>>> Owner: Nobody
>>>>>>> Requestors: Wilson0028 at ucla.edu
>>>>>>> Status: new
>>>>>>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
>>>>>>> Hi,
>>>>>>> I recently had a conversation with John (pasted below)
about
>>>>>>> vertical interpolation. He suggested that I use a larger
vertical
>>>>> range
>>>>>>> because my small range didn't have enough levels for
interpolation.
>>>>>>> Since I am only interested in the mpr files I used the entire
range
>> of
>>>>>>> levels (z0-1500). Now when I get the results, the
observations look
>>>>>>> fine but the forecasted fields look terrible (see attached
picture).
>>>>>>> Any idea what is going on?
>>>>>>>
>>>>>>> Do note, I am using temperature on constant HEIGHT fields and
>> comparing
>>>>>>> it to virtual temperature for this demonstration. Using
temperature
>> of
>>>>>>> constant PRESSURE fields does not have this problem (the
forecasted
>>>>>>> field looks smooth)
>>>>>>>
>>>>>>> All files needed to reproduce this problem are in
>>>>>>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Travis
>>>>>>>
>>>>>>>
>>>>>>> ####################################3
>>>>>>>
>>>>>>> Travis,
>>>>>>>
>>>>>>> Let me start by telling you how Point-Stat does vertical
>> interpolation.
>>>>>>> For a range of pressure levels (specified with a letter P,
like
>>>>> P250-350),
>>>>>>> the vertical interpolation is done linear in the log of
pressure.
>> For
>>>>> a
>>>>>>> range of any other level type (like Z250-350 for height), it's
done
>>>>>>> linearly by height.
>>>>>>>
>>>>>>> I took a look at the data you sent and ran the same case for
which
>> you
>>>>> sent
>>>>>>> me output. I'm reproducing the numbers you're getting
identically.
>> To
>>>>>>> narrow things down, I reran for just one range:
>>>>>>> level = [ "12/P250-350", "12/Z250-350" ]
>>>>>>>
>>>>>>> Here I'm saying to verify virtual temperature between 250 and
350
>>>>> millibars
>>>>>>> (P250-350) and verify it between 250 and 350 meters above
ground
>>>>>>> (Z250-350). Running point_stat at verbosity level 2, I see
the
>>>>> following
>>>>>>> output:
>>>>>>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels and
0
>>>>> climatology
>>>>>>> levels.
>>>>>>> ...
>>>>>>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels and
0
>>>>> climatology
>>>>>>> levels.
>>>>>>>
>>>>>>> For the range P250-350, it found data for pressure levels 250,
300,
>> and
>>>>>>> 350. But for the range Z250-350, it only found data for a
single
>>>>> level 300
>>>>>>> meters above ground.
>>>>>>>
>>>>>>> When doing vertical interpolation on pressure levels, since we
found
>> 3
>>>>>>> forecast levels, there's always a pressure level above/below
each
>>>>>>> observation. So the vertical interpolation can be done
smoothly.
>>>>>>>
>>>>>>> But when doing vertical interpolation on height levels,
there's only
>> a
>>>>>>> single level in that range. So all the observations are
matched to
>>>>> that
>>>>>>> single level.
>>>>>>>
>>>>>>> I think the problem here is a poor choice of levels for
verification.
>>>>>>> Based on your settings, it looks like you want to verify using
>>>>> observations
>>>>>>> in bands of 100 meters. I'd suggest setting up the level for
the
>>>>> forecast
>>>>>>> and observation fields a little differently. You could try
this:
>>>>>>>
>>>>>>> fcst = {
>>>>>>> wind_thresh = [ NA ];
>>>>>>>
>>>>>>> field = [
>>>>>>> {
>>>>>>> name = "VTMP";
>>>>>>> level = [ "Z200-400" ];
>>>>>>> cat_thresh = [];
>>>>>>> }
>>>>>>>
>>>>>>> ];
>>>>>>> };
>>>>>>> obs = {
>>>>>>>
>>>>>>> field = [
>>>>>>> {
>>>>>>> name = "VTMP";
>>>>>>> level = [ "Z250-350" ];
>>>>>>> cat_thresh = [];
>>>>>>> }
>>>>>>>
>>>>>>> ];
>>>>>>> };
>>>>>>>
>>>>>>> This tells point_stat to extract levels 200, 300, and 400 m
from the
>>>>>>> forecast file and use it for this verification task. But only
use
>>>>>>> observations falling between 250 and 350 m. That will give
>> point_stat
>>>>>>> forecast level data to use for the vertical interpolation
above/below
>>>>> each
>>>>>>> observation value. But it'll only use the obs falling in your
>>>>> requested
>>>>>>> range. And that should enable the vertical interpolation to
be done
>>>>> more
>>>>>>> smoothly.
>>>>>>>
>>>>>>> I do realize this is confusing. Hopefully that helps clarify.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
>>>>> met_help at ucar.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>
>>>>>>>
>>>>>>> Hi Randy,
>>>>>>> I appreciate the help. I uploaded everything to
>>>>>>> /incoming/irap/met_help/wilson_data so you can reproduce the
problem
>> if
>>>>>>> need be. Thanks!
>>>>>>>
>>>>>>> Travis Wilson
>>>>>>> UCLA Atmospheric and Oceanic Sciences
>>>>>>> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
>>>>>>> Sent: Tuesday, June 17, 2014 10:02 AM
>>>>>>> To:Wilson0028 at ucla.edu
>>>>>>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
>>>>> height
>>>>>>> fields
>>>>>>>
>>>>>>> Travis -
>>>>>>>
>>>>>>> I had a look at the code and also a few old met_help questions
in
>>>>> order to
>>>>>>> get a handle on this. As far as I can tell, interpolation
should be
>>>>>>> happening. The only times when vertical interpolation doesn't
happen
>>>>> is
>>>>>>> when you're dealing with surface fields, but it looks from
your
>> config
>>>>> file
>>>>>>> that that's not the case here.
>>>>>>>
>>>>>>> I'll talk this over with John when gets back from vacation
next week,
>>>>> and
>>>>>>> see if he has any insights on this.
>>>>>>>
>>>>>>> Randy
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<
>>>>> met_help at ucar.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
>>>>>>>> Transaction: Ticket created byWilson0028 at ucla.edu
>>>>>>>> Queue: met_help
>>>>>>>> Subject: interpolation using constant height fields
>>>>>>>> Owner: Nobody
>>>>>>>> Requestors:Wilson0028 at ucla.edu
>>>>>>>> Status: new
>>>>>>>> Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>>>>>>>> Hi John,
>>>>>>>> When I use temperature (on constant pressure
fields made
>> by
>>>>>>>> UPP) to verify the vertical profile, the foretasted field
gets
>>>>>>> interpolated to
>>>>>>>
>>>>>>> the observation height. Everything looks very smooth (see
>>>>>>> constant_pressure_field.png).
>>>>>>>
>>>>>>> Now when I use temperature (on constant height
fields
>> made by
>>>>>>> UPP), my foretasted field does not get interpolated (see
>>>>>>> constant_height_field.png).
>>>>>>>
>>>>>>> I am assuming this has something to do with the fact that the
fields
>>>>>>> with constant height are in the same grib file that has fields
of
>>>>>>> constant pressure (and the native coordinate in the UPP grib
file is
>>>>>>> pressure, not sure how to make it height). my wgrib is below.
Any
>>>>>>> idea on how to interpolate the forecast fields?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Travis
>>>>>>>
>>>>>>> (note: I am using VTMP)
>>>>>>>
>>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
>>>>>>> imeU=1:50
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
>>>>>>> TimeU=1:100
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
>>>>>>> :TimeU=1:150
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
>>>>>>> :TimeU=1:200
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
>>>>>>> :TimeU=1:250
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:300
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:350
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:400
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:450
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:500
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:550
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:600
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:650
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:700
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:750
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:775
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:800
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:825
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:850
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:875
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:900
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:910
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:920
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:930
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:940
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:950
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:960
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:970
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:980
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:990
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1000
>>>>>>> mb:anl:NAve=0
>>>>>>>
>>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:30
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
>>>>>>> 0:TimeU=1:80
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:140
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:200
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:300
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:400
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:500
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:600
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:700
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:800
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
>>>>>>> =0:TimeU=1:900
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1000
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1200
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1400
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1600
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
>>>>>>> 2=0:TimeU=1:1800
>>>>>>> m above MSL:anl:NAve=0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
>>
------------------------------------------------
Subject: vertical interpolation
From: John Halley Gotway
Time: Fri Aug 01 11:45:28 2014
Travis,
Very good questions. Regarding the first one, the MET team does not
have
control over what goes in to UPP. UPP is supported by Kate Fossell
(formerly Kate Smith), who works upstairs in the MMM group. I believe
she
coordinates development of it with folks from NCEP. I'd suggest
forwarding
your message to wrfhelp and indicate in the subject that it's a UPP
question. That should get it routed to Kate. I'll shoot her an email
as
well to let her know you're writing.
Regarding the second question, I'll reassign this ticket to our MET
project
lead, Tara Jensen. I think she'll be better suited to address it.
FYI - I'll be out of town all next week, but will be returning on Aug
11th.
Thanks,
John
On Fri, Aug 1, 2014 at 10:54 AM, Travis Wilson via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
>
> Hi All,
>
> John recently fixed a bug in MET regarding vertical interpolation
(see
> attached pictures). I still see a couple things that are wrong
(that is
> not necessarily the DTC's problem) that we need to be aware of.
>
> First, we are comparing forecasted temperature to virtual
temperature.
> To my understanding, acoustic profilers are based on the speed of
sound
> which is dependent on the ratio of pressure to density, which
changes
> via temperature and moisture (i.e. virtual temperature)...but not
> height. Since they can only measure virtual temperature it would
make
> sense that we add virtual temperature to UPP. My version of UPP
does
> VTMP but it would be nice to get this in the official release. If
you
> guys don't control this perhaps you could point me in the right
direction.
>
> Secondly, and much more importantly, the native coordinate of
profilers
> is height. "If the user selects pressure as the vertical
coordinate,
> the heights are converted to pressure using the U.S. Standard
Atmosphere
> calculation." (http://madis.noaa.gov/map_variable_list.html). This
> becomes a problem under conditions that differ from the "standard
> atmosphere". Under high pressure you can get the sharp inversions,
so a
> shift in the profile (which can be seen in the "fixed" image) can
cause
> a big change in your verification. In this image, the observations
(I
> believe) actually shift (though it looks like the forecast does)
because
> one time we are verifying forecasted temperature on pressure
surfaces to
> virtual tempearture on pressure surface (converted with the standard
> atmpshere) which is wrong. Then John plotted everything on the
profiler
> pressure coordinate. The "Vertical Levels" compare the forecasted
> temperature on height coordinates to the virtual temperature on
height
> coordinates (which is right). Then we ploted everything on the
profiler
> pressure coordinate (which is wrong, but gives the illusion that the
> forecasted temperature changed...which I really hope it didn't,
> otherwise that is another bug :-) ). So in your verification, just
be
> aware of the native coordinate of the observation and how it is
> converted to the coordinate you are using.
>
> -Travis
>
> On 07/31/2014 04:33 PM, John Halley Gotway via RT wrote:
> > Travis,
> >
> > Wow, that was pretty difficult to track down!
> >
> > You've uncovered a very simple but very serious but. When doing
vertical
> > interpolation linearly by height, the weights for the two values
were
> > reversed. So a point 10% of the way between values 1 and 2, was
getting
> > 10% of value 1 and 90% of value 2, when that should be reversed.
> > Observation heights close to one of the forecast level heights
were
> greatly
> > affected by this bug, while those close to the middle were not
affected
> > much. That led to the zigzag pattern in that plot.
> >
> > I reran with a bugfix and redid the vertical level image. It
shows more
> > consistent behavior.
> >
> > This one's a doozy, and I'm glad you looked closely enough at your
data
> to
> > uncover it!
> >
> > Here's the link to the bugfix:
> >
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
> >
> > Thanks,
> > John
> >
> >
> >
> > On Thu, Jul 31, 2014 at 3:56 PM, Travis Wilson via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461 >
> >>
> >> Yes, why does the soil black line zig-zag?
> >>
> >>
> >> On 07/31/2014 02:46 PM, John Halley Gotway via RT wrote:
> >>> Travis,
> >>>
> >>> I tried running the gnuplot script you sent but I got errors.
So I
> just
> >>> plotted it in R quickly. I just ran over CCLCA using both
vertical and
> >>> pressure levels. The attached image has 3 lines - observations
(red),
> >>> forecast on pressure levels (dashed black), and forecast on
vertical
> >> levels
> >>> (solid black).
> >>>
> >>> Just so I'm crystal clear... is the question, why does the solid
black
> >> line
> >>> zig-zag back and forth?
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>>
> >>> On Thu, Jul 31, 2014 at 2:07 PM, John Halley Gotway
<johnhg at ucar.edu>
> >> wrote:
> >>>> Travis,
> >>>>
> >>>> I just posted a bugfix for that vertical interpolation
problem...
> >>>>
> >>>>
> >>
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
> >>>> Sorry for the hassle, but thanks for making us aware of the
issue!
> >>>>
> >>>> I'll look more into your original question now.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>> On Thu, Jul 31, 2014 at 1:00 PM, Travis Wilson via RT <
> >> met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
>
> >>>>>
> >>>>> Hi John,
> >>>>> The following commands will reproduce the plots. Run
the
> script
> >> in
> >>>>> the same directory as the mpr file. The scripts require bash,
perl,
> >> and
> >>>>> gnuplot.
> >>>>>
> >>>>> bash run_graph_aircraft_mpr.sh
> >>>>> bash plot_vert.sh
> >>>>>
> >>>>> On 07/31/2014 11:00 AM, John Halley Gotway via RT wrote:
> >>>>>> Travis,
> >>>>>>
> >>>>>> Sorry for the delay in getting back to you. Thanks for
sending your
> >>>>> data.
> >>>>>> I took a look in the MPR file you sent
> >>>>>> (point_stat_680000L_20110106_200000V_mpr.txt) and noticed an
> immediate
> >>>>>> problem in the first matched pair line. The interpolated
forecast
> >>>>> value is
> >>>>>> -4552.55954. Of the 246 MPR lines in that file, 5 of them
have
> bogus
> >>>>>> forecast values like that:
> >>>>>>
> >>>>>> cat point_stat_680000L_20110106_200000V_mpr.txt | awk
'{print
> >> $29}'
> >>>>> |
> >>>>>> sort -nr
> >>>>>> ...
> >>>>>> FCST
> >>>>>> -3422.92840
> >>>>>> -4552.55954
> >>>>>> -4957.70470
> >>>>>> -9793.49776
> >>>>>> -9896.13442
> >>>>>>
> >>>>>> After some debugging, I see that the problem is in how we're
doing
> the
> >>>>>> vertical interpolation. We compute a forecast value for the
levels
> >>>>> above
> >>>>>> and below the observation, but fail to check for bad data
prior to
> >> doing
> >>>>>> the vertical interpolation. The problem is that one them is
bad
> data
> >>>>> since
> >>>>>> one of the MSL temperatures is below ground. The fix is to
check
> for
> >>>>> bad
> >>>>>> data prior to doing the vertical interpolation and skip this
> >>>>> observation.
> >>>>>> That fixes this problem and you'll see the debug level 3
output from
> >>>>>> Point-Stat "Rejected: bad fcst value" rejection count
increase each
> >> time
> >>>>>> this happens.
> >>>>>>
> >>>>>> I'll work up a patch for METv4.1 and post it to the MET
website.
> >>>>>>
> >>>>>> I also noticed a pretty bogus observation value for the
station
> named
> >>>>> SACCA
> >>>>>> on line 55 of that mpr.txt file:
> >>>>>> OBS_SID OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST
OBS
> >>>>>> CLIMO
> >>>>>> SACCA 38.30000 -121.42000 998.74115 121.00000
274.06344
> >>>>> 999999.00000 NA
> >>>>>> There isn't any range checking of observation values in MET,
but I
> >> just
> >>>>>> thought I'd point it out to you.
> >>>>>>
> >>>>>> As for the actual reason you wrote, I'm not sure. What did
you use
> to
> >>>>>> create that image you sent? If it's some script that would
be easy
> >> for
> >>>>> me
> >>>>>> to run here, please pass it along. That might help me in
debugging
> >> this
> >>>>>> further.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jul 29, 2014 at 4:42 PM, Travis Wilson via RT <
> >>>>> met_help at ucar.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Tue Jul 29 16:42:07 2014: Request 68461 was acted upon.
> >>>>>>> Transaction: Ticket created by Wilson0028 at ucla.edu
> >>>>>>> Queue: met_help
> >>>>>>> Subject: vertical interpolation
> >>>>>>> Owner: Nobody
> >>>>>>> Requestors: Wilson0028 at ucla.edu
> >>>>>>> Status: new
> >>>>>>> Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68461
> >>>>>>> Hi,
> >>>>>>> I recently had a conversation with John (pasted
below)
> about
> >>>>>>> vertical interpolation. He suggested that I use a larger
vertical
> >>>>> range
> >>>>>>> because my small range didn't have enough levels for
interpolation.
> >>>>>>> Since I am only interested in the mpr files I used the
entire range
> >> of
> >>>>>>> levels (z0-1500). Now when I get the results, the
observations
> look
> >>>>>>> fine but the forecasted fields look terrible (see attached
> picture).
> >>>>>>> Any idea what is going on?
> >>>>>>>
> >>>>>>> Do note, I am using temperature on constant HEIGHT fields
and
> >> comparing
> >>>>>>> it to virtual temperature for this demonstration. Using
> temperature
> >> of
> >>>>>>> constant PRESSURE fields does not have this problem (the
forecasted
> >>>>>>> field looks smooth)
> >>>>>>>
> >>>>>>> All files needed to reproduce this problem are in
> >>>>>>> ftp.rap.ucar.edu*//*:/incoming/irap/met_help/wilson_data
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Travis
> >>>>>>>
> >>>>>>>
> >>>>>>> ####################################3
> >>>>>>>
> >>>>>>> Travis,
> >>>>>>>
> >>>>>>> Let me start by telling you how Point-Stat does vertical
> >> interpolation.
> >>>>>>> For a range of pressure levels (specified with a letter P,
like
> >>>>> P250-350),
> >>>>>>> the vertical interpolation is done linear in the log of
pressure.
> >> For
> >>>>> a
> >>>>>>> range of any other level type (like Z250-350 for height),
it's done
> >>>>>>> linearly by height.
> >>>>>>>
> >>>>>>> I took a look at the data you sent and ran the same case for
which
> >> you
> >>>>> sent
> >>>>>>> me output. I'm reproducing the numbers you're getting
identically.
> >> To
> >>>>>>> narrow things down, I reran for just one range:
> >>>>>>> level = [ "12/P250-350", "12/Z250-350" ]
> >>>>>>>
> >>>>>>> Here I'm saying to verify virtual temperature between 250
and 350
> >>>>> millibars
> >>>>>>> (P250-350) and verify it between 250 and 350 meters above
ground
> >>>>>>> (Z250-350). Running point_stat at verbosity level 2, I see
the
> >>>>> following
> >>>>>>> output:
> >>>>>>> DEBUG 2: For VTMP/P350-250 found 3 forecast levels
and 0
> >>>>> climatology
> >>>>>>> levels.
> >>>>>>> ...
> >>>>>>> DEBUG 2: For VTMP/Z350-250 found 1 forecast levels
and 0
> >>>>> climatology
> >>>>>>> levels.
> >>>>>>>
> >>>>>>> For the range P250-350, it found data for pressure levels
250, 300,
> >> and
> >>>>>>> 350. But for the range Z250-350, it only found data for a
single
> >>>>> level 300
> >>>>>>> meters above ground.
> >>>>>>>
> >>>>>>> When doing vertical interpolation on pressure levels, since
we
> found
> >> 3
> >>>>>>> forecast levels, there's always a pressure level above/below
each
> >>>>>>> observation. So the vertical interpolation can be done
smoothly.
> >>>>>>>
> >>>>>>> But when doing vertical interpolation on height levels,
there's
> only
> >> a
> >>>>>>> single level in that range. So all the observations are
matched to
> >>>>> that
> >>>>>>> single level.
> >>>>>>>
> >>>>>>> I think the problem here is a poor choice of levels for
> verification.
> >>>>>>> Based on your settings, it looks like you want to verify
using
> >>>>> observations
> >>>>>>> in bands of 100 meters. I'd suggest setting up the level
for the
> >>>>> forecast
> >>>>>>> and observation fields a little differently. You could try
this:
> >>>>>>>
> >>>>>>> fcst = {
> >>>>>>> wind_thresh = [ NA ];
> >>>>>>>
> >>>>>>> field = [
> >>>>>>> {
> >>>>>>> name = "VTMP";
> >>>>>>> level = [ "Z200-400" ];
> >>>>>>> cat_thresh = [];
> >>>>>>> }
> >>>>>>>
> >>>>>>> ];
> >>>>>>> };
> >>>>>>> obs = {
> >>>>>>>
> >>>>>>> field = [
> >>>>>>> {
> >>>>>>> name = "VTMP";
> >>>>>>> level = [ "Z250-350" ];
> >>>>>>> cat_thresh = [];
> >>>>>>> }
> >>>>>>>
> >>>>>>> ];
> >>>>>>> };
> >>>>>>>
> >>>>>>> This tells point_stat to extract levels 200, 300, and 400 m
from
> the
> >>>>>>> forecast file and use it for this verification task. But
only use
> >>>>>>> observations falling between 250 and 350 m. That will give
> >> point_stat
> >>>>>>> forecast level data to use for the vertical interpolation
> above/below
> >>>>> each
> >>>>>>> observation value. But it'll only use the obs falling in
your
> >>>>> requested
> >>>>>>> range. And that should enable the vertical interpolation to
be
> done
> >>>>> more
> >>>>>>> smoothly.
> >>>>>>>
> >>>>>>> I do realize this is confusing. Hopefully that helps
clarify.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jun 17, 2014 at 11:35 AM, Travis Wilson via RT<
> >>>>> met_help at ucar.edu>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
>
> >>>>>>>
> >>>>>>> Hi Randy,
> >>>>>>> I appreciate the help. I uploaded everything to
> >>>>>>> /incoming/irap/met_help/wilson_data so you can reproduce the
> problem
> >> if
> >>>>>>> need be. Thanks!
> >>>>>>>
> >>>>>>> Travis Wilson
> >>>>>>> UCLA Atmospheric and Oceanic Sciences
> >>>>>>> model
viewer:http://web.atmos.ucla.edu/~wilson28/pages/viewer.html
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Randy Bullock via RT [mailto:met_help at ucar.edu]
> >>>>>>> Sent: Tuesday, June 17, 2014 10:02 AM
> >>>>>>> To:Wilson0028 at ucla.edu
> >>>>>>> Subject: Re: [rt.rap.ucar.edu #67713] interpolation using
constant
> >>>>> height
> >>>>>>> fields
> >>>>>>>
> >>>>>>> Travis -
> >>>>>>>
> >>>>>>> I had a look at the code and also a few old met_help
questions in
> >>>>> order to
> >>>>>>> get a handle on this. As far as I can tell, interpolation
should
> be
> >>>>>>> happening. The only times when vertical interpolation
doesn't
> happen
> >>>>> is
> >>>>>>> when you're dealing with surface fields, but it looks from
your
> >> config
> >>>>> file
> >>>>>>> that that's not the case here.
> >>>>>>>
> >>>>>>> I'll talk this over with John when gets back from vacation
next
> week,
> >>>>> and
> >>>>>>> see if he has any insights on this.
> >>>>>>>
> >>>>>>> Randy
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jun 16, 2014 at 8:07 PM, Travis Wilson via RT<
> >>>>> met_help at ucar.edu>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Mon Jun 16 20:07:20 2014: Request 67713 was acted upon.
> >>>>>>>> Transaction: Ticket created byWilson0028 at ucla.edu
> >>>>>>>> Queue: met_help
> >>>>>>>> Subject: interpolation using constant height
fields
> >>>>>>>> Owner: Nobody
> >>>>>>>> Requestors:Wilson0028 at ucla.edu
> >>>>>>>> Status: new
> >>>>>>>> Ticket <URL:
> >>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67713
> >>>>>>>> Hi John,
> >>>>>>>> When I use temperature (on constant pressure
fields
> made
> >> by
> >>>>>>>> UPP) to verify the vertical profile, the foretasted field
gets
> >>>>>>> interpolated to
> >>>>>>>
> >>>>>>> the observation height. Everything looks very smooth (see
> >>>>>>> constant_pressure_field.png).
> >>>>>>>
> >>>>>>> Now when I use temperature (on constant height
fields
> >> made by
> >>>>>>> UPP), my foretasted field does not get interpolated (see
> >>>>>>> constant_height_field.png).
> >>>>>>>
> >>>>>>> I am assuming this has something to do with the fact that
the
> fields
> >>>>>>> with constant height are in the same grib file that has
fields of
> >>>>>>> constant pressure (and the native coordinate in the UPP grib
file
> is
> >>>>>>> pressure, not sure how to make it height). my wgrib is
below. Any
> >>>>>>> idea on how to interpolate the forecast fields?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Travis
> >>>>>>>
> >>>>>>> (note: I am using VTMP)
> >>>>>>>
> >>
30:569006:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=50:TR=0:P1=0:P2=0:T
> >>>>>>> imeU=1:50
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
46:853000:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=100:TR=0:P1=0:P2=0:
> >>>>>>> TimeU=1:100
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
61:1130366:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=150:TR=0:P1=0:P2=0
> >>>>>>> :TimeU=1:150
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
76:1427466:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=200:TR=0:P1=0:P2=0
> >>>>>>> :TimeU=1:200
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
91:1737568:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=250:TR=0:P1=0:P2=0
> >>>>>>> :TimeU=1:250
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
106:2041070:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=300:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:300
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
121:2357640:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=350:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:350
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
136:2667676:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=400:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:400
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
151:2975534:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=450:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:450
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
166:3276924:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=500:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:500
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
181:3573958:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=550:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:550
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
196:3868814:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=600:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:600
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
211:4165848:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=650:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:650
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
226:4465060:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=700:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:700
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
241:4903598:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=750:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:750
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
256:5344314:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=775:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:775
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
271:5778496:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=800:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:800
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
286:6210500:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=825:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:825
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
301:6642504:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=850:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:850
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
316:7074508:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=875:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:875
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
331:7506512:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=900:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:900
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
346:7945050:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=910:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:910
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
361:8379232:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=920:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:920
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
376:8813414:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=930:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:930
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
391:9247596:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=940:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:940
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
406:9686134:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=950:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:950
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
421:10126850:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=960:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:960
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
436:10565388:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=970:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:970
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
451:11003926:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=980:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:980
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
466:11444642:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=990:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:990
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
480:11852594:d=11010400:VTMP:kpds5=12:kpds6=100:kpds7=1000:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1000
> >>>>>>> mb:anl:NAve=0
> >>>>>>>
> >>
578:13222406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=30:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:30
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
579:13240112:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=80:TR=0:P1=0:P2=
> >>>>>>> 0:TimeU=1:80
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
580:13258406:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=140:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:140
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
581:13277194:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=200:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:200
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
582:13296424:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=300:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:300
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
583:13316380:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=400:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:400
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
584:13336962:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=500:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:500
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
585:13358144:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=600:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:600
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
586:13380028:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=700:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:700
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
587:13402522:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=800:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:800
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
588:13425618:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=900:TR=0:P1=0:P2
> >>>>>>> =0:TimeU=1:900
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
589:13449322:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1000:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1000
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
590:13473584:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1200:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1200
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
591:13498886:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1400:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1400
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
592:13526228:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1600:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1600
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>
593:13556146:d=11010400:VTMP:kpds5=12:kpds6=103:kpds7=1800:TR=0:P1=0:P
> >>>>>>> 2=0:TimeU=1:1800
> >>>>>>> m above MSL:anl:NAve=0
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>
> >>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list