[Met_help] [rt.rap.ucar.edu #65124] History for yellowstone compilation
John Halley Gotway via RT
met_help at ucar.edu
Tue Feb 18 11:59:27 MST 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Trying to compile MET-TC on NCAR's supercomputer yellowstone but getting
compilation errors. They occur before the tropical cyclone section
(TC_UTILS) is compiled.
I managed to hack my way past some initial errors:
avoided the isatty() function by commenting out some lines.
fixed the GSL base directory by taking out the /gsl part of the path
(probably a CISL module problem when module load gsl is loaded)
but now I am stuck. It happens on ensemble_stat:
icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
-Wshadow -static -DBLOCK4
-DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
-I/glade/p/work/ahijevyc/METv4.1/include
-I/glade/apps/opt/netcdf/4.2/intel/default/include
-I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
-I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
-I/glade/apps/el6/include -I/glade/apps/el6/usr/include
-I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
-I/glade/apps/opt/netcdf/4.2/intel/default/include \
-L/glade/p/work/ahijevyc/METv4.1/lib
-L/glade/apps/opt/netcdf/4.2/intel/default/lib
-L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
-Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
-Wl,-rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
-Wl,-rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
-L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
-Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-rpath,/glade/apps/el6/usr/lib64
-L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
-lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
-Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
-L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4 -lnetcdff
-lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
-lvx_stat_out \
-lvx_statistics \
-lvx_shapedata \
-lvx_gsl_prob \
-lvx_analysis_util \
-lvx_data2d_factory \
-lvx_data2d_nc_met \
-lvx_data2d_grib \
-lvx_data2d_nc_pinterp \
-lvx_data2d_nccf \
-lvx_data2d \
-lvx_nc_util \
-lvx_grid \
-lvx_config \
-lvx_cal \
-lvx_util \
-lvx_math \
-lvx_color \
-lvx_log \
-lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
function `H5PL_load':
H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchhttpcode':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
undefined reference to `curl_easy_getinfo'
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchurl_file':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
undefined reference to `curl_easy_perform'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
undefined reference to `curl_easy_getinfo'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
undefined reference to `curl_easy_strerror'
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchlastmodified':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
undefined reference to `curl_easy_setopt'
...more errors follow
It seems to be related to the curl library and suggests netcdf needs it,
but I want to avoid compiling netcdf and just use the supercomputer
version.
I found this helpful email reference to compiled MET on yellowstone, but
I couldn't find any tc_utils in
/glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the email, it
seemed the compilation was not working recently.
http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
Dave
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Tue Jan 28 11:08:03 2014
Hi Dave,
I'm looking into and will let you know when I've made progress. I'd
seen that "isatty()" problem, but hadn't had a chance to address it
yet.
Thanks,
John
On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>
> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
> Transaction: Ticket created by ahijevyc
> Queue: met_help
> Subject: yellowstone compilation
> Owner: Nobody
> Requestors: ahijevyc at ucar.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
>
> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
> compilation errors. They occur before the tropical cyclone section
> (TC_UTILS) is compiled.
>
> I managed to hack my way past some initial errors:
> avoided the isatty() function by commenting out some lines.
> fixed the GSL base directory by taking out the /gsl part of the
path
> (probably a CISL module problem when module load gsl is loaded)
>
> but now I am stuck. It happens on ensemble_stat:
>
>
> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
> -Wshadow -static -DBLOCK4
> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
> -I/glade/p/work/ahijevyc/METv4.1/include
> -I/glade/apps/opt/netcdf/4.2/intel/default/include
> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
> -L/glade/p/work/ahijevyc/METv4.1/lib
> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
> -lvx_stat_out \
> -lvx_statistics \
> -lvx_shapedata \
> -lvx_gsl_prob \
> -lvx_analysis_util \
> -lvx_data2d_factory \
> -lvx_data2d_nc_met \
> -lvx_data2d_grib \
> -lvx_data2d_nc_pinterp \
> -lvx_data2d_nccf \
> -lvx_data2d \
> -lvx_nc_util \
> -lvx_grid \
> -lvx_config \
> -lvx_cal \
> -lvx_util \
> -lvx_math \
> -lvx_color \
> -lvx_log \
> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>
> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
> function `H5PL_load':
> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
> applications requires at runtime the shared libraries from the glibc
> version used for linking
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchhttpcode':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
> undefined reference to `curl_easy_getinfo'
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchurl_file':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
> undefined reference to `curl_easy_perform'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
> undefined reference to `curl_easy_getinfo'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
> undefined reference to `curl_easy_strerror'
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchlastmodified':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
> undefined reference to `curl_easy_setopt'
> ...more errors follow
>
>
> It seems to be related to the curl library and suggests netcdf needs
it,
> but I want to avoid compiling netcdf and just use the supercomputer
> version.
>
> I found this helpful email reference to compiled MET on yellowstone,
but
> I couldn't find any tc_utils in
> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
> seemed the compilation was not working recently.
> http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
>
> Dave
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Tue Jan 28 11:11:03 2014
OKay - thanks!
On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
> Hi Dave,
>
> I'm looking into and will let you know when I've made progress. I'd
seen that "isatty()" problem, but hadn't had a chance to address it
yet.
>
> Thanks,
> John
>
>
> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>> Transaction: Ticket created by ahijevyc
>> Queue: met_help
>> Subject: yellowstone compilation
>> Owner: Nobody
>> Requestors: ahijevyc at ucar.edu
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>>
>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>> compilation errors. They occur before the tropical cyclone section
>> (TC_UTILS) is compiled.
>>
>> I managed to hack my way past some initial errors:
>> avoided the isatty() function by commenting out some lines.
>> fixed the GSL base directory by taking out the /gsl part of the
path
>> (probably a CISL module problem when module load gsl is loaded)
>>
>> but now I am stuck. It happens on ensemble_stat:
>>
>>
>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>> -Wshadow -static -DBLOCK4
>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>> -I/glade/p/work/ahijevyc/METv4.1/include
>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>> -L/glade/p/work/ahijevyc/METv4.1/lib
>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
>> -lvx_stat_out \
>> -lvx_statistics \
>> -lvx_shapedata \
>> -lvx_gsl_prob \
>> -lvx_analysis_util \
>> -lvx_data2d_factory \
>> -lvx_data2d_nc_met \
>> -lvx_data2d_grib \
>> -lvx_data2d_nc_pinterp \
>> -lvx_data2d_nccf \
>> -lvx_data2d \
>> -lvx_nc_util \
>> -lvx_grid \
>> -lvx_config \
>> -lvx_cal \
>> -lvx_util \
>> -lvx_math \
>> -lvx_color \
>> -lvx_log \
>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>
>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
>> function `H5PL_load':
>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
>> applications requires at runtime the shared libraries from the
glibc
>> version used for linking
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchhttpcode':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>> undefined reference to `curl_easy_getinfo'
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchurl_file':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>> undefined reference to `curl_easy_perform'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>> undefined reference to `curl_easy_getinfo'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>> undefined reference to `curl_easy_strerror'
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchlastmodified':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
>> undefined reference to `curl_easy_setopt'
>> ...more errors follow
>>
>>
>> It seems to be related to the curl library and suggests netcdf
needs it,
>> but I want to avoid compiling netcdf and just use the supercomputer
>> version.
>>
>> I found this helpful email reference to compiled MET on
yellowstone, but
>> I couldn't find any tc_utils in
>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>> seemed the compilation was not working recently.
>> http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
>>
>> Dave
>>
>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Tue Jan 28 14:21:25 2014
Dave,
OK, we should be all set. For some reason the current version of the
intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
in the MET code. I just finished compiling MET on yellowstone in:
/glade/p/ral/jnt/MET/MET_releases/METv4.1
In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
Just copy that into you top-level METv4.1 directory and unpack it.
I'll also post that patches file to the known issues page:
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
/glade/p/ral/jnt/tools/netcdf-3.6.3
Please give that a shot and let me know if you have any more problems
compiling in yellowstone. We obviously want MET to run smoothly
there!
Thanks,
John
On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> OKay - thanks!
> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>> Hi Dave,
>>
>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>
>> Thanks,
>> John
>>
>>
>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>> Transaction: Ticket created by ahijevyc
>>> Queue: met_help
>>> Subject: yellowstone compilation
>>> Owner: Nobody
>>> Requestors: ahijevyc at ucar.edu
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>
>>>
>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>> compilation errors. They occur before the tropical cyclone section
>>> (TC_UTILS) is compiled.
>>>
>>> I managed to hack my way past some initial errors:
>>> avoided the isatty() function by commenting out some lines.
>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>> (probably a CISL module problem when module load gsl is loaded)
>>>
>>> but now I am stuck. It happens on ensemble_stat:
>>>
>>>
>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>> -Wshadow -static -DBLOCK4
>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>> -lvx_stat_out \
>>> -lvx_statistics \
>>> -lvx_shapedata \
>>> -lvx_gsl_prob \
>>> -lvx_analysis_util \
>>> -lvx_data2d_factory \
>>> -lvx_data2d_nc_met \
>>> -lvx_data2d_grib \
>>> -lvx_data2d_nc_pinterp \
>>> -lvx_data2d_nccf \
>>> -lvx_data2d \
>>> -lvx_nc_util \
>>> -lvx_grid \
>>> -lvx_config \
>>> -lvx_cal \
>>> -lvx_util \
>>> -lvx_math \
>>> -lvx_color \
>>> -lvx_log \
>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>
>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
>>> function `H5PL_load':
>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
>>> applications requires at runtime the shared libraries from the
glibc
>>> version used for linking
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchhttpcode':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>> undefined reference to `curl_easy_getinfo'
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchurl_file':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>> undefined reference to `curl_easy_perform'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>> undefined reference to `curl_easy_getinfo'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>> undefined reference to `curl_easy_strerror'
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchlastmodified':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
>>> undefined reference to `curl_easy_setopt'
>>> ...more errors follow
>>>
>>>
>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>> version.
>>>
>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>> I couldn't find any tc_utils in
>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>> seemed the compilation was not working recently.
>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>
>>> Dave
>>>
>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Wed Jan 29 10:02:51 2014
Thanks John _ I'll try it now. FYI, you introduced a typo in the MET
known issue page right below the section you added. (Right below "And
then recompile MET" it says "h3>")
dave
On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
> Dave,
>
> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
> in the MET code. I just finished compiling MET on yellowstone in:
> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>
> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
> Just copy that into you top-level METv4.1 directory and unpack it.
>
> I'll also post that patches file to the known issues page:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>
> Thanks,
> John
>
>
> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>> OKay - thanks!
>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>> Hi Dave,
>>>
>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>> Transaction: Ticket created by ahijevyc
>>>> Queue: met_help
>>>> Subject: yellowstone compilation
>>>> Owner: Nobody
>>>> Requestors: ahijevyc at ucar.edu
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>
>>>>
>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>> compilation errors. They occur before the tropical cyclone
section
>>>> (TC_UTILS) is compiled.
>>>>
>>>> I managed to hack my way past some initial errors:
>>>> avoided the isatty() function by commenting out some lines.
>>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>
>>>> but now I am stuck. It happens on ensemble_stat:
>>>>
>>>>
>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>>> -Wshadow -static -DBLOCK4
>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>> -lvx_stat_out \
>>>> -lvx_statistics \
>>>> -lvx_shapedata \
>>>> -lvx_gsl_prob \
>>>> -lvx_analysis_util \
>>>> -lvx_data2d_factory \
>>>> -lvx_data2d_nc_met \
>>>> -lvx_data2d_grib \
>>>> -lvx_data2d_nc_pinterp \
>>>> -lvx_data2d_nccf \
>>>> -lvx_data2d \
>>>> -lvx_nc_util \
>>>> -lvx_grid \
>>>> -lvx_config \
>>>> -lvx_cal \
>>>> -lvx_util \
>>>> -lvx_math \
>>>> -lvx_color \
>>>> -lvx_log \
>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>
>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>> function `H5PL_load':
>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>> applications requires at runtime the shared libraries from the
glibc
>>>> version used for linking
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchhttpcode':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>>> undefined reference to `curl_easy_getinfo'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchurl_file':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>>> undefined reference to `curl_easy_perform'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>>> undefined reference to `curl_easy_getinfo'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>>> undefined reference to `curl_easy_strerror'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchlastmodified':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>> undefined reference to `curl_easy_setopt'
>>>> ...more errors follow
>>>>
>>>>
>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>> version.
>>>>
>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>> I couldn't find any tc_utils in
>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>> seemed the compilation was not working recently.
>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>
>>>> Dave
>>>>
>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Wed Jan 29 10:18:46 2014
Yes! Got it to compile after setting NETCDF_BASE to
/glade/p/ral/jnt/tools/netcdf-3.6.3
Thanks!
dave
On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
> Dave,
>
> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
> in the MET code. I just finished compiling MET on yellowstone in:
> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>
> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
> Just copy that into you top-level METv4.1 directory and unpack it.
>
> I'll also post that patches file to the known issues page:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>
> Thanks,
> John
>
>
> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>> OKay - thanks!
>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>> Hi Dave,
>>>
>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>> Transaction: Ticket created by ahijevyc
>>>> Queue: met_help
>>>> Subject: yellowstone compilation
>>>> Owner: Nobody
>>>> Requestors: ahijevyc at ucar.edu
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>
>>>>
>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>> compilation errors. They occur before the tropical cyclone
section
>>>> (TC_UTILS) is compiled.
>>>>
>>>> I managed to hack my way past some initial errors:
>>>> avoided the isatty() function by commenting out some lines.
>>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>
>>>> but now I am stuck. It happens on ensemble_stat:
>>>>
>>>>
>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>>> -Wshadow -static -DBLOCK4
>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>> -lvx_stat_out \
>>>> -lvx_statistics \
>>>> -lvx_shapedata \
>>>> -lvx_gsl_prob \
>>>> -lvx_analysis_util \
>>>> -lvx_data2d_factory \
>>>> -lvx_data2d_nc_met \
>>>> -lvx_data2d_grib \
>>>> -lvx_data2d_nc_pinterp \
>>>> -lvx_data2d_nccf \
>>>> -lvx_data2d \
>>>> -lvx_nc_util \
>>>> -lvx_grid \
>>>> -lvx_config \
>>>> -lvx_cal \
>>>> -lvx_util \
>>>> -lvx_math \
>>>> -lvx_color \
>>>> -lvx_log \
>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>
>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>> function `H5PL_load':
>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>> applications requires at runtime the shared libraries from the
glibc
>>>> version used for linking
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchhttpcode':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>>> undefined reference to `curl_easy_getinfo'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchurl_file':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>>> undefined reference to `curl_easy_perform'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>>> undefined reference to `curl_easy_getinfo'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>>> undefined reference to `curl_easy_strerror'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchlastmodified':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>> undefined reference to `curl_easy_setopt'
>>>> ...more errors follow
>>>>
>>>>
>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>> version.
>>>>
>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>> I couldn't find any tc_utils in
>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>> seemed the compilation was not working recently.
>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>
>>>> Dave
>>>>
>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Thu Jan 30 09:57:58 2014
Dave,
Thanks for the heads up about the typo. That's what I get for editing
the html files directly.
Glad that did the trick. If you're using the MET-TC tools for the
first time...
- Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
- Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
- Kathryn Newman, Christopher Williams, and I have a lot of experience
configuring/running the tools. And we'd all be happy to answer any
questions that come up.
I'll go ahead and resolve this ticket.
Thanks,
John
On 01/29/2014 10:18 AM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> Yes! Got it to compile after setting NETCDF_BASE to
>
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Thanks!
>
> dave
>
>
>
> On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
>> Dave,
>>
>> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
>> in the MET code. I just finished compiling MET on yellowstone in:
>> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>>
>> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
>> Just copy that into you top-level METv4.1 directory and unpack it.
>>
>> I'll also post that patches file to the known issues page:
>>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>>
>> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
>> /glade/p/ral/jnt/tools/netcdf-3.6.3
>>
>> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>>
>> Thanks,
>> John
>>
>>
>> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>
>>> OKay - thanks!
>>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>>> Hi Dave,
>>>>
>>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>>> Transaction: Ticket created by ahijevyc
>>>>> Queue: met_help
>>>>> Subject: yellowstone compilation
>>>>> Owner: Nobody
>>>>> Requestors: ahijevyc at ucar.edu
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>>
>>>>>
>>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>>> compilation errors. They occur before the tropical cyclone
section
>>>>> (TC_UTILS) is compiled.
>>>>>
>>>>> I managed to hack my way past some initial errors:
>>>>> avoided the isatty() function by commenting out some
lines.
>>>>> fixed the GSL base directory by taking out the /gsl part
of the path
>>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>>
>>>>> but now I am stuck. It happens on ensemble_stat:
>>>>>
>>>>>
>>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o
\
>>>>> -Wshadow -static -DBLOCK4
>>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>>> -lvx_stat_out \
>>>>> -lvx_statistics \
>>>>> -lvx_shapedata \
>>>>> -lvx_gsl_prob \
>>>>> -lvx_analysis_util \
>>>>> -lvx_data2d_factory \
>>>>> -lvx_data2d_nc_met \
>>>>> -lvx_data2d_grib \
>>>>> -lvx_data2d_nc_pinterp \
>>>>> -lvx_data2d_nccf \
>>>>> -lvx_data2d \
>>>>> -lvx_nc_util \
>>>>> -lvx_grid \
>>>>> -lvx_config \
>>>>> -lvx_cal \
>>>>> -lvx_util \
>>>>> -lvx_math \
>>>>> -lvx_color \
>>>>> -lvx_log \
>>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>>
>>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>>> function `H5PL_load':
>>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>>> applications requires at runtime the shared libraries from the
glibc
>>>>> version used for linking
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchhttpcode':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:29:
>>>>> undefined reference to `curl_easy_getinfo'
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchurl_file':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:43:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:48:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:53:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:58:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:64:
>>>>> undefined reference to `curl_easy_perform'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:77:
>>>>> undefined reference to `curl_easy_getinfo'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:83:
>>>>> undefined reference to `curl_easy_strerror'
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchlastmodified':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> ...more errors follow
>>>>>
>>>>>
>>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>>> version.
>>>>>
>>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>>> I couldn't find any tc_utils in
>>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>>> seemed the compilation was not working recently.
>>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>>
>>>>> Dave
>>>>>
>>>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Thu Jan 30 15:45:53 2014
Is there any reason that tc_pairs and tc_stat won't work globally? I
was worried because I tried that tc-dland "distance-to-land" routine
and
it only filled in half the 360 degrees longitude.
On 1/30/14 9:57 AM, John Halley Gotway via RT wrote:
> Dave,
>
> Thanks for the heads up about the typo. That's what I get for
editing the html files directly.
>
> Glad that did the trick. If you're using the MET-TC tools for the
first time...
> - Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
> - Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
> - Kathryn Newman, Christopher Williams, and I have a lot of
experience configuring/running the tools. And we'd all be happy to
answer any questions that come up.
>
> I'll go ahead and resolve this ticket.
>
> Thanks,
> John
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Thu Jan 30 16:05:03 2014
I have adeck files from the NHC. And I have my own from the MPAS
model. Do I need to concatenate them into one file before I run
TC-Pairs or can I have separate adeck files for the NHC models and the
MPAS model?
In other words, can I say
./bin/tc_pairs -adeck ./atcf/a*dat ./mpas/a*dat -bdeck ./atcf/b*dat
-config ./TCPairsConfig -out tc_pairs
where ./atcf/a*dat refers to the NHC adecks and ./mpas/a*dat refers to
the MPAS adecks?
dave
On 1/30/14 9:57 AM, John Halley Gotway via RT wrote:
> Dave,
>
> Thanks for the heads up about the typo. That's what I get for
editing the html files directly.
>
> Glad that did the trick. If you're using the MET-TC tools for the
first time...
> - Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
> - Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
> - Kathryn Newman, Christopher Williams, and I have a lot of
experience configuring/running the tools. And we'd all be happy to
answer any questions that come up.
>
> I'll go ahead and resolve this ticket.
>
> Thanks,
> John
>
------------------------------------------------
Subject: yellowstone compilation
From: John Halley Gotway
Time: Thu Jan 30 16:14:25 2014
Dave,
Can you tell me specifically what tc_dland command resulted in bad
data? I just ran it for a global 1-degree grid using the following
command:
tc_dland global_dland.nc -grid -90 -180 1 1 181 361
An image of the resulting distances to land is attached. I generated
this using the plot_data_plane utility:
plot_data_plane global_dland.nc global_dland.png 'name="dland";
level="(*,*)";'
But you'll notice that our distances to land don't look great. "land"
is only defined in North America. To get accurate distances to land
globally, we'd need a good definition of what counts as
"land" globally. NHC doesn't have that, but Kathryn was going to
check with other agencies to look for it.
To answer your question - I would expect the MET-TC tools to run fine
globally - with the exception of this poor definition of land.
Thanks,
John
On 01/30/2014 03:45 PM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> Is there any reason that tc_pairs and tc_stat won't work globally?
I
> was worried because I tried that tc-dland "distance-to-land" routine
and
> it only filled in half the 360 degrees longitude.
>
>
> On 1/30/14 9:57 AM, John Halley Gotway via RT wrote:
>> Dave,
>>
>> Thanks for the heads up about the typo. That's what I get for
editing the html files directly.
>>
>> Glad that did the trick. If you're using the MET-TC tools for the
first time...
>> - Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
>> - Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
>> - Kathryn Newman, Christopher Williams, and I have a lot of
experience configuring/running the tools. And we'd all be happy to
answer any questions that come up.
>>
>> I'll go ahead and resolve this ticket.
>>
>> Thanks,
>> John
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Thu Jan 30 16:19:43 2014
Dave,
You do not need to concatenate them. The way you've listed it with
wildcards is fine.
Usually, our hurricane data is broken out into different files
depending on the storm. And we've found it to be convenient to call
tc_pairs once per storm. That simplifies the process of matching
ADECK tracks up to BDECK tracks. While you could throw a whole
season's worth of data at it, it might run really slowly and you might
run out of memory. Just try it in whatever way is most
convenient, but if it's taking too long to run, consider passing it
smaller amounts of data.
Hope that helps.
John
On 01/30/2014 04:05 PM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> I have adeck files from the NHC. And I have my own from the MPAS
> model. Do I need to concatenate them into one file before I run
> TC-Pairs or can I have separate adeck files for the NHC models and
the
> MPAS model?
>
> In other words, can I say
> ./bin/tc_pairs -adeck ./atcf/a*dat ./mpas/a*dat -bdeck ./atcf/b*dat
> -config ./TCPairsConfig -out tc_pairs
>
> where ./atcf/a*dat refers to the NHC adecks and ./mpas/a*dat refers
to
> the MPAS adecks?
>
> dave
>
>
>
>
> On 1/30/14 9:57 AM, John Halley Gotway via RT wrote:
>> Dave,
>>
>> Thanks for the heads up about the typo. That's what I get for
editing the html files directly.
>>
>> Glad that did the trick. If you're using the MET-TC tools for the
first time...
>> - Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
>> - Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
>> - Kathryn Newman, Christopher Williams, and I have a lot of
experience configuring/running the tools. And we'd all be happy to
answer any questions that come up.
>>
>> I'll go ahead and resolve this ticket.
>>
>> Thanks,
>> John
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Thu Jan 30 16:39:44 2014
John, Ah, I didn't realize it was only defined for the north atlantic
basin. It would be great if that could be mentioned in the tutorial.
Especially because of the really high values in the bottom right
corner and the low values on the left side. It jumps from dark blue
to
magenta in one grid point!
Before I downloaded MET-TC I searched for a distance-from-land
product,
but didn't find one. Seems like a fun product to make using Google
earth, or something that knows the area of land masses.
Dave
On 1/30/14 4:14 PM, John Halley Gotway via RT wrote:
> Dave,
>
> Can you tell me specifically what tc_dland command resulted in bad
data? I just ran it for a global 1-degree grid using the following
command:
> tc_dland global_dland.nc -grid -90 -180 1 1 181 361
>
> An image of the resulting distances to land is attached. I
generated this using the plot_data_plane utility:
> plot_data_plane global_dland.nc global_dland.png 'name="dland";
level="(*,*)";'
>
> But you'll notice that our distances to land don't look great.
"land" is only defined in North America. To get accurate distances to
land globally, we'd need a good definition of what counts as
> "land" globally. NHC doesn't have that, but Kathryn was going to
check with other agencies to look for it.
>
> To answer your question - I would expect the MET-TC tools to run
fine globally - with the exception of this poor definition of land.
>
> Thanks,
> John
>
> On 01/30/2014 03:45 PM, David Ahijevych via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>> Is there any reason that tc_pairs and tc_stat won't work globally?
I
>> was worried because I tried that tc-dland "distance-to-land"
routine and
>> it only filled in half the 360 degrees longitude.
>>
>>
>> On 1/30/14 9:57 AM, John Halley Gotway via RT wrote:
>>> Dave,
>>>
>>> Thanks for the heads up about the typo. That's what I get for
editing the html files directly.
>>>
>>> Glad that did the trick. If you're using the MET-TC tools for the
first time...
>>> - Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
>>> - Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
>>> - Kathryn Newman, Christopher Williams, and I have a lot of
experience configuring/running the tools. And we'd all be happy to
answer any questions that come up.
>>>
>>> I'll go ahead and resolve this ticket.
>>>
>>> Thanks,
>>> John
>>>
------------------------------------------------
More information about the Met_help
mailing list