[Met_help] Observation "Level"

John Halley Gotway johnhg at ucar.edu
Fri Feb 19 12:37:12 MST 2010


Jackie,

No, it shouldn't.  I believe ASCII2NC should read whatever you provide.  FYI, by convention, we use 5 decimal points of precision in the MET ASCII output files.

If you see odd behavior, just let me know.

Thanks,
John

jackie.miller at vaisala.com wrote:
> John,
> 
> One more question- does it matter how many decimal places we use in the
> ascii observation fields?  
> 
> 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 1:09 PM
> To: Miller Jackie JCM; met_help
> Subject: Re: [Met_help] Observation "Level"
> 
> 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