[Met_help] MET compilation error
John Halley Gotway
johnhg at rap.ucar.edu
Mon Aug 17 14:37:20 MDT 2009
Holly,
We do offer a 2 day training for MET here at NCAR as part of the
WRF-Tutorial. Here's our webpage about it... although I see that the info
is out of date right now!
http://www.dtcenter.org/met/users/support/tutorial.php
These tutorials occur twice each year, in July and January. The next one
will be January 2010.
And we do post the slides from the tutorials. However, I see again that
we haven't done that yet for the July 2009 tutorial. Here's where we'll
be posting them:
http://www.dtcenter.org/met/users/docs/overview.php
Hope that helps. We'd love to have you join us in January if that works
for you.
Thanks,
John
> Phew! That worked. Thanks so much, John. I'll pay close attention to
> that from here on out now that I know that's the culprit.
>
> By the way, I have an interesting proposition for the MET group [please
> let me know if you're the wrong person to ask about this]. I have some
> travel credits that need to be used before November of this year. If I
> were to come to Boulder sometime, would there be anybody there willing
> to sit down with me for a couple days for some MET software training?
> Our company is about to embark on a rather large and significant project
> that will be using MET rather extensively. As such, it would be very
> beneficial for me to know the program as well as I can.
>
> Have you all done anything like this before, or would you be open to the
> idea? I noticed you have a workshop at the end of this month, but it
> doesn't seem like it's focused on actual MET training.
>
> My sincere thanks,
> 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: Monday, August 17, 2009 1:55 PM
> To: Holly Hassenzahl
> Cc: Brian Good; met_help
> Subject: Re: [Met_help] MET compilation error
>
> 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