[Met_help] [rt.rap.ucar.edu #38090] History for FW: other models in MET point_stat

RAL HelpDesk {for John Halley Gotway} met_help at ucar.edu
Tue Jun 1 10:33:55 MDT 2010


----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hi,

 

I'm trying to do a point_stat verification of our ECMWF data. 

Unfortunately the it keeps saying there's no match (see output below).

If tried playing around with the scanmode, indicatorOfTypeOfLevel, date etc., but didn't help.

Below a link to all the files (ecmwf grib file, configure file and observation file) combined in a zip.

 

https://www.wetransfer.com/dl.php?code=fT6H0wIc&hash=f1ed06b8707947776864e3e6d1bc09161c870c6f053263d0c2ce8d6c981a64016621d71d8fcfc

 

 

Do you know what I'm missing?

 

Kind regards,

 

Daniël

 

------------------------------------------------------------------------

  Daniël van Dijke

  Meteorological Researcher  

  Meteo Consult BV, Wageningen, the Netherlands

  Tel: +31 (0)317 399874

  Email: vandijke at meteogroup.com

------------------------------------------------------------------------

 

 

 

Output point_stat:

--------------------------------------------------------------------------------------------------------------------------

GSL_RNG_TYPE=mt19937

GSL_RNG_SEED=1863646539

Forecast File: /data/research/verification/met//data/test_grib/ecmwf.grb

Climatology File: none

Configuration File: config/PointStatConfig_ecmwf_25km_eu

Observation File: /data/research/verification/met//out/ascii2nc//obs_2010052406.nc

 

----------------------------------------

 

Reading records for VDDSF/R26.

For VDDSF/R26 found 1 forecast levels and 0 climatology levels.

 

----------------------------------------

 

Reading records for NBDSF/R21.

For NBDSF/R21 found 1 forecast levels and 0 climatology levels.

 

----------------------------------------

 

Reading records for MSTAV/R32.

For MSTAV/R32 found 1 forecast levels and 0 climatology levels.

 

----------------------------------------

 

Searching 131336 observations from 19128 PrepBufr messages.

 

----------------------------------------

 

Processing VDDSF/R26 versus TMP/Z2, for observation type ANYSFC, over region FULL, for interpolation method DW_MEAN(4), using 0 pairs.

 

----------------------------------------

 

Processing NBDSF/R21 versus DPT/Z2, for observation type ANYSFC, over region FULL, for interpolation method DW_MEAN(4), using 0 pairs.

 

----------------------------------------

 

Processing MSTAV/R32 versus WIND/Z10, for observation type ANYSFC, over region FULL, for interpolation method DW_MEAN(4), using 0 pairs.

 

----------------------------------------

--------------------------------------------------------------------------------------------------------------------------

 

-----Oorspronkelijk bericht-----
Van: Marlous Jonker 
Verzonden: woensdag 26 mei 2010 8:20
Aan: Daniel van Dijke
Onderwerp: FW: other models in MET point_stat

 

 

 

-----Oorspronkelijk bericht-----

Van: John Halley Gotway [mailto:johnhg at ucar.edu] 

Verzonden: dinsdag 25 mei 2010 17:25

Aan: Marlous Jonker

CC: met_help at mailman.ucar.edu

Onderwerp: Re: other models in MET point_stat

 

Marlous,

 

The MET tools allow you to select different forecast and observation GRIB codes.  For example, here's an excerpt from the Grid-Stat configuration file:

 

//

// Specify a comma-separated list of fields to be verified.  The forecast and

// observation fields may be specified separately.  If the obs_field parameter

// is left blank, it will default to the contents of fcst_field.

//

// Each field is specified as a grib code or corresponding grib code

// abbreviation followed by an accumulation or vertical level indicator.

//

// Each verification field is specified as one of the following:

//    GC/ANNN for accumulation interval NNN

//    GC/ZNNN for vertical level NNN

//    GC/PNNN for pressure level NNN in hPa

//    GC/PNNN-NNN for a range of pressure levels in hPa

//    GC/LNNN for a generic level type

//    GC/RNNN for a specific GRIB record number

//    Where GC is the number of or abbreviation for the grib code

//    to be verified.

// http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html

//

//    NOTE: To verify winds as vectors rather than scalars,

//          specify UGRD (or 33) followd by VGRD (or 34) with the

//          same level values.

//

//    NOTE: To process a probability field, add "/PROB", such as "POP/Z0/PROB".

//

// e.g. fcst_field[] = [ "61/A3", "APCP/A24", "RH/L10" ];

//

fcst_field[] = [ "61/A3" ];

obs_field[]  = [];

 

You'll notice separate setting for the forecast and observation fields.  If you treat WRF as the "forecast" and ECMWF as the "observation", you'd just list out the GRIB codes for each.  A word of

warning, MET doesn't do anything fancy with units.  For example, if you compare a temperature field in Celcius to a temperature field in Kelvin, it won't do any unit conversions for you.  It's your

responsibility to make sure that the units are comparable and to make sense of the verification output.

 

Hope that helps.

 

In the future, please send support questions directly to "met_help at ucar.edu".  We've set up a new tracking system for handling support requests.

 

Thanks,

John

 

Marlous Jonker wrote:

> Hi John,

> 

>  

> 

> After all your useful comments and help on MET point_stat, we managed to

> set up an operational verification of WRF! Now we'd like to make a

> comparison between WRF and the European ECMWF model.

> 

> The output from ECMWF has a different grib ID. How can we let MET

> understand that this grib has a different grib ID than WRF, without

> adapting the grib file itself to the WRF grib ID. 

> 

> The ECMWF and WRF verification is supposed to run after one another, so

> I hope there is a way to change the grib ID of MET in the command line.

> 

>  

> 

> Cheers,

> 

> Marlous

> 

>  

> 

> -------------------------------------------------------------------

> 

>   Marlous Jonker

> 

>   Meteorological Researcher

> 

>   Meteo Consult BV, Wageningen, the Netherlands

> 

>   Tel: +31 (0)317 399872

> 

>   Email: M.Jonker at weer.nl

> 

>   www: research.meteogroup.com

> 

> -------------------------------------------------------------------

> 

>  

> 

> 

> 



-- 

This e-mail is from Meteo Consult B.V., a MeteoGroup company. For more information, see http://www.weer.nl/gebruiksvoorwaarden.

This e-mail may contain confidential information. Only the addressee is permitted to read, copy, distribute or otherwise use this e-mail or any attachments. If you have received it in error, please contact the sender immediately. Any opinion expressed in this e-mail is personal to the sender and may not reflect the opinion of MeteoGroup.

Any e-mail reply to this address may be subject to interception or monitoring for operational reasons or for lawful business practices.


----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: FW: other models in MET point_stat
From: John Halley Gotway
Time: Thu May 27 12:32:28 2010

Daniel,

Thanks for sending that data.  It helped a lot in debugging this
issue.  When users ask the question "why am I getting 0 matched
pairs?", here's what we typically check:
(1) Do the observation locations fall within the forecast domain?
(2) Do the valid times of the observations fall within the
verification time window?
(3) Are the observation message types consistent with what's requested
in the config file?
(4) Are the observation variable types consistent with the what's
requested in the config file?
(5) Are the observation vertical levels consistent with the what's
requested in the config file?

In your case, the answer to all those questions is yes.

But after running it through the debugger, we found that the problem
lies in how the ECMWF GRIB file is packed.  In particular, the
"scan_mode" flag in the Grid Description Section is set wrong.  Here's
a table describing it:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html

In your file, it's set to 64, but based on how the data is packed, it
should be set to 0.  Your data is packed from north to south, but the
scan mode flag says to read it from south to north.

To fix this, you have 2 options:
(1) Update the GRIB file to change the scan mode flag from 64 to 0.
(2) Hard-code a fix for this to compensate for it in the MET code.

Of course, the first option is better, but here's how you'd do the
second:
- Open up the file "METv2.0/lib/vx_met_util/read_grib.cc"
- After line 999, add the following:
       // Daniël van Dijke (05/27/2010)
       // Hard-code ydir to be 0 to fix incorrect ECMWF scan mode
flag.
       ydir = 0;
- This addition should come just before this comment in the code:
       //
       // Multiply longitude values by -1 since the NCAR code
considers
       // degrees west to be positive.
       //
- In the top-level MET directory, do a "make clean" and then a "make"
to rebuild MET.
- Try rerunning your test data.

This will allow MET to work on your ECMWF data, but would break it for
any data that supposed to be indexed in the opposite direction.

Please also note that you will still not see any matched pairs when
verifying 10-meter wind speed.  And the reason for that is that there
are no observations of 10-meter wind speed in your observation file.

Hope that helps,
John Halley Gotway
met_help at ucar.edu


On Wed May 26 06:48:42 2010, D.vanDijke at weer.nl wrote:
> Hi,
>
>
>
> I'm trying to do a point_stat verification of our ECMWF data.
>
> Unfortunately the it keeps saying there's no match (see output
below).
>
> If tried playing around with the scanmode, indicatorOfTypeOfLevel,
> date etc., but didn't help.
>
> Below a link to all the files (ecmwf grib file, configure file and
> observation file) combined in a zip.
>
>
>
>
https://www.wetransfer.com/dl.php?code=fT6H0wIc&hash=f1ed06b8707947776864e3e6d1bc09161c870c6f053263d0c2ce8d6c981a64016621d71d8fcfc
>
>
>
>
>
> Do you know what I'm missing?
>
>
>
> Kind regards,
>
>
>
> Daniël
>
>
>
>
------------------------------------------------------------------------
>
>   Daniël van Dijke
>
>   Meteorological Researcher
>
>   Meteo Consult BV, Wageningen, the Netherlands
>
>   Tel: +31 (0)317 399874
>
>   Email: vandijke at meteogroup.com
>
>
------------------------------------------------------------------------
>
>
>
>
>
>
>
> Output point_stat:
>
>
--------------------------------------------------------------------------------------------------------------------------
>
> GSL_RNG_TYPE=mt19937
>
> GSL_RNG_SEED=1863646539
>
> Forecast File:
> /data/research/verification/met//data/test_grib/ecmwf.grb
>
> Climatology File: none
>
> Configuration File: config/PointStatConfig_ecmwf_25km_eu
>
> Observation File:
> /data/research/verification/met//out/ascii2nc//obs_2010052406.nc
>
>
>
> ----------------------------------------
>
>
>
> Reading records for VDDSF/R26.
>
> For VDDSF/R26 found 1 forecast levels and 0 climatology levels.
>
>
>
> ----------------------------------------
>
>
>
> Reading records for NBDSF/R21.
>
> For NBDSF/R21 found 1 forecast levels and 0 climatology levels.
>
>
>
> ----------------------------------------
>
>
>
> Reading records for MSTAV/R32.
>
> For MSTAV/R32 found 1 forecast levels and 0 climatology levels.
>
>
>
> ----------------------------------------
>
>
>
> Searching 131336 observations from 19128 PrepBufr messages.
>
>
>
> ----------------------------------------
>
>
>
> Processing VDDSF/R26 versus TMP/Z2, for observation type ANYSFC,
over
> region FULL, for interpolation method DW_MEAN(4), using 0 pairs.
>
>
>
> ----------------------------------------
>
>
>
> Processing NBDSF/R21 versus DPT/Z2, for observation type ANYSFC,
over
> region FULL, for interpolation method DW_MEAN(4), using 0 pairs.
>
>
>
> ----------------------------------------
>
>
>
> Processing MSTAV/R32 versus WIND/Z10, for observation type ANYSFC,
> over region FULL, for interpolation method DW_MEAN(4), using 0
pairs.
>
>
>
> ----------------------------------------
>
>
--------------------------------------------------------------------------------------------------------------------------
>
>
>
> -----Oorspronkelijk bericht-----
> Van: Marlous Jonker
> Verzonden: woensdag 26 mei 2010 8:20
> Aan: Daniel van Dijke
> Onderwerp: FW: other models in MET point_stat
>
>
>
>
>
>
>
> -----Oorspronkelijk bericht-----
>
> Van: John Halley Gotway [mailto:johnhg at ucar.edu]
>
> Verzonden: dinsdag 25 mei 2010 17:25
>
> Aan: Marlous Jonker
>
> CC: met_help at mailman.ucar.edu
>
> Onderwerp: Re: other models in MET point_stat
>
>
>
> Marlous,
>
>
>
> The MET tools allow you to select different forecast and observation
> GRIB codes.  For example, here's an excerpt from the Grid-Stat
> configuration file:
>
>
>
> //
>
> // Specify a comma-separated list of fields to be verified.  The
> forecast and
>
> // observation fields may be specified separately.  If the obs_field
> parameter
>
> // is left blank, it will default to the contents of fcst_field.
>
> //
>
> // Each field is specified as a grib code or corresponding grib code
>
> // abbreviation followed by an accumulation or vertical level
> indicator.
>
> //
>
> // Each verification field is specified as one of the following:
>
> //    GC/ANNN for accumulation interval NNN
>
> //    GC/ZNNN for vertical level NNN
>
> //    GC/PNNN for pressure level NNN in hPa
>
> //    GC/PNNN-NNN for a range of pressure levels in hPa
>
> //    GC/LNNN for a generic level type
>
> //    GC/RNNN for a specific GRIB record number
>
> //    Where GC is the number of or abbreviation for the grib code
>
> //    to be verified.
>
> // http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
>
> //
>
> //    NOTE: To verify winds as vectors rather than scalars,
>
> //          specify UGRD (or 33) followd by VGRD (or 34) with the
>
> //          same level values.
>
> //
>
> //    NOTE: To process a probability field, add "/PROB", such as
> "POP/Z0/PROB".
>
> //
>
> // e.g. fcst_field[] = [ "61/A3", "APCP/A24", "RH/L10" ];
>
> //
>
> fcst_field[] = [ "61/A3" ];
>
> obs_field[]  = [];
>
>
>
> You'll notice separate setting for the forecast and observation
> fields.  If you treat WRF as the "forecast" and ECMWF as the
> "observation", you'd just list out the GRIB codes for each.  A word
of
>
> warning, MET doesn't do anything fancy with units.  For example, if
> you compare a temperature field in Celcius to a temperature field in
> Kelvin, it won't do any unit conversions for you.  It's your
>
> responsibility to make sure that the units are comparable and to
make
> sense of the verification output.
>
>
>
> Hope that helps.
>
>
>
> In the future, please send support questions directly to
> "met_help at ucar.edu".  We've set up a new tracking system for
handling
> support requests.
>
>
>
> Thanks,
>
> John
>
>
>
> Marlous Jonker wrote:
>
> > Hi John,
>
> >
>
> >
>
> >
>
> > After all your useful comments and help on MET point_stat, we
> managed to
>
> > set up an operational verification of WRF! Now we'd like to make a
>
> > comparison between WRF and the European ECMWF model.
>
> >
>
> > The output from ECMWF has a different grib ID. How can we let MET
>
> > understand that this grib has a different grib ID than WRF,
without
>
> > adapting the grib file itself to the WRF grib ID.
>
> >
>
> > The ECMWF and WRF verification is supposed to run after one
another,
> so
>
> > I hope there is a way to change the grib ID of MET in the command
> line.
>
> >
>
> >
>
> >
>
> > Cheers,
>
> >
>
> > Marlous
>
> >
>
> >
>
> >
>
> >
-------------------------------------------------------------------
>
> >
>
> >   Marlous Jonker
>
> >
>
> >   Meteorological Researcher
>
> >
>
> >   Meteo Consult BV, Wageningen, the Netherlands
>
> >
>
> >   Tel: +31 (0)317 399872
>
> >
>
> >   Email: M.Jonker at weer.nl
>
> >
>
> >   www: research.meteogroup.com
>
> >
>
> >
-------------------------------------------------------------------
>
> >
>
> >
>
> >
>
> >
>
> >
>
>
>



