[Met_help] MET compilation error
John Halley Gotway
johnhg at rap.ucar.edu
Mon Aug 17 16:15:31 MDT 2009
Holly,
I talked to some folks here about the idea, but I don't think it'd work
out. We're awfully busy and have a tough time even setting aside the time
to prepare and conduct the 2 tutorials per year.
To learn more about MET, I'd suggest...
(1) Reading the user's guide.
(2) Going through the MET Online Tutorial.
(3) Reviewing the slides from the recent MET Tutorial.
(4) You could even go through the exercises from the recent MET Tutorial.
They can be found here:
http://www.dtcenter.org/met/users/support/OnLinePractical
If you have any questions in your use of MET, we're happy to answer them
through MET-Help. And you're more than welcome to head out here in
January 2010 for more practice.
Thanks,
John
> John,
>
> Thanks for getting back to me. I would love to attend the MET training
> in January. However my airline credits expire in November, so we were
> hoping to make something happen before then. Any chance you'd accept a
> lone straggler a couple months early? I know that's a lot to ask of you
> all, so we'd completely understand if it's not possible. But I had to
> ask!
>
> 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 3:37 PM
> To: Holly Hassenzahl
> Cc: met_help at ucar.edu
> Subject: RE: [Met_help] MET compilation error
>
> 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