[Met_help] MET compilation error
John Halley Gotway
johnhg at rap.ucar.edu
Mon Aug 17 09:11:23 MDT 2009
Holly,
Good news and bad news.
The good news is that when I run your datafile through the MET tools (Point-Stat and MODE specifically), I'm not seeing the problem you're seeing. The tools are able to read the file without any
problem. I'm using "TMP/Z0". I've attached the PointStatConfig_TMP file I used for your reference. I didn't see the PointStatConfig file you mentioned in your last email - perhaps you forgot to
send it. I'm guessing there's just some minor problem in your config file.
However, the bad news is the way the data is stored in the GRIB file you sent. It contains 36 records for TMP at the surface that correspond to 36 different lead times. The problem is that when you
tell MET to look for "TMP/Z0" in that file, it just uses the first record it finds, regardless of lead time. So you're only able to access the first such record!
The output of the WRF model, for which MET was initially designed, places output for each forecast lead time into a separate output file - so this wasn't an issue. But this is the second time this
issue has come up, so we'll need to add the capability of selecting out a specific lead time to a future version of MET. Perhaps we could add a "-fcst_lead" command line argument.
In the meantime, there is a work-around you could try. You could use the "copygb" utility to extract out the lead time you'd like to verify to a separate file, and then use that as input to MET. For
example, the following command will extract out only the records containing 96 hour forecasts:
copygb -xk'13*-1 96' conus.2009081312.grib conus.2009081312_96L.grib
So if you want to verify a 96 hour forecast, you could run this command and then use the file "conus.2009081312_96L.grib" as input to MET. The arguments for copygb are a bit cryptic but I've attached
the file "copygb.doc" which gives info about the arguments.
Thanks,
John
Holly Hassenzahl wrote:
> Hi John-
>
> Thanks for your advice. I tried using TMP/L0 and MET did not like that
> either. Kpds7 does in fact equal 0, so I was really hoping that would
> work! Oh well.
>
> I have loaded the grib file (conus.2009081312.grib) that I have been
> trying to use. I also loaded the PointStatConfig file that I've been
> using in case you want to take a look at that.
>
> Please let me know if I can upload anything else for you that might be
> useful.
>
> Thanks again for help!
> Holly
>
> ___________________________________
> Holly C. Hassenzahl
> Meteorologist, Science Analyst
> Data Products Group
>
> Weather Central, Inc.
> 401 Charmany Drive Suite 200
> Madison, WI 53711
> +1.608.274.5789
> +1.608.276.4600
> http://www.weathercentral.tv
>
>
> -----Original Message-----
> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
> Sent: Friday, August 14, 2009 1:09 PM
> To: Holly Hassenzahl; met_help
> Subject: Re: [Met_help] MET compilation error
>
> Holly,
>
> Try using "TMP/L0" in the config file and see if that works.
>
> Do you have the "wgrib" utility on your machine? If so, try running
> that NDFD GRIB1 file through wgrib and look at the values listed for
> "kpds7=". I believe that's where the level value is stored
> that MET's looking for. By saying "TMP/L0", you're saying that you want
> temperature with a level value of 0 (i.e. kpds7=0), and you don't care
> what "type" of level it is... height level, pressure
> level, etc...
>
> If you still can't get it to work, just send me one of the GRIB1 files,
> and I'll take a crack at it. You could post it to our anonymous ftp
> site:
> ftp ftp.rap.ucar.edu
> username = anonymous
> password = "your email address"
> mkdir incoming/irap/met_help/hassenzahl_data
> cd incoming/irap/met_help/hassenzahl_data
> put "your data file"
> bye
>
> Thanks,
> John
>
>
> Holly Hassenzahl wrote:
>> Hello again, John-
>>
>> Do you know if anyone has ever tried using MET to do obs verifications
>> with NDFD? We are hoping to run surface temp verifications with NDFD,
>> but are encountering an issue.
>>
>> We've converted NDFD from grib2 to grib1. However, the level of the
>> NDFD temps is given as "sfc" instead of a number value, like 0 or 2m.
>> As such, we are suspecting that MET cannot locate pairs to run
>> computations on since nothing we enter in fcst_field makes sense.
> We've
>> tried TMP/Lsfc, TMP/Z0, TMP/Z2, etc.
>>
>> Do you have any ideas or suggestions of what might work? Thanks so
>> much.
>> Holly
>>
>> ___________________________________
>> Holly C. Hassenzahl
>> Meteorologist, Science Analyst
>> Data Products Group
>>
>> Weather Central, Inc.
>> 401 Charmany Drive Suite 200
>> Madison, WI 53711
>> +1.608.274.5789
>> +1.608.276.4600
>> http://www.weathercentral.tv
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>> Sent: Thursday, August 13, 2009 1:54 PM
>> To: Holly Hassenzahl
>> Cc: met_help at ucar.edu
>> Subject: RE: [Met_help] MET compilation error
>>
>> Holly,
>>
>> Great. I'm glad you were able to figure it out. That's interesting
>> that
>> your "g++" compiler for version 4.1.2 is actually named "g++4".
>> Everybody's systems are a little different.
>>
>> Let me make a couple of recommendations...
>> - I'd suggest retrieving the latest set of patches for METv2.0 from:
>>
> http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php
>> You'll just need to download one tar file and then recompile MET.
>>
>> - You may find it helpful to go through the MET online tutorial:
>>
> http://www.dtcenter.org/met/users/support/online_tutorial/METv2.0/index.
>> php
>>
>> If you have any questions in your use of MET, just let us know.
>>
>> Thanks,
>> John
>>
>>> Thanks for your help, John. I was using two different versions of
> gcc
>>> and gfortran. It was like this because gfortran had not been
>> installed
>>> on my computer. I installed a recent version yesterday, but my gcc
>>> version was only at 3.2.3. Turns out that gcc 3.2.3 has issues with
>>> gfortran.
>>>
>>> I switched to a different Linux box that was using Red Hat 4, and had
>>> both gcc 4.1.2 and gfortran 4.1.2 installed. All of the utilities
>>> compiled perfectly, but then we got an error when trying to compile
>> MET.
>>> It kept telling us that -lgfortran could not be found. I added the
>>> "-L/path/to/gcc/directory -lgcc" line to FC_LIBS and still got the
>> same
>>> error. However, we had the CXX line set to use g++. When this was
>>> changed to g++4, everything worked.
>>>
>>> Phew!
>>> Thanks again for your prompt replies and all of your help.
>>>
>>> Holly
>>>
>>> ___________________________________
>>> Holly C. Hassenzahl
>>> Meteorologist, Science Analyst
>>> Data Products Group
>>>
>>> Weather Central, Inc.
>>> 401 Charmany Drive Suite 200
>>> Madison, WI 53711
>>> +1.608.274.5789
>>> +1.608.276.4600
>>> http://www.weathercentral.tv
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>> Sent: Wednesday, August 12, 2009 9:29 AM
>>> To: Holly Hassenzahl
>>> Cc: met_help
>>> Subject: Re: [Met_help] MET compilation error
>>>
>>> Holly,
>>>
>>> I notice in the error message you sent me that you had to specify in
>> the
>>> Makefile where to find the gfortran library
> (-L/usr/local/gfortran/lib
>>> -lgfortran). That leads me to believe that it's not in
>>> a standard location that the gfortran compiler already knows about.
>>>
>>> Try checking the version numbers of the compilers you're using by
>> typing
>>> the following:
>>> g++ --version
>>> gfortran --version
>>>
>>> Do the version numbers match? If not, that's a problem.
>>>
>>> Regarding the specific error message you're seeing, the "__powidf2"
>>> function is defined on my machine in the "gcc" library file. On my
>>> machine that's in "/usr/lib/gcc/i486-linux-gnu/4.1.2/libgcc.a"
>>> but my that's a standard location and the gfortran compiler knows
>> where
>>> to find the GCC library. However, since your gfortran library is not
>> in
>>> a location that the gfortran compiler already knows
>>> about, I'm guessing the same is true of the GCC library... leading to
>>> the error you're seeing.
>>>
>>> If the compiler version numbers do match above, you could try this
>> next:
>>> - Locate the file "libgcc.a" on your system.
>>> - Then in the Makefile, after "-L/usr/local/gfortran/lib -lgfortran"
>> add
>>> the following "-L/path/to/gcc/directory -lgcc"
>>> - Try rebuilding MET.
>>>
>>> Let me know how it goes.
>>>
>>> Thanks,
>>> John
>>>
>>> Holly Hassenzahl wrote:
>>>> Hi John-
>>>>
>>>> Thanks for your quick reply. Unfortunately, I had already compiled
>>>> BUFRLIB as you suggested. So these errors have been occurring,
>>>> regardless of using the "-fno-second-underscore" tag.
>>>>
>>>> Holly
>>>>
>>>> ___________________________________
>>>> Holly C. Hassenzahl
>>>> Meteorologist, Science Analyst
>>>> Data Products Group
>>>>
>>>> Weather Central, Inc.
>>>> 401 Charmany Drive Suite 200
>>>> Madison, WI 53711
>>>> +1.608.274.5789
>>>> +1.608.276.4600
>>>> http://www.weathercentral.tv
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>> Sent: Tuesday, August 11, 2009 4:51 PM
>>>> To: Holly Hassenzahl
>>>> Cc: met_help at ucar.edu
>>>> Subject: Re: [Met_help] MET compilation error
>>>>
>>>> Holly,
>>>>
>>>> I believe this error has to do with how you compiled BUFRLIB.
> Please
>>>> take
>>>> a look at the sample commands for compiling BUFRLIB on this page:
>>>>
> http://www.dtcenter.org/met/users/support/online_tutorial/METv2.0/compil
>>>> ation/req_libs.php
>>>>
>>>> Try compiling BUFRLIB with the following commands:
>>>> gcc -c -DUNDERSCORE *.c
>>>> gfortran -c -DUNDERSCORE -fno-second-underscore *.f *.F
>>>> ar crv libbufr.a *.o
>>>>
>>>> I think that "-fno-second-underscore" will fix the error you're
>>> seeing.
>>>> Hope that does the trick.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> johnhg at ucar.edu
>>>>
>>>>> Hello-
>>>>>
>>>>> I am trying to compile MET 2.0 using GNU compilers and am getting
>> the
>>>>> following errors when making the pb2nc application:
>>>>>
>>>>> /usr/bin/g++ -o pb2nc pb2nc.cc pb2nc_Conf.o numpbmsg.o openpb.o
>>>> readpb.o
>>>>> dumppb.o \
>>>>> -Wall -Wshadow -static -DMET_BASE=\"/home/ldm/METv2.0\" \
>>>>> -I../../lib -I/home/ldm/NETCDF/netcdf-3.6.3/include
>>>>> -I/home/ldm/GSL/gsl-1.12/include -I/home/ldm/BUFRLIB \
>>>>> -L../../lib -L/home/ldm/NETCDF/netcdf-3.6.3/lib
>>>>> -L/home/ldm/GSL/gsl-1.12/lib -L/home/ldm/BUFRLIB \
>>>>> -lbufr -lvx_pb_util \
>>>>> -lvx_met_util -lvx_analysis_util -lvx_wrfdata -lvx_met_util \
>>>>> -lvx_contable -lvx_grib_classes \
>>>>> -lvx_econfig -lvx_gsl_prob -lgsl \
>>>>> -lvx_plot_util -lvx_render -lvx_pxm -lvx_color -lvx_ps -lvx_afm \
>>>>> -lvx_data_grids -lvx_gnomon -lvx_nav -lvx_cal -lvx_util -lvx_math
>> -lm
>>>> \
>>>>> -lnetcdf_c++ -lnetcdf \
>>>>> -L/usr/local/gfortran/lib -lgfortran
>>>>> /home/ldm/BUFRLIB/libbufr.a(ufbtab.o)(.text+0x731): In function
>>>> `ufbtab_':
>>>>> : undefined reference to `__powidf2'
>>>>> /home/ldm/BUFRLIB/libbufr.a(ufbtab.o)(.text+0xf29): In function
>>>> `ufbtab_':
>>>>> : undefined reference to `__powidf2'
>>>>> /home/ldm/BUFRLIB/libbufr.a(rdcmps.o)(.text+0x294): In function
>>>> `rdcmps_':
>>>>> : undefined reference to `__powidf2'
>>>>> /home/ldm/BUFRLIB/libbufr.a(rdtree.o)(.text+0x1fd): In function
>>>> `rdtree_':
>>>>> : undefined reference to `__powidf2'
>>>>> collect2: ld returned 1 exit status
>>>>> make[3]: *** [pb2nc] Error 1
>>>>> make[2]: *** [all] Error 2
>>>>> make[1]: *** [targets] Error 2
>>>>> make: *** [all] Error 2
>>>>>
>>>>> I have tried emptying out all of the F2C lines in the Makefile, as
>>>> well as
>>>>> emptying out all expect the -lf2c (as recommended to someone in
>> April
>>>> of
>>>>> this year).
>>>>>
>>>>> Is there something else I am missing or could try? Thank you...
>>>>>
>>>>> Holly
>>>>>
>>>>> -----------------------------------------------
>>>>> Holly Hassenzahl
>>>>> Meteorologist, Science Analyst
>>>>> Data Products Group
>>>>>
>>>>> Weather Central, Inc.
>>>>> 401 Charmany Drive Suite 200
>>>>> Madison, WI 53719
>>>>> 608.274.5789
>>>>> http://weathercentral.tv
>>>>>
>>>>> _______________________________________________
>>>>> Met_help mailing list
>>>>> Met_help at mailman.ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/met_help
>>>>>
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PointStatConfig_TMP
Url: http://mailman.ucar.edu/pipermail/met_help/attachments/20090817/95cad6ed/attachment-0001.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copygb.doc
Type: application/msword
Size: 11205 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/met_help/attachments/20090817/95cad6ed/attachment-0001.doc
More information about the Met_help
mailing list