------------------------------------------------
Subject: FW: other models in MET point_stat
From: Daniel van Dijke
Time: Fri May 28 04:19:52 2010

Hi John,



Thanks for your answer. Originally the ECMWF data doesn't have
scanmode 64, but 0. Since it wasn't working, I started to play around
a bit.

Still with scanmode set to 0 it doesn't give me any pairs.

Here you can find a new set of data:



https://www.wetransfer.com/dl.php?code=Cv3CneD0&hash=2ded39f220c933fb40d4abc2b3e7736a2340c2893f503b42449d21052ade5a1e565925eb94041





Maybe you can give it another try?



Thanks in advanced!



Daniël



PS the wind was a known issue (didn't put it in my netcdf files yet,
now it should be there)





-----Oorspronkelijk bericht-----
Van: RAL HelpDesk {for John Halley Gotway} [mailto:met_help at ucar.edu]
Verzonden: donderdag 27 mei 2010 20:33
Aan: Daniel van Dijke
Onderwerp: [rt.rap.ucar.edu #38090] Resolved: FW: other models in MET
point_stat



According to our records, your request has been resolved. If you have
any

further questions or concerns, please respond to this message.



Previous message:



Daniel,



Thanks for sending that data.  It helped a lot in debugging this
issue.  When users ask the question "why am I getting 0 matched
pairs?", here's what we typically check:

(1) Do the observation locations fall within the forecast domain?

(2) Do the valid times of the observations fall within the
verification time window?

(3) Are the observation message types consistent with what's requested
in the config file?

(4) Are the observation variable types consistent with the what's
requested in the config file?

(5) Are the observation vertical levels consistent with the what's
requested in the config file?



In your case, the answer to all those questions is yes.



But after running it through the debugger, we found that the problem
lies in how the ECMWF GRIB file is packed.  In particular, the
"scan_mode" flag in the Grid Description Section is set wrong.  Here's
a table describing it:

http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html



In your file, it's set to 64, but based on how the data is packed, it
should be set to 0.  Your data is packed from north to south, but the
scan mode flag says to read it from south to north.



To fix this, you have 2 options:

(1) Update the GRIB file to change the scan mode flag from 64 to 0.

(2) Hard-code a fix for this to compensate for it in the MET code.



Of course, the first option is better, but here's how you'd do the
second:

- Open up the file "METv2.0/lib/vx_met_util/read_grib.cc"

- After line 999, add the following:

       // Daniël van Dijke (05/27/2010)

       // Hard-code ydir to be 0 to fix incorrect ECMWF scan mode
flag.

       ydir = 0;

- This addition should come just before this comment in the code:

       //

       // Multiply longitude values by -1 since the NCAR code
considers

       // degrees west to be positive.

       //

- In the top-level MET directory, do a "make clean" and then a "make"
to rebuild MET.

- Try rerunning your test data.



This will allow MET to work on your ECMWF data, but would break it for
any data that supposed to be indexed in the opposite direction.



Please also note that you will still not see any matched pairs when
verifying 10-meter wind speed.  And the reason for that is that there
are no observations of 10-meter wind speed in your observation file.



Hope that helps,

John Halley Gotway

met_help at ucar.edu





--

This e-mail is from Meteo Consult B.V., a MeteoGroup company. For more
information, see http://www.weer.nl/gebruiksvoorwaarden.

This e-mail may contain confidential information. Only the addressee
is permitted to read, copy, distribute or otherwise use this e-mail or
any attachments. If you have received it in error, please contact the
sender immediately. Any opinion expressed in this e-mail is personal
to the sender and may not reflect the opinion of MeteoGroup.

Any e-mail reply to this address may be subject to interception or
monitoring for operational reasons or for lawful business practices.

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38090] Resolved: FW: other models in MET point_stat
From: John Halley Gotway
Time: Fri May 28 11:51:15 2010

