[Met_help] [rt.rap.ucar.edu #40188] History for Quick grib code question
RAL HelpDesk {for Paul Oldenburg}
met_help at ucar.edu
Fri Sep 10 15:02:37 MDT 2010
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
What grib code should I give to my ascii observation (processed by ascii2nc)
to be matched with the "cloud bottom height" produced by WRF Post processor?
The WPP gives this field a grib code of 7, but that standard grib code would
be interpreted incorredtly by ascii2nc, correct?
Thanks,
Scott
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #40188] Quick grib code question
From: Paul Oldenburg
Time: Thu Aug 19 13:54:37 2010
Scott,
You should use the same grib code in your ascii2nc input file that is
used in the output from the WRF post processor.
The reason is that ascii2nc just does a simple match on the grib code,
regardless of which field the grib code refers
to. Thus, for all such observations, you should put a 7 in column 7
so that point_stat will match them. Does that make
sense? Please let us know if you have any more questions.
Thanks,
Paul
RAL HelpDesk {for Scott Rabenhorst} wrote:
> Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
> Transaction: Ticket created by scott.rabenhorst at gmail.com
> Queue: met_help
> Subject: Quick grib code question
> Owner: Nobody
> Requestors: scott.rabenhorst at gmail.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
>
>
> Hello,
>
> What grib code should I give to my ascii observation (processed by
ascii2nc)
> to be matched with the "cloud bottom height" produced by WRF Post
processor?
> The WPP gives this field a grib code of 7, but that standard grib
code would
> be interpreted incorredtly by ascii2nc, correct?
>
> Thanks,
> Scott
------------------------------------------------
Subject: Quick grib code question
From: Scott Rabenhorst
Time: Thu Aug 19 14:20:11 2010
Hi Paul,
I still am confused on how point_stat will match variables correctly
without
a field name. WPP produces several fields with GRIB code 7 (Terrain
height,
cloud top height, cloud bottom height, height of freezing level, etc).
As
far as I know, there is no was to set a field name using ascii2nc...am
I
correct? If there was, then I could see matching variables combined
with
their respective grib codes, otherwise how does point_stat compare
there
right fields? Am I making sense? Maybe I have overlooked something in
ascii2nc. Please let me know.
Thanks,
Scott
On Thu, Aug 19, 2010 at 3:54 PM, RAL HelpDesk {for Paul Oldenburg} <
met_help at ucar.edu> wrote:
> Scott,
>
> You should use the same grib code in your ascii2nc input file that
is used
> in the output from the WRF post processor.
> The reason is that ascii2nc just does a simple match on the grib
code,
> regardless of which field the grib code refers
> to. Thus, for all such observations, you should put a 7 in column 7
so
> that point_stat will match them. Does that make
> sense? Please let us know if you have any more questions.
>
> Thanks,
>
> Paul
>
>
> RAL HelpDesk {for Scott Rabenhorst} wrote:
> > Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
> > Transaction: Ticket created by scott.rabenhorst at gmail.com
> > Queue: met_help
> > Subject: Quick grib code question
> > Owner: Nobody
> > Requestors: scott.rabenhorst at gmail.com
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
> >
> >
> > Hello,
> >
> > What grib code should I give to my ascii observation (processed by
> ascii2nc)
> > to be matched with the "cloud bottom height" produced by WRF Post
> processor?
> > The WPP gives this field a grib code of 7, but that standard grib
code
> would
> > be interpreted incorredtly by ascii2nc, correct?
> >
> > Thanks,
> > Scott
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #40188] Quick grib code question
From: Paul Oldenburg
Time: Thu Aug 19 15:59:03 2010
Scott,
First of all, let me acknowledge that point_stat was not designed for
verifying fields that are not on pressure levels.
As such, the solution to your problem may seem a little unwieldy.
Use the grib code of 7 as I previously suggested in
your ascii2nc input file to generate the obs NetCDF input to
point_stat. I suggest you use the following approach to
modify the model grib input:
1. Extract the record of interest from the model grib file that you
intend to verify. Cloud height has grib code 7
(kpds5) and level type 2 (kpds6). This can be done using the wgrib
command. First, determine the record number that
contains the cloud bottom information, using a command similar to
this:
wgrib [model_grib_file] | grep "HGT" | grep "kpds6=2:" | cut -d':' -f1
Once you have this record number, use wgrib to extract that record
into a new grib file, using a command like this:
wgrib [model_grib_file] -o [output_grib_file] -grib -d [record_num]
2. In the point_stat config file, use the following setting for
fcst_field:
fcst_field[] = [ "HGT/L0" ];
Run point_stat with the extracted grib file that you created in step 1
and point_stat should only match pairs with model
data that corresponds to cloud bottom. Does this make sense? Please
let us know if you have any questions.
Thanks,
Paul
RAL HelpDesk {for Scott Rabenhorst} wrote:
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
>
> Hi Paul,
>
> I still am confused on how point_stat will match variables correctly
without
> a field name. WPP produces several fields with GRIB code 7 (Terrain
height,
> cloud top height, cloud bottom height, height of freezing level,
etc). As
> far as I know, there is no was to set a field name using
ascii2nc...am I
> correct? If there was, then I could see matching variables combined
with
> their respective grib codes, otherwise how does point_stat compare
there
> right fields? Am I making sense? Maybe I have overlooked something
in
> ascii2nc. Please let me know.
>
> Thanks,
> Scott
>
>
> On Thu, Aug 19, 2010 at 3:54 PM, RAL HelpDesk {for Paul Oldenburg} <
> met_help at ucar.edu> wrote:
>
>> Scott,
>>
>> You should use the same grib code in your ascii2nc input file that
is used
>> in the output from the WRF post processor.
>> The reason is that ascii2nc just does a simple match on the grib
code,
>> regardless of which field the grib code refers
>> to. Thus, for all such observations, you should put a 7 in column
7 so
>> that point_stat will match them. Does that make
>> sense? Please let us know if you have any more questions.
>>
>> Thanks,
>>
>> Paul
>>
>>
>> RAL HelpDesk {for Scott Rabenhorst} wrote:
>>> Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
>>> Transaction: Ticket created by scott.rabenhorst at gmail.com
>>> Queue: met_help
>>> Subject: Quick grib code question
>>> Owner: Nobody
>>> Requestors: scott.rabenhorst at gmail.com
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
>>>
>>>
>>> Hello,
>>>
>>> What grib code should I give to my ascii observation (processed by
>> ascii2nc)
>>> to be matched with the "cloud bottom height" produced by WRF Post
>> processor?
>>> The WPP gives this field a grib code of 7, but that standard grib
code
>> would
>>> be interpreted incorredtly by ascii2nc, correct?
>>>
>>> Thanks,
>>> Scott
>>
>>
------------------------------------------------
Subject: Quick grib code question
From: Scott Rabenhorst
Time: Thu Aug 19 16:33:57 2010
Hi Paul,
Thanks for the method you suggested. So it appears the idea here is to
isolate both the forecast and observation fields that are desired,
then
compare them. I guess this would be the methodology behind any
comparison
field without a unique grib code. Thanks for the info, I'll give this
a try.
~Scott
On Thu, Aug 19, 2010 at 5:59 PM, RAL HelpDesk {for Paul Oldenburg} <
met_help at ucar.edu> wrote:
> Scott,
>
> First of all, let me acknowledge that point_stat was not designed
for
> verifying fields that are not on pressure levels.
> As such, the solution to your problem may seem a little unwieldy.
Use the
> grib code of 7 as I previously suggested in
> your ascii2nc input file to generate the obs NetCDF input to
point_stat. I
> suggest you use the following approach to
> modify the model grib input:
>
> 1. Extract the record of interest from the model grib file that you
intend
> to verify. Cloud height has grib code 7
> (kpds5) and level type 2 (kpds6). This can be done using the wgrib
> command. First, determine the record number that
> contains the cloud bottom information, using a command similar to
this:
>
> wgrib [model_grib_file] | grep "HGT" | grep "kpds6=2:" | cut -d':'
-f1
>
> Once you have this record number, use wgrib to extract that record
into a
> new grib file, using a command like this:
>
> wgrib [model_grib_file] -o [output_grib_file] -grib -d [record_num]
>
> 2. In the point_stat config file, use the following setting for
> fcst_field:
>
> fcst_field[] = [ "HGT/L0" ];
>
> Run point_stat with the extracted grib file that you created in step
1 and
> point_stat should only match pairs with model
> data that corresponds to cloud bottom. Does this make sense?
Please let
> us know if you have any questions.
>
> Thanks,
>
> Paul
>
> RAL HelpDesk {for Scott Rabenhorst} wrote:
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
> >
> > Hi Paul,
> >
> > I still am confused on how point_stat will match variables
correctly
> without
> > a field name. WPP produces several fields with GRIB code 7
(Terrain
> height,
> > cloud top height, cloud bottom height, height of freezing level,
etc). As
> > far as I know, there is no was to set a field name using
ascii2nc...am I
> > correct? If there was, then I could see matching variables
combined with
> > their respective grib codes, otherwise how does point_stat compare
there
> > right fields? Am I making sense? Maybe I have overlooked something
in
> > ascii2nc. Please let me know.
> >
> > Thanks,
> > Scott
> >
> >
> > On Thu, Aug 19, 2010 at 3:54 PM, RAL HelpDesk {for Paul Oldenburg}
<
> > met_help at ucar.edu> wrote:
> >
> >> Scott,
> >>
> >> You should use the same grib code in your ascii2nc input file
that is
> used
> >> in the output from the WRF post processor.
> >> The reason is that ascii2nc just does a simple match on the grib
code,
> >> regardless of which field the grib code refers
> >> to. Thus, for all such observations, you should put a 7 in
column 7 so
> >> that point_stat will match them. Does that make
> >> sense? Please let us know if you have any more questions.
> >>
> >> Thanks,
> >>
> >> Paul
> >>
> >>
> >> RAL HelpDesk {for Scott Rabenhorst} wrote:
> >>> Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
> >>> Transaction: Ticket created by scott.rabenhorst at gmail.com
> >>> Queue: met_help
> >>> Subject: Quick grib code question
> >>> Owner: Nobody
> >>> Requestors: scott.rabenhorst at gmail.com
> >>> Status: new
> >>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188>
> >>>
> >>>
> >>> Hello,
> >>>
> >>> What grib code should I give to my ascii observation (processed
by
> >> ascii2nc)
> >>> to be matched with the "cloud bottom height" produced by WRF
Post
> >> processor?
> >>> The WPP gives this field a grib code of 7, but that standard
grib code
> >> would
> >>> be interpreted incorredtly by ascii2nc, correct?
> >>>
> >>> Thanks,
> >>> Scott
> >>
> >>
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #40188] Quick grib code question
From: John Halley Gotway
Time: Thu Aug 19 21:32:13 2010
Scott,
Hello, my name is John Halley Gotway, and I work on MET-Help support
as
well. I just wanted to jump in here and make a quick comment.
Generally,
this type of shuffling around of GRIB records isn't necessary.
For example, in a typical WPP output file, you may have many records
that
all use the GRIB code of 7 for height (HGT). Most of them will be
defined
on pressure levels where the value for that level is pressure value
(e.g.
500mb, 750mb, and so on). You'd access these GRIB records in the MET
config files by saying "HGT/P500" or "HGT/P750". The 'P' tells MET to
only look for GRIB records defined on a pressure level.
However, you're after the cloud base height. It's level value is
actually
encoded as 0. In the sample WPP output data we have for testing, we
saw
another HGT record with a level value of 0 - it was defined to be at
the
surface.
If you select "HGT/L0" in the MET config files (the 'L' tells MET to
not
check the type of level), it'll look through the GRIB file for any
record
that contains HGT with a level value of 0. In our test data, since it
encountered the one for the surface first, it used that one.
So this process of using wgrib to extract the record before verifying
it
is only necessary when you have multiple GRIB records using the same
GRIB
code AND the same level value (a value of 0 in your case). It hasn't
been
an issue for most users. But I suppose that most users haven't been
verifying the cloud base to our knowledge.
Hope that helps clarify.
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
>
> Hi Paul,
>
> Thanks for the method you suggested. So it appears the idea here is
to
> isolate both the forecast and observation fields that are desired,
then
> compare them. I guess this would be the methodology behind any
comparison
> field without a unique grib code. Thanks for the info, I'll give
this a
> try.
>
> ~Scott
>
>
>
> On Thu, Aug 19, 2010 at 5:59 PM, RAL HelpDesk {for Paul Oldenburg} <
> met_help at ucar.edu> wrote:
>
>> Scott,
>>
>> First of all, let me acknowledge that point_stat was not designed
for
>> verifying fields that are not on pressure levels.
>> As such, the solution to your problem may seem a little unwieldy.
Use
>> the
>> grib code of 7 as I previously suggested in
>> your ascii2nc input file to generate the obs NetCDF input to
point_stat.
>> I
>> suggest you use the following approach to
>> modify the model grib input:
>>
>> 1. Extract the record of interest from the model grib file that
you
>> intend
>> to verify. Cloud height has grib code 7
>> (kpds5) and level type 2 (kpds6). This can be done using the wgrib
>> command. First, determine the record number that
>> contains the cloud bottom information, using a command similar to
this:
>>
>> wgrib [model_grib_file] | grep "HGT" | grep "kpds6=2:" | cut -d':'
-f1
>>
>> Once you have this record number, use wgrib to extract that record
into
>> a
>> new grib file, using a command like this:
>>
>> wgrib [model_grib_file] -o [output_grib_file] -grib -d [record_num]
>>
>> 2. In the point_stat config file, use the following setting for
>> fcst_field:
>>
>> fcst_field[] = [ "HGT/L0" ];
>>
>> Run point_stat with the extracted grib file that you created in
step 1
>> and
>> point_stat should only match pairs with model
>> data that corresponds to cloud bottom. Does this make sense?
Please
>> let
>> us know if you have any questions.
>>
>> Thanks,
>>
>> Paul
>>
>> RAL HelpDesk {for Scott Rabenhorst} wrote:
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
>> >
>> > Hi Paul,
>> >
>> > I still am confused on how point_stat will match variables
correctly
>> without
>> > a field name. WPP produces several fields with GRIB code 7
(Terrain
>> height,
>> > cloud top height, cloud bottom height, height of freezing level,
etc).
>> As
>> > far as I know, there is no was to set a field name using
ascii2nc...am
>> I
>> > correct? If there was, then I could see matching variables
combined
>> with
>> > their respective grib codes, otherwise how does point_stat
compare
>> there
>> > right fields? Am I making sense? Maybe I have overlooked
something in
>> > ascii2nc. Please let me know.
>> >
>> > Thanks,
>> > Scott
>> >
>> >
>> > On Thu, Aug 19, 2010 at 3:54 PM, RAL HelpDesk {for Paul
Oldenburg} <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Scott,
>> >>
>> >> You should use the same grib code in your ascii2nc input file
that is
>> used
>> >> in the output from the WRF post processor.
>> >> The reason is that ascii2nc just does a simple match on the grib
>> code,
>> >> regardless of which field the grib code refers
>> >> to. Thus, for all such observations, you should put a 7 in
column 7
>> so
>> >> that point_stat will match them. Does that make
>> >> sense? Please let us know if you have any more questions.
>> >>
>> >> Thanks,
>> >>
>> >> Paul
>> >>
>> >>
>> >> RAL HelpDesk {for Scott Rabenhorst} wrote:
>> >>> Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
>> >>> Transaction: Ticket created by scott.rabenhorst at gmail.com
>> >>> Queue: met_help
>> >>> Subject: Quick grib code question
>> >>> Owner: Nobody
>> >>> Requestors: scott.rabenhorst at gmail.com
>> >>> Status: new
>> >>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188>
>> >>>
>> >>>
>> >>> Hello,
>> >>>
>> >>> What grib code should I give to my ascii observation (processed
by
>> >> ascii2nc)
>> >>> to be matched with the "cloud bottom height" produced by WRF
Post
>> >> processor?
>> >>> The WPP gives this field a grib code of 7, but that standard
grib
>> code
>> >> would
>> >>> be interpreted incorredtly by ascii2nc, correct?
>> >>>
>> >>> Thanks,
>> >>> Scott
>> >>
>> >>
>>
>>
>>
>>
>
------------------------------------------------
Subject: Quick grib code question
From: Scott Rabenhorst
Time: Fri Aug 20 08:50:35 2010
Hi John,
Thanks for the helpful explanation. This makes sense and selecting a
level
is an easier solution. In fact, table 3 in the WPP user's guide shows
a
columns grib-codes and levels, and for the most part they are unique.
It
seems the most important things to be aware of are WPP fields with
identical
grib-code and level, and also separating different observation fields
that
share the same grib-code. I will give your suggestion a try. Thanks
again
for the tips, help, and discussion.
~Scott
On Thu, Aug 19, 2010 at 11:32 PM, RAL HelpDesk {for John Halley
Gotway} <
met_help at ucar.edu> wrote:
> Scott,
>
> Hello, my name is John Halley Gotway, and I work on MET-Help support
as
> well. I just wanted to jump in here and make a quick comment.
Generally,
> this type of shuffling around of GRIB records isn't necessary.
>
> For example, in a typical WPP output file, you may have many records
that
> all use the GRIB code of 7 for height (HGT). Most of them will be
defined
> on pressure levels where the value for that level is pressure value
(e.g.
> 500mb, 750mb, and so on). You'd access these GRIB records in the
MET
> config files by saying "HGT/P500" or "HGT/P750". The 'P' tells MET
to
> only look for GRIB records defined on a pressure level.
>
> However, you're after the cloud base height. It's level value is
actually
> encoded as 0. In the sample WPP output data we have for testing, we
saw
> another HGT record with a level value of 0 - it was defined to be at
the
> surface.
>
> If you select "HGT/L0" in the MET config files (the 'L' tells MET to
not
> check the type of level), it'll look through the GRIB file for any
record
> that contains HGT with a level value of 0. In our test data, since
it
> encountered the one for the surface first, it used that one.
>
> So this process of using wgrib to extract the record before
verifying it
> is only necessary when you have multiple GRIB records using the same
GRIB
> code AND the same level value (a value of 0 in your case). It
hasn't been
> an issue for most users. But I suppose that most users haven't been
> verifying the cloud base to our knowledge.
>
> Hope that helps clarify.
>
> Thanks,
> John
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
> >
> > Hi Paul,
> >
> > Thanks for the method you suggested. So it appears the idea here
is to
> > isolate both the forecast and observation fields that are desired,
then
> > compare them. I guess this would be the methodology behind any
comparison
> > field without a unique grib code. Thanks for the info, I'll give
this a
> > try.
> >
> > ~Scott
> >
> >
> >
> > On Thu, Aug 19, 2010 at 5:59 PM, RAL HelpDesk {for Paul Oldenburg}
<
> > met_help at ucar.edu> wrote:
> >
> >> Scott,
> >>
> >> First of all, let me acknowledge that point_stat was not designed
for
> >> verifying fields that are not on pressure levels.
> >> As such, the solution to your problem may seem a little
unwieldy. Use
> >> the
> >> grib code of 7 as I previously suggested in
> >> your ascii2nc input file to generate the obs NetCDF input to
point_stat.
> >> I
> >> suggest you use the following approach to
> >> modify the model grib input:
> >>
> >> 1. Extract the record of interest from the model grib file that
you
> >> intend
> >> to verify. Cloud height has grib code 7
> >> (kpds5) and level type 2 (kpds6). This can be done using the
wgrib
> >> command. First, determine the record number that
> >> contains the cloud bottom information, using a command similar to
this:
> >>
> >> wgrib [model_grib_file] | grep "HGT" | grep "kpds6=2:" | cut
-d':' -f1
> >>
> >> Once you have this record number, use wgrib to extract that
record into
> >> a
> >> new grib file, using a command like this:
> >>
> >> wgrib [model_grib_file] -o [output_grib_file] -grib -d
[record_num]
> >>
> >> 2. In the point_stat config file, use the following setting for
> >> fcst_field:
> >>
> >> fcst_field[] = [ "HGT/L0" ];
> >>
> >> Run point_stat with the extracted grib file that you created in
step 1
> >> and
> >> point_stat should only match pairs with model
> >> data that corresponds to cloud bottom. Does this make sense?
Please
> >> let
> >> us know if you have any questions.
> >>
> >> Thanks,
> >>
> >> Paul
> >>
> >> RAL HelpDesk {for Scott Rabenhorst} wrote:
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188 >
> >> >
> >> > Hi Paul,
> >> >
> >> > I still am confused on how point_stat will match variables
correctly
> >> without
> >> > a field name. WPP produces several fields with GRIB code 7
(Terrain
> >> height,
> >> > cloud top height, cloud bottom height, height of freezing
level, etc).
> >> As
> >> > far as I know, there is no was to set a field name using
ascii2nc...am
> >> I
> >> > correct? If there was, then I could see matching variables
combined
> >> with
> >> > their respective grib codes, otherwise how does point_stat
compare
> >> there
> >> > right fields? Am I making sense? Maybe I have overlooked
something in
> >> > ascii2nc. Please let me know.
> >> >
> >> > Thanks,
> >> > Scott
> >> >
> >> >
> >> > On Thu, Aug 19, 2010 at 3:54 PM, RAL HelpDesk {for Paul
Oldenburg} <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> >> Scott,
> >> >>
> >> >> You should use the same grib code in your ascii2nc input file
that is
> >> used
> >> >> in the output from the WRF post processor.
> >> >> The reason is that ascii2nc just does a simple match on the
grib
> >> code,
> >> >> regardless of which field the grib code refers
> >> >> to. Thus, for all such observations, you should put a 7 in
column 7
> >> so
> >> >> that point_stat will match them. Does that make
> >> >> sense? Please let us know if you have any more questions.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Paul
> >> >>
> >> >>
> >> >> RAL HelpDesk {for Scott Rabenhorst} wrote:
> >> >>> Thu Aug 19 11:27:38 2010: Request 40188 was acted upon.
> >> >>> Transaction: Ticket created by scott.rabenhorst at gmail.com
> >> >>> Queue: met_help
> >> >>> Subject: Quick grib code question
> >> >>> Owner: Nobody
> >> >>> Requestors: scott.rabenhorst at gmail.com
> >> >>> Status: new
> >> >>> Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=40188>
> >> >>>
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> What grib code should I give to my ascii observation
(processed by
> >> >> ascii2nc)
> >> >>> to be matched with the "cloud bottom height" produced by WRF
Post
> >> >> processor?
> >> >>> The WPP gives this field a grib code of 7, but that standard
grib
> >> code
> >> >> would
> >> >>> be interpreted incorredtly by ascii2nc, correct?
> >> >>>
> >> >>> Thanks,
> >> >>> Scott
> >> >>
> >> >>
> >>
> >>
> >>
> >>
> >
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list