[Met_help] Observation "Level"
John Halley Gotway
johnhg at rap.ucar.edu
Tue Mar 9 08:35:35 MST 2010
Jackie,
Try running the following command on your input GRIB file:
wgrib in_file.grib | egrep "33|34|11"
You'll see that the level values for U-component of wind, V-component of
wind, and temperature are likely set to a value of 2 (kpds7=2). That
means that the "surface" winds and temperature are actually defined at
2-meters. So use:
"33/Z2", "34/Z2", and "11/Z2" for those
Sorry for misleading you earlier about the level values for winds. I'd
really suggest using the wgrib utility to interrogate your GRIB files and
figure out which fields/levels you'd like to verify.
So I'd suggest setting:
fcst_field[] = [
"7/Z0","7/P850","7/P500","7/P250"
"33/Z2", "34/Z2",
"33/P850", "34/P850",
"33/P500", "34/P500",
"33/P250", "34/P250"
"11/Z2", "11/P850","11/P500","11/P250" ];
You'll notice that I've changed the order of the U winds and V winds in
the list. In the notes in the Grid-Stat config file
(http://www.dtcenter.org/met/users/support/online_tutorial/METv2.0/grid_stat/GridStatConfig_default)
we suggest listing 33 followed by 34 at the same level in order to compute
the VL1L2 output lines.
Clear as mud?
Thanks,
John
> Hi John,
>
> I tried entering "Z0" and the output file from grid_stat showed
> statistics for the temp and hght fields at Z0 but not for the vector
> winds (UGRD and VGRD) - only stats for the 850, 500, and 250 pressure
> levels. That part of the config file looks like this:
>
> //
> fcst_field[] = [ "7/Z0","7/P850","7/P500","7/P250","33/Z0",
> "33/P850","33/P500","33/P250","34/Z0",
> "34/P850","34/P500","34/P250","11/Z0",
> "11/P850","11/P500","11/P250" ];
> obs_field[] = [];
>
> //
> Have I made a mistake or is there a different convention for surface
> wind vector fields?
>
> 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 rap.ucar.edu]
> Sent: Monday, March 08, 2010 11:38 AM
> To: Miller Jackie JCM
> Cc: met_help at ucar.edu
> Subject: RE: [Met_help] Observation "Level"
>
> Jackie,
>
> For surface fields, you should probably indicate a vertical level value
> of
> 0. Something like: "7/Z0" and "33/Z0"
>
> In the fcst_field, the number or abbreviation before the '/' tells
> Grid-Stat the meteorological variable you'd like to use (i.e. temp,
> press,
> winds). After the '/', you tell Grid-Stat what level value you'd like.
> If you run your GRIB file through the "wgrib" utility to dump
> information
> about it, you'll see that the surface fields have a level value of 0
> (kpds7=0 in the wgrib output). "Z0" tells Grid-Stat to look for a
> vertical level with a value of 0.
>
> Please take a look at the comments in the Grid-Stat configuration file
> for
> a description of the level types to use. And feel free to write if any
> more issues come up.
>
> Thanks,
> John
>
>> Hi John,
>>
>> I have been working with the toolkit and able to generate some output.
>> I have been using the grid-stat tool to verify model output. I want
> to
>> verify the temperature, pressure, and winds at the sfc. I tried using
>> the following as forecast fields: "7/PRMSL", "33/PRMSL", etc. but the
>> sfc values don't show up in the output file. What is the naming
>> convention for verifying these fields at the sfc?
>>
>> Thanks,
>> 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