Daniel,

I reran the data you sent and am seeing a bunch of matched pairs being
computed.  I'm using the latest set of patches for METv2.0 (updated
last on 12/23/2009).  When I tried running with METv2.0 as
originally released, it actually seg-faulted!  So please be sure
you've updated to the latest set of patches, which can be found here:
   http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php

Just follow the instructions at the top of the page to apply the
patches.  I've also copied the output I'm seeing from Point-Stat for
your data below - just so you can see the numbers of matched pairs
I'm seeing.

And lastly, I'd highly recommend editing your config file as follows:
rank_corr_flag = 0;

It'll skip the computation of a couple of statistics, but you'll find
that it runs MUCH MUCH faster.  From 45 seconds down to 4 seconds on
my machine.

Hope that helps.

John

[johnhg at billiken]%
/d1/johnhg/MET/MET_releases/METv2.0_patch/bin/point_stat ecmwf.grb
obs_2010052706.nc PointStatConfig_ecmwf_25km_eu -outdir out -v 2
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=1526726732
Forecast File: ecmwf.grb
Climatology File: none
Configuration File: PointStatConfig_ecmwf_25km_eu
Observation File: obs_2010052706.nc

----------------------------------------

Reading records for VDDSF/R28.
For VDDSF/R28 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Reading records for NBDSF/R2.
For NBDSF/R2 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Reading records for MSTAV/R32.
For MSTAV/R32 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Searching 148858 observations from 18696 PrepBufr messages.

