[Met_help] MET compilation error
John Halley Gotway
johnhg at rap.ucar.edu
Mon Aug 17 12:55:18 MDT 2009
Holly,
Ah... ok, I understand better now.
There are two things you need to be sure to do...
First (you're already doing this), be sure to verify against the ADPSFC observations, which are surface obs. You should use this message type for verifying forecasts at the surface.
Second (and I think this is the problem), I'm guessing the verification time window isn't big enough to capture any observations. Each forecast you verify is valid a some particular time, call it t.
In the PointStatConfig file you can set a time window to determine which observations are being compared to the forecast. You set this relative to the forecast valid time, t. The valid time window
is defined as [t + beg_ds, t + end_ds]. In the default config file "beg_ds = -5400" and "end_ds = 5400" seconds... so that's +/- 90 minutes. You can also set the valid time window on the command
line using the "-valid_beg" and "-valid_end" command line options - these override the beg_ds and end_ds settings.
Try running you're Point-Stat command but open it up to a huge matching time window... something like "-valid_beg 20010101 -valid_end 20100101" - anytime between 2001 and 2010. Then check to see if
you have matching observations. It's your job to make sure that your forecast times match up well with your observation times. And it's up to you to decide what time window to use.
Just so you know, when you run the file conus.2009081312.grib file through Point-Stat, the first record of temperature at the surface is a 66 hour forecast. So that's what MET is using. The valid
time for that record is really 2009081606 (If I added right). That's probably the source of the confusion.
John
Holly Hassenzahl wrote:
> Hi John-
>
> Thank you so much for looking into this for me. I tried using your PointStatConfig_TMP file, but am still having the same issue. It doesn't give me any errors saying it can't read the grib file, it just can't match any pairs to compute stats:
>
> Processing TMP/Z0 versus TMP/Z0, for observation type ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using 0 pairs.
>
> Thus, all of my output files are empty except for the headers. Are you actually getting output stats when you run it? If so, then it's probably not an issue with the config file. Unless maybe it's my prepbufr output? I will put my prepbufr output (test_pb.nc) up on the ftp site. The PointStatConfig file I was using last week is also on the ftp site now.
>
> We have yet to install the copygb utility, but that is good to know there is syntax for extracting a forecast lead time. I was wondering about. A frcst_lead variable would be an excellent thing to have in the next MET version.
>
> Thanks again for all of your help. We really appreciate it over here. We'll get to the bottom of all this soon!
>
> 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
>
>
>
> -----Original Message-----
> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
> Sent: Mon 8/17/2009 10:11 AM
> To: Holly Hassenzahl; met_help
> Subject: Re: [Met_help] MET compilation error
>
> 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
>>>>>>
>
>
More information about the Met_help
mailing list