[Fwd: Re: [Met_help] Several questions about MET]

[John Halley Gotway]

I forgot to copy met_help in the reply.

John

-------- Original Message --------
Subject: Re: [Met_help] Several questions about MET
Date: Fri, 20 Jun 2008 09:14:09 -0600
From: John Halley Gotway <johnhg at rap.ucar.edu>
To: Jan Ploski <Jan.Ploski at offis.de>
References: <OFA7AFFE3F.44F28A83-ONC125746D.004DC55C-C125746D.004DD95E at offis.uni-oldenburg.de> <485A911F.9050703 at rap.ucar.edu> <485A9EF5.4010601 at offis.de> <485ABF60.5020904 at rap.ucar.edu> 
<485AC933.3050109 at offis.de>

Jan,

(1) You're right, that's a bug.  It's listed on the MET known problems page (http://www.dtcenter.org/met/users/support/known_issues/METv1.0/index.php).  Glad you were able to fix it yourself though.

(3) Regarding the use of "autoconf", I completely agree.  That's on our list of things to do, but we just haven't gotten it done yet.

(4) METv1.0 is a relatively new package that does contain some bugs.  The next release, METv1.1, fixes all of the bugs we're currently aware of.  NCAR hasn't begun using MET in a "production
environment" to my knowledge.  I would caution against using METv1.0 in an operational setting as the sole source of verification results.  Instead, I'd recommend using the tools in more of an
evaluation mode for a time until you get more comfortable with the results you're seeing.

The "test_all" script simply calls each one of the MET tools a handful of times to ensure that there are no obvious runtime errors.  It is not an attempt to test out every feature of MET.

However, as long as the test scripts run OK and the output looks reasonable, I'd be pretty confident that your version of MET is working as expected.

(2) Regarding the BUFRLIB issue you're seeing, this means that you need to use the "cwordsh" utility to reblock the PrepBufr file AND/OR that you're trying to run MET on a 64-bit machine.

Since I believe you're machine is 64-bit, let me point you to a write-up I posted to the MET website last week:
http://www.dtcenter.org/met/users/support/known_issues/METv1.0/met_64_bit.php
The BUFRLIB issues are certainly inconvenient.  We hope to make it easier to use in the future.

John


Jan Ploski wrote:
> John Halley Gotway wrote:
>> Jan,
>>
>> I have a guess as to what's going wrong.  Please replace your version 
>> of "METv1.0/src/grid_stat.cc" with the version that's attached to this 
>> email.  Then do a "make clean" and rebuild MET.
>>
>> Please let me know if this fixes the problem you're seeing.  This is a 
>> bug of sorts that we've fixed for METv1.1.  It only shows up on 
>> certain machines and compilers.  But we were doing some "risky" things 
>> in the code with strings that we shouldn't have been doing.  If you 
>> run into this error from other MET tools, let me know, and I'll patch 
>> it up for you.  And as I mentioned, it'll be fixed in METv1.1.
> 
> John,
> 
> The replacement grid_stat.cc you provided fixed my reported "illegal 
> characters" problem - thanks!
> 
> I have a few more remarks/questions:
> 
> 1) During the compilation I got (now and previously) the following 
> error, which was easily fixed by an edit to include $(NETCDF_INCS) in 
> the Makefile for vx_met_util:
> 
> pgCC read_grib.cc -g -Bstatic  -c -I.. -I/opt/gsl-1.11/include
> read_grib.cc:
> "../vx_met_util/read_pcp_combine_netcdf.h", line 16: catastrophic error: 
> could
>           not open source file "netcdf.hh"
>   #include "netcdf.hh"
> 
> 2) In test_all.log I see the following errors (probably related to each 
> other?)
> 
>  **************BUFR ARCHIVE LIBRARY ABORT*****************
>  BUFRLIB: OPENBF - ERROR READING INPUT FILE CONNECTED TO UNIT  11 WHEN 
> CHECKING FOR 'BUFR' IN FIRST 4 BYTES OF RECORD
>  **************BUFR ARCHIVE LIBRARY ABORT*****************
> 
> *** Testing POINT_STAT application ***
> 
> 
> *** Running POINT_STAT on sample NAM data ***
> Forecast File: 
> ../data/sample_fcst/2007033000/nam.t00z.awip1236.tm00.20070330.grb
> Observation File: ../out/pb2nc/sample_pb.nc
> Configuration File: config/PointStatConfig
> Climatology File: none
> 
> 
> ERROR: process_obs_file() -> can't open observation netCDF file: 
> ../out/pb2nc/sample_pb.nc
> 
> 3) Why do you not use GNU autoconf for managing the build? I guess this 
> question is relevant not just to MET, but also to other NCAR projects. 
> In any case, ./configure; make; make test; make install would be a very 
> welcome procedure from the user's (or IT support guy's) perspective...
> 
> 4) How reliable and bug-free is METv1.0? This question can be split into 
> two parts:
> - has METv1.0 been tested extensively in the production environment at 
> NCAR?
> - can we assume that if test_all.sh runs correctly on our machine we 
> have a build "just as good" as the one that you use in your production 
> environment? (i.e., is the test coverage sufficient to be confident 
> about this match)
> 
> Of course, we are going to do some manual testing ourselves next (the 
> goal is to replace our own rather simple verification codes with MET), 
> but we'd like to know just how careful we have to be.
> 
> Regards,
> Jan Ploski