[Met_help] Observation "Level"
John Halley Gotway
johnhg at ucar.edu
Fri Feb 19 12:08:33 MST 2010
Jackie,
I'll try to answer your questions inline below...
jackie.miller at vaisala.com wrote:
> John,
>
>
>
> Thank you for the note. We will look forward to hearing about the new
> updates in the Spring release of MET.
>
>
>
> In addition to what you described, we would like to use the Point-stat
> tool to compare sfc observations to a sfc forecast. I believe that this
> is in fact possible with the current version. Can you please clarify
> the necessary inputs for the following fields in the ascii observation
> file:
>
>
By convention, we consider 2-meter temperature and 10-meter winds to be surface forecasts. And we consider observations of type ADPSFC or SFCSHP to be observations at the surface.
So when you verify 2-meter temperature, you should do so versus ADPSFC observations:
fcst_field[] = [ "TMP/Z2" ];
message_type[] = [ "ADPSFC" ];
So in preparing you observations in ASCII2NC, set the message type to "ADPSFC". And when you do that, you won't even need to specify a "level" value for them since Point-Stat won't use it. So you
could set it to "-9999" for missing data. Any observation with a message type of ADPSFC is assumed to be at the surface.
Let me point out that elevation and height (columns 6 and 9) are currently NOT being used in Point-Stat. We put them in there as placeholders for future use.
Column 6: Elevation - this defines the elevation of the STATION in msl. If you have the elevation, go ahead and put it in, but if not, just fill it with "-9999". It is NOT used in Point-Stat.
Column 9: Height - this defines the height of the observation in msl. If you have the height, go ahead and put it in, but if not, just fill it with "-9999". It is NOT used in Point-Stat. For
2-meter temperature, the height would be the elevation + 2.
Column 8: Level - this defines the the vertical level for the observation. For 500-mb temperature, put in a value of 500. For 2-meter temperature, put in a value of 2. For an observation of wind at
60-meters, put in a value of 60. For 12-hour accumulated precip, put in a value of 12. But remember, if the message type is ADPSFC, the observation is assumed to be at the surface regardless of this
level value.
I'm sorry this is so confusing. But hopefully we can get it working they way you'd like.
>
> - Column 8 ("Level")
>
> o In your original recommendation you suggested setting "level"
> to the height of the observation. These obs are taken at 2m, so do I
> need to indicate that in this field (i.e. add 2m to the column 6
> ("height") value) or set it equal to column 6? If the latter, then will
> column 6, 8, and 9 values all be equal? (Elevation, Level, and Height)
>
>
>
> - Column 1 ("Message type"): Should I set the message type to
> ADPSFC?
>
>
Yes, for surface observations, use "ADPSFC". And for surface observations over water, use "SFCSHP".
>
> Also, for the grid-stat tool, the fcst_field[] variable must include a
> level indicator. What is the MET convention for MSLP? What would be
> the appropriate values for the level (PNNN)?
>
>
So you're interested in Mean Sea Level Pressure. Take a look in your GRIB file to see what you have. For example, in some test data I have, I found two different types of Mean Sea Level Pressure:
533:84600066:d=08122200:PRMSL:kpds5=2:kpds6=102:kpds7=0:TR=10:P1=0:P2=36:TimeU=1:MSL:36hr fcst:NAve=0
535:85023760:d=08122200:MSLET:kpds5=130:kpds6=102:kpds7=0:TR=10:P1=0:P2=36:TimeU=1:MSL:36hr fcst:NAve=0
PRMSL is GRIB code 2, and MSLET is GRIB code 130. You can refer to this table:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
In both cases, the level value for these GRIB records is defined as 0. So I'd try the following:
fcst_field[] = [ "PRMSL/Z0" ];
>
> Lastly, from playing with the grid-stat tool, it appears that you MUST
> specify fcst_thresh[] values even if you don't want to generate discrete
> statistics. Is this the case? I only wanted to generate continuous
> statistics but got an error that a threshold must be defined for each
> forecast field.
>
Yes, that is the case. Just put in some dummy forecast threshold values in for each field you're verifying. If you don't request categorical statistics, those thresholds won't actually be used.
Sorry for this inconvenience. I suppose we should really on do that check if you've requested statistics in the output that actually do rely on a threshold being applied.
Just let me know if you need any more clarification.
Thanks,
John
>
>
> Thanks for your help. I look forward to your responses,
>
>
>
> Jackie
>
>
>
>
>
>
>
> Jackie Miller
>
> Meteorologist
>
> Vaisala Inc.
>
>
>
> Phone +1 303 885 3251
>
> Mobile +1 303 885 3251
>
> www.vaisala.com
>
>
>
> This electronic message contains a communication which is strictly
> confidential and intended solely for the addressee(s). Any
> non-addressee is prohibited from reading, disseminating, distributing,
> or copying the communication contained herein. If you are in possession
> of the communication in error, please immediately notify the sender via
> an electronic response and destroy the original communication. Thank
> you.
>
>
>
> U.S. Export Restrictions & Disclaimer: Export of any technical
> information contained in this email and/or its attachments is subject to
> the export control laws and regulations of the U.S. Government and may
> require a valid license or written approval prior to export.
>
>
>
> -----Original Message-----
> From: John Halley Gotway [mailto:johnhg at ucar.edu]
> Sent: Friday, February 19, 2010 10:12 AM
> To: Miller Jackie JCM; met_help
> Subject: Re: [Met_help] Observation "Level"
>
>
>
> Jackie,
>
>
>
> Sorry for the delay in getting back to you. I was out of the office for
> a while.
>
>
>
> To support matching at the types of levels we've discussed we'll need to
> do some development work on our side. In particular, Point-Stat isn't
> set up to do vertical interpolation between two vertical
>
> levels. For example, if you have forecasts at 10m and 20m above ground
> and an observation at 15m, Point-Stat wouldn't be able to vertically
> interpolate between the 10m and 20m forecast levels to
>
> match the observation at 15m.
>
>
>
> We're currently working on enhancements to MET for the next release in
> the spring, 2010. When we begin working on this in Point-Stat, I'll let
> you know if any more questions arise.
>
>
>
> Thanks,
>
> John
>
>
>
> jackie.miller at vaisala.com wrote:
>
>> Hi John,
>
>
>> I wanted to check to see if you need any more information from me.
>
>> In your original response you suggested to set the "Level" and
> "Message
>
>> type" fields to the following:
>
>>> - Set "level" to the height of the observation 10, 30, or 60m.
>
>
>>> - Set the message type to ADPSFC.
>
>> Is this still your recommendation? Or is that dependent on the
> solution
>
>> that we reach?
>
>
>> Thanks again for your help and I look forward to an update.
>
>> Best regards,
>
>> Jackie
>
>
>> Jackie Miller
>
>> Meteorologist
>
>> Vaisala Inc.
>
>
>> Phone +1 303 885 3251
>
>> Mobile +1 303 885 3251
>
>> www.vaisala.com
>
>>
>
>> This electronic message contains a communication which is strictly
>
>> confidential and intended solely for the addressee(s). Any
>
>> non-addressee is prohibited from reading, disseminating, distributing,
>
>> or copying the communication contained herein. If you are in
> possession
>
>> of the communication in error, please immediately notify the sender
> via
>
>> an electronic response and destroy the original communication. Thank
>
>> you.
>
>>
>
>> U.S. Export Restrictions & Disclaimer: Export of any technical
>
>> information contained in this email and/or its attachments is subject
> to
>
>> the export control laws and regulations of the U.S. Government and may
>
>> require a valid license or written approval prior to export.
>
>> -----Original Message-----
>
>> From: John Halley Gotway [mailto:johnhg at ucar.edu]
>
>> Sent: Wednesday, February 03, 2010 1:30 PM
>
>> To: Miller Jackie JCM
>
>> Cc: met_help
>
>> Subject: Re: [Met_help] Observation "Level"
>
>
>> Jackie,
>
>
>> Here are a few more questions...
>
>
>> (1) What are the forecast levels that will be used? Are they pressure
>
>> levels, like 800mb? Or are they vertical levels above ground, like
> 10,
>
>> 20, 30, 40, 50, 60 meters above ground?
>
>
>> (2) What is the level information for the observations? It sounds
> like
>
>> they're at particular meters above ground level. Correct?
>
>
>> (3) How would you like those observations levels to be matched to the
>
>> forecast levels? For example, suppose you have forecasts of 50 and 60
>
>> meters above ground level and an observed value at 57
>
>> meters. Would you want to compare that to the forecast value at 60
>
>> meters, or would you want to perform vertical interpolation between
> the
>
>> forecasts at 50 and 60 meters?
>
>
>> The answers to those questions will help guide how we could support
>
>> this. We've been meaning to enhance our support for verifying at
>
>> different vertical levels for a while. And this may prove to be a
>
>> good opportunity to do so.
>
>
>> Thanks,
>
>> John
>
>
>> jackie.miller at vaisala.com wrote:
>
>>> Hi John,
>
>
>>>
>
>
>>> To answer your questions:
>
>
>>> * We will be verifying forecasts for variables at multiple
>
>>> levels within the PBL.
>
>
>>> * Observations are from a range of levels.
>
>
>>>
>
>
>>> Unfortunately those answers aren't associated with the quick-fix you
>
>>> described...(the observation and forecast levels don't match). I will
>
>> be
>
>>> interested to hear what is possible!
>
>
>>>
>
>
>>> Thanks for your help,
>
>
>>> Jackie
>
>
>>>
>
>
>>>
>
>
>>> Jackie Miller
>
>
>>> Meteorologist
>
>
>>> Vaisala Inc.
>
>
>>>
>
>
>>> Phone +1 303 885 3251
>
>
>>> Mobile +1 303 885 3251
>
>
>>> www.vaisala.com
>
>
>>>
>
>
>>> This electronic message contains a communication which is strictly
>
>>> confidential and intended solely for the addressee(s). Any
>
>>> non-addressee is prohibited from reading, disseminating,
> distributing,
>
>>> or copying the communication contained herein. If you are in
>
>> possession
>
>>> of the communication in error, please immediately notify the sender
>
>> via
>
>>> an electronic response and destroy the original communication. Thank
>
>>> you.
>
>
>>>
>
>
>>> U.S. Export Restrictions & Disclaimer: Export of any technical
>
>>> information contained in this email and/or its attachments is subject
>
>> to
>
>>> the export control laws and regulations of the U.S. Government and
> may
>
>>> require a valid license or written approval prior to export.
>
>
>>>
>
>
>>> -----Original Message-----
>
>>> From: John Halley Gotway [mailto:johnhg at ucar.edu]
>
>>> Sent: Wednesday, February 03, 2010 10:32 AM
>
>>> To: Miller Jackie JCM
>
>>> Cc: met_help at ucar.edu
>
>>> Subject: Re: [Met_help] Observation "Level"
>
>
>>>
>
>
>>> Jackie,
>
>
>>>
>
>
>>> Thanks for filling out the registration form. Since you work for
>
>>> Vaisala, I assume you'd like to use MET to verify forecasts for wind
>
>>> farms. And you'd like to use observations at 10, 30, and 60m on
>
>
>>> the towers? Is that correct?
>
>
>>>
>
>
>>> The logic in the Point-Stat tool (as released in METv2.0) is not
>
>>> currently robust enough to do the type of matching you'd like to
>
>>> perform. We had limited the verification of vertical levels to
>
>
>>> 2-meter temperature and 10-meter winds. However, I think it may only
>
>>> take a few lines of code in one of the source file to do what you'd
>
>> like
>
>>> to do. But I need to ask you a few questions first...
>
>
>>>
>
>
>>> - What are the level values for the forecasts you're trying to
> verify?
>
>>> Do you have wind forecasts for explicitly 10, 30, and 60 meters above
>
>>> ground level?
>
>
>>> - Do you have observations at and want to verify at single levels
> (10,
>
>>> 30, and 60) or a range of levels? For example, do you ever have
>
>>> observations at 58m or 62m, or are they always at 60?
>
>
>>>
>
>
>>> If the answer is that you have forecasts at single levels (10, 30,
> and
>
>>> 60) and your observations are at those same levels, it should be a
>
>> very
>
>>> easy fix to handle that. And in that case, I'd have you
>
>
>>> encode your observations as follows:
>
>
>>> - Set "level" to the height of the observation 10, 30, or 60m.
>
>
>>> - Set the message type to ADPSFC.
>
>
>>>
>
>
>>> The routine we'll need to modify is "add_obs" in the file
>
>>> METv2.0/lib/vx_met_util/met_stats.cc.
>
>
>>>
>
>
>>> And let me suggest that you retrieve the latest set of patches for
>
>>> METv2.0, if you haven't already done so:
>
>
>
> http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php
>
>>> Just follow the instructions at the top of the page to get all of the
>
>>> patches.
>
>
>>>
>
>
>>> Please tell me the answers to those questions, and we can figure out
>
>> how
>
>>> to proceed.
>
>
>>>
>
>
>>> Thanks,
>
>
>>> John
>
>
>>>
>
>
>>> jackie.miller at vaisala.com wrote:
>
>
>>>> I am creating ASCII observation files to use with the ASCII2NC tool.
>
>>> In
>
>
>>>> the documentation, the ASCII Point Observation Format includes a
>
>> field
>
>>>> called "level" that is "pressure level in hPa or accumulation
>
>> interval
>
>>>> in hours for the observation type". What is the best way to
>
>> determine
>
>>>> this pressure level? And does this value vary depending on the
>
>>> height
>
>
>>>> of the observation in addition to the elevation? (e.g. will
>
>>> measurements
>
>
>>>> taken at 60m, 30m, and 10m on the same tower have different "Level"
>
>>>> values?)
>
>
>>>>
>
>
>>>> Thank you for your help,
>
>
>>>> Jackie
>
>
>>>>
>
>
>>>> Jackie Miller
>
>>>> Meteorologist
>
>
>>>> Vaisala Inc.
>
>
>>>> Phone +1 303 885 3251
>
>>>> Mobile +1 303 885 3251
>
>>>> www.vaisala.com
>
>
> <https://exchange.ou.edu/owa/redir.aspx?C=b302bd7f7cb24f099b2eb70ba1b9bf
>
>
> 5f&URL=https%3a%2f%2fwebmail.vaisala.com%2fexchweb%2fbin%2fredir.asp%3fU
>
>>>> RL%3dhttp%3a%2f%2fwww.vaisala.com>
>
>
>>>>
>
>
>>>> This electronic message contains a communication which is strictly
>
>>>> confidential and intended solely for the addressee(s). Any
>
>>>> non-addressee is prohibited from reading, disseminating,
>
>> distributing,
>
>>>> or copying the communication contained herein. If you are in
>
>>> possession
>
>
>>>> of the communication in error, please immediately notify the sender
>
>>> via
>
>
>>>> an electronic response and destroy the original communication.
> Thank
>
>>>> you.
>
>
>>>>
>
>
>>>> U.S. Export Restrictions & Disclaimer: Export of any technical
>
>>>> information contained in this email and/or its attachments is
> subject
>
>>> to
>
>
>>>> the export control laws and regulations of the U.S. Government and
>
>> may
>
>>>> require a valid license or written approval prior to export.
>
>
>>>>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>>>> _______________________________________________
>
>>>> Met_help mailing list
>
>>>> Met_help at mailman.ucar.edu
>
>>>> http://mailman.ucar.edu/mailman/listinfo/met_help
>
>
>
More information about the Met_help
mailing list