[Met_help] [rt.rap.ucar.edu #49125] History for questions about point_stat for upper-air
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Tue Aug 23 09:33:07 MDT 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello Met Help,
I am testing out upper-air verification using point_stat, and I've noticed a couple "problems" with the program.
First of all, I have set up the following fcst and obs fields in the config file:
fcst_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU", "UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
obs_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU", "UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
In each case, I substitute in a lower (LLL) and upper (UUU) range of pressure levels based on a script I have devised.
So here are the "problems" I encountered:
1. In one of the model runs, the SPFH is output in the GRIB file, but not the DPT. As a result, point_stat quits when it tries to process DPT when not available. Is there a way to have point_stat continue to process the rest of the variables in the fcst/obs fields without quitting when it does not find a variable?
2. In the same vain, can point_stat compute DPT from the SPFH (or the other way around) in the instance that DPT or SPFH is available, but the other is not?
Thanks for the help!
Jonathan
--------------------------------------------------------------------------------------------------
Jonathan Case, ENSCO Inc.
NASA Short-term Prediction Research and Transition Center (aka SPoRT Center)
320 Sparkman Drive, Room 3062
Huntsville, AL 35805
Voice: 256.961.7504
Fax: 256.961.7788
Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
--------------------------------------------------------------------------------------------------
"Whether the weather is cold, or whether the weather is hot, we'll weather
the weather whether we like it or not!"
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #49125] questions about point_stat for upper-air
From: John Halley Gotway
Time: Mon Aug 22 16:14:27 2011
Jon,
Regarding your first question, I played around with the code for
several minutes and was able to produce the desired functionality - to
print a warning rather than error out. However, it's a bit
messy and required changing 4 source files.
This problem could also be overcome through scripting. In case you
aren't aware of it, you can actually use environment variables in the
MET config files. If I were in your position, I'd probably
loop through the fields I want to verify, use wgrib to see if it's
present in my grib file, and store a list of fields and thresholds to
be used in an environment variable. Then I'd just refer to
those environment variables in the Point-Stat config files.
However, from a user-support perspective, we want to make MET as easy
to use as possible. If you think this sort of behavior would make it
a lot easier, we could probably add it. But first, please
let me know what version/date of patches you're currently using. I
could send you the 4 updated source code files you need and have you
test out the functionality.
The second issue is not something currently on our radar. We
generally see the derivation of fields as a model post-processing
issue and not a verification one. We did add support in MET for
deriving wind speed from U and V, but only because the WRF
PostProcessor (or now Unified PostProcessor) does not provide an
option for deriving it. However WPP and UPP do provide the ability to
derive dewpoint and specific humidity.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 08/22/2011 03:24 PM, RAL HelpDesk {for Case, Jonathan[ENSCO INC]}
wrote:
>
> Mon Aug 22 15:24:18 2011: Request 49125 was acted upon.
> Transaction: Ticket created by jonathan.case-1 at nasa.gov
> Queue: met_help
> Subject: questions about point_stat for upper-air
> Owner: Nobody
> Requestors: jonathan.case-1 at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=49125 >
>
>
> Hello Met Help,
>
> I am testing out upper-air verification using point_stat, and I've
noticed a couple "problems" with the program.
>
> First of all, I have set up the following fcst and obs fields in the
config file:
> fcst_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU",
"UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
> obs_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU",
"UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
>
> In each case, I substitute in a lower (LLL) and upper (UUU) range of
pressure levels based on a script I have devised.
>
> So here are the "problems" I encountered:
>
> 1. In one of the model runs, the SPFH is output in the GRIB
file, but not the DPT. As a result, point_stat quits when it tries to
process DPT when not available. Is there a way to have point_stat
continue to process the rest of the variables in the fcst/obs fields
without quitting when it does not find a variable?
>
> 2. In the same vain, can point_stat compute DPT from the SPFH
(or the other way around) in the instance that DPT or SPFH is
available, but the other is not?
>
> Thanks for the help!
> Jonathan
>
>
--------------------------------------------------------------------------------------------------
> Jonathan Case, ENSCO Inc.
> NASA Short-term Prediction Research and Transition Center (aka SPoRT
Center)
> 320 Sparkman Drive, Room 3062
> Huntsville, AL 35805
> Voice: 256.961.7504
> Fax: 256.961.7788
> Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
>
--------------------------------------------------------------------------------------------------
>
> "Whether the weather is cold, or whether the weather is hot, we'll
weather
> the weather whether we like it or not!"
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #49125] questions about point_stat for upper-air
From: Case, Jonathan[ENSCO INC]
Time: Tue Aug 23 09:02:14 2011
Hi John,
Thanks for the timely reply (as always!).
I agree that
some more sophisticated scripting can take care of a missing variable
issue.
I'll look into that solution.
As for the derivation of
one variable from another -- I still think this would be an important
addition to MET.
In our example, we have CONUS 4-km WRF output
grids, which tend to be very large if including "redundant" variables
at multiple pressure levels. Since dewpoint, RH, MIXR, SPFH are all
inter-changeable to some degree of complexity, it would be most
helpful to be able to internally compute one from another (such as
what GEMPAK currently does).
However, I understand that this would
be a significant effort to make this generic. Consider this my
request for this capability.
Jonathan
-----Original Message-----
From: RAL HelpDesk {for John Halley Gotway} [mailto:met_help at ucar.edu]
Sent: Monday, August 22, 2011 5:14 PM
To: Case, Jonathan (MSFC-
VP61)[ENSCO INC]
Subject: Re: [rt.rap.ucar.edu #49125] questions
about point_stat for upper-air
Jon,
Regarding your first
question, I played around with the code for several minutes and was
able to produce the desired functionality - to print a warning rather
than error out. However, it's a bit
messy and required changing 4
source files.
This problem could also be overcome through
scripting. In case you aren't aware of it, you can actually use
environment variables in the MET config files. If I were in your
position, I'd probably
loop through the fields I want to verify, use
wgrib to see if it's present in my grib file, and store a list of
fields and thresholds to be used in an environment variable. Then I'd
just refer to
those environment variables in the Point-Stat config
files.
However, from a user-support perspective, we want to make
MET as easy to use as possible. If you think this sort of behavior
would make it a lot easier, we could probably add it. But first,
please
let me know what version/date of patches you're currently
using. I could send you the 4 updated source code files you need and
have you test out the functionality.
The second issue is not
something currently on our radar. We generally see the derivation of
fields as a model post-processing issue and not a verification one.
We did add support in MET for
deriving wind speed from U and V, but
only because the WRF PostProcessor (or now Unified PostProcessor) does
not provide an option for deriving it. However WPP and UPP do provide
the ability to
derive dewpoint and specific humidity.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 08/22/2011 03:24 PM, RAL
HelpDesk {for Case, Jonathan[ENSCO INC]} wrote:
>
> Mon Aug 22
15:24:18 2011: Request 49125 was acted upon.
> Transaction: Ticket
created by jonathan.case-1 at nasa.gov
> Queue: met_help
>
Subject: questions about point_stat for upper-air
> Owner:
Nobody
> Requestors: jonathan.case-1 at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=49125 >
>
>
>
Hello Met Help,
>
> I am testing out upper-air verification using
point_stat, and I've noticed a couple "problems" with the program.
>
> First of all, I have set up the following fcst and obs fields in the
config file:
> fcst_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU",
"SPFH/PLLL-UUU", "UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
> obs_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU",
"UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
>
> In each
case, I substitute in a lower (LLL) and upper (UUU) range of pressure
levels based on a script I have devised.
>
> So here are the
"problems" I encountered:
>
> 1. In one of the model runs,
the SPFH is output in the GRIB file, but not the DPT. As a result,
point_stat quits when it tries to process DPT when not available. Is
there a way to have point_stat continue to process the rest of the
variables in the fcst/obs fields without quitting when it does not
find a variable?
>
> 2. In the same vain, can point_stat
compute DPT from the SPFH (or the other way around) in the instance
that DPT or SPFH is available, but the other is not?
>
> Thanks for
the help!
> Jonathan
>
>
--------------------------------------------------------------------------------------------------
> Jonathan Case, ENSCO Inc.
> NASA Short-term Prediction Research and
Transition Center (aka SPoRT Center)
> 320 Sparkman Drive, Room 3062
> Huntsville, AL 35805
> Voice: 256.961.7504
> Fax: 256.961.7788
>
Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
>
--------------------------------------------------------------------------------------------------
>
> "Whether the weather is cold, or whether the weather is hot,
we'll weather
> the weather whether we like it or not!"
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #49125] questions about point_stat for upper-air
From: John Halley Gotway
Time: Tue Aug 23 09:32:30 2011
Jon,
Thanks for the feedback. I've forwarded your suggestion around to the
development team, but frankly, with what we've already got on our
plate for the next release, I'm doubtful we'd be able to add
anything. Of course, MET is open source, and you're welcome to make
any changes to the code you'd like.
Sorry we can't be of more help at this point.
I'll go ahead and resolve this ticket, but please let us know if more
questions or issues arise.
Thanks,
John
On 08/23/2011 09:02 AM, RAL HelpDesk {for Case, Jonathan[ENSCO INC]}
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=49125 >
>
> Hi John,
>
> Thanks for the timely reply (as always!).
> I agree that some more sophisticated scripting can take care of a
missing variable issue.
> I'll look into that solution.
>
> As for the derivation of one variable from another -- I still think
this would be an important addition to MET.
> In our example, we have CONUS 4-km WRF output grids, which tend to
be very large if including "redundant" variables at multiple pressure
levels. Since dewpoint, RH, MIXR, SPFH are all inter-changeable to
some degree of complexity, it would be most helpful to be able to
internally compute one from another (such as what GEMPAK currently
does).
>
> However, I understand that this would be a significant effort to
make this generic. Consider this my request for this capability.
>
> Jonathan
>
> -----Original Message-----
> From: RAL HelpDesk {for John Halley Gotway}
[mailto:met_help at ucar.edu]
> Sent: Monday, August 22, 2011 5:14 PM
> To: Case, Jonathan (MSFC-VP61)[ENSCO INC]
> Subject: Re: [rt.rap.ucar.edu #49125] questions about point_stat for
upper-air
>
> Jon,
>
> Regarding your first question, I played around with the code for
several minutes and was able to produce the desired functionality - to
print a warning rather than error out. However, it's a bit
> messy and required changing 4 source files.
>
> This problem could also be overcome through scripting. In case you
aren't aware of it, you can actually use environment variables in the
MET config files. If I were in your position, I'd probably
> loop through the fields I want to verify, use wgrib to see if it's
present in my grib file, and store a list of fields and thresholds to
be used in an environment variable. Then I'd just refer to
> those environment variables in the Point-Stat config files.
>
> However, from a user-support perspective, we want to make MET as
easy to use as possible. If you think this sort of behavior would
make it a lot easier, we could probably add it. But first, please
> let me know what version/date of patches you're currently using. I
could send you the 4 updated source code files you need and have you
test out the functionality.
>
> The second issue is not something currently on our radar. We
generally see the derivation of fields as a model post-processing
issue and not a verification one. We did add support in MET for
> deriving wind speed from U and V, but only because the WRF
PostProcessor (or now Unified PostProcessor) does not provide an
option for deriving it. However WPP and UPP do provide the ability to
> derive dewpoint and specific humidity.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
> On 08/22/2011 03:24 PM, RAL HelpDesk {for Case, Jonathan[ENSCO INC]}
wrote:
>>
>> Mon Aug 22 15:24:18 2011: Request 49125 was acted upon.
>> Transaction: Ticket created by jonathan.case-1 at nasa.gov
>> Queue: met_help
>> Subject: questions about point_stat for upper-air
>> Owner: Nobody
>> Requestors: jonathan.case-1 at nasa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=49125 >
>>
>>
>> Hello Met Help,
>>
>> I am testing out upper-air verification using point_stat, and I've
noticed a couple "problems" with the program.
>>
>> First of all, I have set up the following fcst and obs fields in
the config file:
>> fcst_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU",
"UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
>> obs_field[] = [ "TMP/PLLL-UUU", "DPT/PLLL-UUU", "SPFH/PLLL-UUU",
"UGRD/PLLL-UUU", "VGRD/PLLL-UUU", "WIND/PLLL-UUU" ];
>>
>> In each case, I substitute in a lower (LLL) and upper (UUU) range
of pressure levels based on a script I have devised.
>>
>> So here are the "problems" I encountered:
>>
>> 1. In one of the model runs, the SPFH is output in the GRIB
file, but not the DPT. As a result, point_stat quits when it tries to
process DPT when not available. Is there a way to have point_stat
continue to process the rest of the variables in the fcst/obs fields
without quitting when it does not find a variable?
>>
>> 2. In the same vain, can point_stat compute DPT from the SPFH
(or the other way around) in the instance that DPT or SPFH is
available, but the other is not?
>>
>> Thanks for the help!
>> Jonathan
>>
>>
--------------------------------------------------------------------------------------------------
>> Jonathan Case, ENSCO Inc.
>> NASA Short-term Prediction Research and Transition Center (aka
SPoRT Center)
>> 320 Sparkman Drive, Room 3062
>> Huntsville, AL 35805
>> Voice: 256.961.7504
>> Fax: 256.961.7788
>> Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
>>
--------------------------------------------------------------------------------------------------
>>
>> "Whether the weather is cold, or whether the weather is hot, we'll
weather
>> the weather whether we like it or not!"
>>
>
------------------------------------------------
More information about the Met_help
mailing list