----------------------------------------

Processing VDDSF/R28 versus TMP/Z2, for observation type ANYSFC, over
region FULL, for interpolation method DW_MEAN(4), using 18642 pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Processing NBDSF/R2 versus DPT/Z2, for observation type ANYSFC, over
region FULL, for interpolation method DW_MEAN(4), using 18152 pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Processing MSTAV/R32 versus WIND/Z10, for observation type ANYSFC,
over region FULL, for interpolation method DW_MEAN(4), using 14069
pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Output file: out/point_stat_300000L_20100527_060000V.stat
Output file: out/point_stat_300000L_20100527_060000V_ctc.txt
Output file: out/point_stat_300000L_20100527_060000V_cts.txt
Output file: out/point_stat_300000L_20100527_060000V_cnt.txt
Output file: out/point_stat_300000L_20100527_060000V_sl1l2.txt
Output file: out/point_stat_300000L_20100527_060000V_vl1l2.txt


RAL HelpDesk {for Daniel van Dijke} wrote:
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38090 >
>
> Hi John,
>
>
>
> Thanks for your answer. Originally the ECMWF data doesn't have
scanmode 64, but 0. Since it wasn't working, I started to play around
a bit.
>
> Still with scanmode set to 0 it doesn't give me any pairs.
>
> Here you can find a new set of data:
>
>
>
>
https://www.wetransfer.com/dl.php?code=Cv3CneD0&hash=2ded39f220c933fb40d4abc2b3e7736a2340c2893f503b42449d21052ade5a1e565925eb94041
>
>
>
>
>
> Maybe you can give it another try?
>
>
>
> Thanks in advanced!
>
>
>
> Daniël
>
>
>
> PS the wind was a known issue (didn't put it in my netcdf files yet,
now it should be there)
>
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: RAL HelpDesk {for John Halley Gotway}
[mailto:met_help at ucar.edu]
> Verzonden: donderdag 27 mei 2010 20:33
> Aan: Daniel van Dijke
> Onderwerp: [rt.rap.ucar.edu #38090] Resolved: FW: other models in
MET point_stat
>
>
>
> According to our records, your request has been resolved. If you
have any
>
> further questions or concerns, please respond to this message.
>
>
>
> Previous message:
>
>
>
> Daniel,
>
>
>
> Thanks for sending that data.  It helped a lot in debugging this
issue.  When users ask the question "why am I getting 0 matched
pairs?", here's what we typically check:
>
> (1) Do the observation locations fall within the forecast domain?
>
> (2) Do the valid times of the observations fall within the
verification time window?
>
> (3) Are the observation message types consistent with what's
requested in the config file?
>
> (4) Are the observation variable types consistent with the what's
requested in the config file?
>
> (5) Are the observation vertical levels consistent with the what's
requested in the config file?
>
>
>
> In your case, the answer to all those questions is yes.
>
>
>
> But after running it through the debugger, we found that the problem
lies in how the ECMWF GRIB file is packed.  In particular, the
"scan_mode" flag in the Grid Description Section is set wrong.  Here's
a table describing it:
>
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html
>
>
>
> In your file, it's set to 64, but based on how the data is packed,
it should be set to 0.  Your data is packed from north to south, but
the scan mode flag says to read it from south to north.
>
>
>
> To fix this, you have 2 options:
>
> (1) Update the GRIB file to change the scan mode flag from 64 to 0.
>
> (2) Hard-code a fix for this to compensate for it in the MET code.
>
>
>
> Of course, the first option is better, but here's how you'd do the
second:
>
> - Open up the file "METv2.0/lib/vx_met_util/read_grib.cc"
>
> - After line 999, add the following:
>
>        // Daniël van Dijke (05/27/2010)
>
>        // Hard-code ydir to be 0 to fix incorrect ECMWF scan mode
flag.
>
>        ydir = 0;
>
> - This addition should come just before this comment in the code:
>
>        //
>
>        // Multiply longitude values by -1 since the NCAR code
considers
>
>        // degrees west to be positive.
>
>        //
>
> - In the top-level MET directory, do a "make clean" and then a
"make" to rebuild MET.
>
> - Try rerunning your test data.
>
>
>
> This will allow MET to work on your ECMWF data, but would break it
for any data that supposed to be indexed in the opposite direction.
>
>
>
> Please also note that you will still not see any matched pairs when
verifying 10-meter wind speed.  And the reason for that is that there
are no observations of 10-meter wind speed in your observation file.
>
>
>
> Hope that helps,
>
> John Halley Gotway
>
> met_help at ucar.edu
>
>
>
>
>

------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #38090] Resolved: FW: other models in MET point_stat
From: Daniel van Dijke
Time: Sun May 30 05:10:51 2010

Hi John,

It works! Thanks a lot for your effort.

Cheers,

Daniel

-----Oorspronkelijk bericht-----
Van: RAL HelpDesk {for John Halley Gotway} [mailto:met_help at ucar.edu]
Verzonden: vrijdag 28 mei 2010 19:51
Aan: Daniel van Dijke
Onderwerp: Re: [rt.rap.ucar.edu #38090] Resolved: FW: other models in
MET point_stat

Daniel,

I reran the data you sent and am seeing a bunch of matched pairs being
computed.  I'm using the latest set of patches for METv2.0 (updated
last on 12/23/2009).  When I tried running with METv2.0 as
originally released, it actually seg-faulted!  So please be sure
you've updated to the latest set of patches, which can be found here:
   http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php

Just follow the instructions at the top of the page to apply the
patches.  I've also copied the output I'm seeing from Point-Stat for
your data below - just so you can see the numbers of matched pairs
I'm seeing.

And lastly, I'd highly recommend editing your config file as follows:
rank_corr_flag = 0;

It'll skip the computation of a couple of statistics, but you'll find
that it runs MUCH MUCH faster.  From 45 seconds down to 4 seconds on
my machine.

Hope that helps.

John

[johnhg at billiken]%
/d1/johnhg/MET/MET_releases/METv2.0_patch/bin/point_stat ecmwf.grb
obs_2010052706.nc PointStatConfig_ecmwf_25km_eu -outdir out -v 2
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=1526726732
Forecast File: ecmwf.grb
Climatology File: none
Configuration File: PointStatConfig_ecmwf_25km_eu
Observation File: obs_2010052706.nc

----------------------------------------

Reading records for VDDSF/R28.
For VDDSF/R28 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Reading records for NBDSF/R2.
For NBDSF/R2 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Reading records for MSTAV/R32.
For MSTAV/R32 found 1 forecast levels and 0 climatology levels.

----------------------------------------

Searching 148858 observations from 18696 PrepBufr messages.

----------------------------------------

Processing VDDSF/R28 versus TMP/Z2, for observation type ANYSFC, over
region FULL, for interpolation method DW_MEAN(4), using 18642 pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Processing NBDSF/R2 versus DPT/Z2, for observation type ANYSFC, over
region FULL, for interpolation method DW_MEAN(4), using 18152 pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Processing MSTAV/R32 versus WIND/Z10, for observation type ANYSFC,
over region FULL, for interpolation method DW_MEAN(4), using 14069
pairs.
Computing Categorical Statistics.
Computing Continuous Statistics.
Computing Scalar Partial Sums.

----------------------------------------

Output file: out/point_stat_300000L_20100527_060000V.stat
Output file: out/point_stat_300000L_20100527_060000V_ctc.txt
Output file: out/point_stat_300000L_20100527_060000V_cts.txt
Output file: out/point_stat_300000L_20100527_060000V_cnt.txt
Output file: out/point_stat_300000L_20100527_060000V_sl1l2.txt
Output file: out/point_stat_300000L_20100527_060000V_vl1l2.txt


RAL HelpDesk {for Daniel van Dijke} wrote:
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38090 >
>
> Hi John,
>
>
>
> Thanks for your answer. Originally the ECMWF data doesn't have
scanmode 64, but 0. Since it wasn't working, I started to play around
a bit.
>
> Still with scanmode set to 0 it doesn't give me any pairs.
>
> Here you can find a new set of data:
>
>
>
>
https://www.wetransfer.com/dl.php?code=Cv3CneD0&hash=2ded39f220c933fb40d4abc2b3e7736a2340c2893f503b42449d21052ade5a1e565925eb94041
>
>
>
>
>
> Maybe you can give it another try?
>
>
>
> Thanks in advanced!
>
>
>
> Daniël
>
>
>
> PS the wind was a known issue (didn't put it in my netcdf files yet,
now it should be there)
>
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: RAL HelpDesk {for John Halley Gotway}
[mailto:met_help at ucar.edu]
> Verzonden: donderdag 27 mei 2010 20:33
> Aan: Daniel van Dijke
> Onderwerp: [rt.rap.ucar.edu #38090] Resolved: FW: other models in
MET point_stat
>
>
>
> According to our records, your request has been resolved. If you
have any
>
> further questions or concerns, please respond to this message.
>
>
>
> Previous message:
>
>
>
> Daniel,
>
>
>
> Thanks for sending that data.  It helped a lot in debugging this
issue.  When users ask the question "why am I getting 0 matched
pairs?", here's what we typically check:
>
> (1) Do the observation locations fall within the forecast domain?
>
> (2) Do the valid times of the observations fall within the
verification time window?
>
> (3) Are the observation message types consistent with what's
requested in the config file?
>
> (4) Are the observation variable types consistent with the what's
requested in the config file?
>
> (5) Are the observation vertical levels consistent with the what's
requested in the config file?
>
>
>
> In your case, the answer to all those questions is yes.
>
>
>
> But after running it through the debugger, we found that the problem
lies in how the ECMWF GRIB file is packed.  In particular, the
"scan_mode" flag in the Grid Description Section is set wrong.  Here's
a table describing it:
>
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html
>
>
>
> In your file, it's set to 64, but based on how the data is packed,
it should be set to 0.  Your data is packed from north to south, but
the scan mode flag says to read it from south to north.
>
>
>
> To fix this, you have 2 options:
>
> (1) Update the GRIB file to change the scan mode flag from 64 to 0.
>
> (2) Hard-code a fix for this to compensate for it in the MET code.
>
>
>
> Of course, the first option is better, but here's how you'd do the
second:
>
> - Open up the file "METv2.0/lib/vx_met_util/read_grib.cc"
>
> - After line 999, add the following:
>
>        // Daniël van Dijke (05/27/2010)
>
>        // Hard-code ydir to be 0 to fix incorrect ECMWF scan mode
flag.
>
>        ydir = 0;
>
> - This addition should come just before this comment in the code:
>
>        //
>
>        // Multiply longitude values by -1 since the NCAR code
considers
>
>        // degrees west to be positive.
>
>        //
>
> - In the top-level MET directory, do a "make clean" and then a
"make" to rebuild MET.
>
> - Try rerunning your test data.
>
>
>
> This will allow MET to work on your ECMWF data, but would break it
for any data that supposed to be indexed in the opposite direction.
>
>
>
> Please also note that you will still not see any matched pairs when
verifying 10-meter wind speed.  And the reason for that is that there
are no observations of 10-meter wind speed in your observation file.
>
>
>
> Hope that helps,
>
> John Halley Gotway
>
> met_help at ucar.edu
>
>
>
>
>



--

This e-mail is from Meteo Consult B.V., a MeteoGroup company. For more
information, see http://www.weer.nl/gebruiksvoorwaarden.

This e-mail may contain confidential information. Only the addressee
is permitted to read, copy, distribute or otherwise use this e-mail or
any attachments. If you have received it in error, please contact the
sender immediately. Any opinion expressed in this e-mail is personal
to the sender and may not reflect the opinion of MeteoGroup.

Any e-mail reply to this address may be subject to interception or
monitoring for operational reasons or for lawful business practices.

------------------------------------------------


More information about the Met_help mailing list