[Met_help] [rt.rap.ucar.edu #80828] History for MET v6.0 compilation problem
John Halley Gotway via RT
met_help at ucar.edu
Wed Jul 10 16:39:19 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
MET support folk(s),
I have a problem and a question: (1) a MET v6.0 compilation problem; and (2) a question about downloading UPP v2.2 (or even whether or not I need it).
I am trying to install MET v6.0 on a Mac Pro running Mac OS X v10.12.5 (Sierra), using GNU Fortran and C compilers v.7.1. I’ve installed WRFv3.9 and WPSv3.9 successfully using the same compilers (though I haven’t run them yet). To support those installations, I downloaded and installed NetCDF v.4.1.3, jasper v.1.900.1, libpng v.1.2.50, and zlib v.1.2.7 from the WRF Web site and placed the library and include files in directories recommended by the WRF online installation instructions.
To support the MET v6.0 installation, I also downloaded and compiled the BUFRLIB v.10.2.3 library, GSL v.2.3, and g2clib v.1.6.0.
To install MET v6.0 I’m following instructions in the online tutorial and the README file that comes with the met-6.0_bugfix distribution, but unfortunately my effort to install MET v6.0 hasn’t gone as successfully; I’m getting a compiler error that I can’t resolve:
In file included from nc_var_info.cc:24:0:
nc_utils.h:22:10: fatal error: netcdf: No such file or directory
#include <netcdf>
^~~~~~~~
compilation terminated.
make[3]: *** [libvx_nc_util_a-nc_var_info.o] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
For the time being I’m at the end of my rope, thus this message. If you can suggest a way forward, I’d be grateful.
I’ve attached the following files to provide context for the error:
— config.log file
— make_install.log more
— src/libcode/vx_nc_util/Makefile (the Makefile most proximate to the error)
I set the MET-specific and related environment variables listed below, reflecting my local installation locations for NetCDF, GSL, g2clib, the BUFR library, etc.
setenv WRF_BUILD_PATH /Users/wrf/WRF/Build_WRF
setenv WRF_UTIL_LIB_PATH $WRF_BUILD_PATH/LIBRARIES
setenv NETCDF $WRF_UTIL_LIB_PATH/netcdf
setenv GRIB2 $WRF_BUILD_PATH/LIBRARIES/grib2
setenv JASPERLIB $GRIB2/jasper/lib
setenv JASPERINC $GRIB2/jasper/include
setenv MET_BASE /Users/wrf/WRF/METV6.0
setenv MET_NETCDFLIB $NETCDF/lib
setenv MET_NETCDFINC $NETCDF/include
setenv MET_GSLINC /usr/local/include
setenv MET_GSLLIB /usr/local/lib
setenv MET_GRIB2CLIB /usr/local/src/g2clib-1.6.0
setenv MET_GRIB2CINC /usr/local/src/g2clib-1.6.0
setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-3/libbufr.a
On my second question, I’m assuming that if I want to use MET 6.0 to evaluate WRF-ARW model output, I’ll need UPP to convert WRF NetCDF output to GRIB format (either GRIB1 or GRIB2)—let me know if that’s no longer true. However, I can’t find a copy of UPP v2.2 (which I assume is the most recent version). Access seems to be through WRF-NMM support Web pages at DTC, but since support for WRF-NMM has been discontinued, so has access to UPP v2.2.
I’ve been running WRF-ARW, UPP v.2.1, and MET v.4.1 for 3+ years (under Mac OS X v10.6 [Snow Leopard]), so all of my questions above are about upgrading to a more recent version of Mac OS X, GNU compilers, and WRF, WPS, UPP, and MET software.
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) ) ) ) ) ~ ~ ~ ~ *
***************************************************************
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Mon Jun 12 11:53:14 2017
Supporting files attached this time—sorry about that!
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Mon Jun 12 12:55:47 2017
Hello Dr. Dempsey,
It looks like you have some issues with compiling MET v6.0 and are
also
wondering if you need to install the UPPv2.2.
1) Compiling issue
Based on your environment variables, it looks like you incorrectly set
the
MET_BUFRLIB to the actual library file, when you only needed to
indicate
the directory. Please replace
setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-
3/libbufr.a
with
setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-3
Based on your config.log, it looks like you did not install HDF5. In
METv6.0, NetCDF has dependencies on HDF5, so you will need to build
HDF5
first, then build NetCDF. For instructions on installing HDF5, please
refer to the online tutorial under the heading "Compiling HDF5",
located at:
http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs
Remember to perform a 'make clean' then re-run your config command
before
rebuilding METv6.0.
2) UPP requirement and download
As far as converting WRF NetCDF to grib/grib2, I'll need to verify
that you
still need (or no longer need) to install UPP (and which versions are
compatible with METv6.0).
If you still wish to download the latest version of UPP (UPP v3.1 was
released in September 2016), please follow this link:
http://www.dtcenter.org/upp/users/
The web page at http://www.dtcenter.org/wrf-nmm/users/index.php has an
updated link to the UPP download if you need to bookmark it.
Please let us know if you are still experiencing any issues with
METv6.0.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Mon Jun 12 14:05:38 2017
Hello Dr. Dempsey,
I checked with other MET staff and you will still need UPP to convert
your
WRF-ARW data to grib/grib2. Your currently installed version, UPP
v2.1
should suffice and you shouldn't need to update it for MET v6.0.
However,
I don't know if UPPv2.1 is still compatible with your latest version
of Mac
OS X. If you need to update your version of UPP, any version should
work
with METv6.0.
Thank you for your interest in MET v6.0. Please don't hesitate to
contact
us if you have any other MET-related questions.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Mon, Jun 12, 2017 at 5:17 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> Mon Jun 12 11:17:58 2017: Request 80828 was acted upon.
> Transaction: Ticket created by dempsey at sfsu.edu
> Queue: met_help
> Subject: MET v6.0 compilation problem
> Owner: Nobody
> Requestors: dempsey at sfsu.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> MET support folk(s),
>
> I have a problem and a question: (1) a MET v6.0 compilation problem;
and
> (2) a question about downloading UPP v2.2 (or even whether or not I
need
> it).
>
> I am trying to install MET v6.0 on a Mac Pro running Mac OS X
v10.12.5
> (Sierra), using GNU Fortran and C compilers v.7.1. I’ve installed
WRFv3.9
> and WPSv3.9 successfully using the same compilers (though I haven’t
run
> them yet). To support those installations, I downloaded and
installed
> NetCDF v.4.1.3, jasper v.1.900.1, libpng v.1.2.50, and zlib v.1.2.7
from
> the WRF Web site and placed the library and include files in
directories
> recommended by the WRF online installation instructions.
>
> To support the MET v6.0 installation, I also downloaded and compiled
the
> BUFRLIB v.10.2.3 library, GSL v.2.3, and g2clib v.1.6.0.
>
> To install MET v6.0 I’m following instructions in the online
tutorial and
> the README file that comes with the met-6.0_bugfix distribution, but
> unfortunately my effort to install MET v6.0 hasn’t gone as
successfully;
> I’m getting a compiler error that I can’t resolve:
>
> In file included from nc_var_info.cc:24:0:
> nc_utils.h:22:10: fatal error: netcdf: No such file or directory
> #include <netcdf>
> ^~~~~~~~
> compilation terminated.
> make[3]: *** [libvx_nc_util_a-nc_var_info.o] Error 1
> make[2]: *** [install-recursive] Error 1
> make[1]: *** [install-recursive] Error 1
> make: *** [install-recursive] Error 1
>
> For the time being I’m at the end of my rope, thus this message. If
you
> can suggest a way forward, I’d be grateful.
>
> I’ve attached the following files to provide context for the error:
>
> — config.log file
> — make_install.log more
> — src/libcode/vx_nc_util/Makefile (the Makefile most proximate to
the
> error)
>
> I set the MET-specific and related environment variables listed
below,
> reflecting my local installation locations for NetCDF, GSL, g2clib,
the
> BUFR library, etc.
>
> setenv WRF_BUILD_PATH /Users/wrf/WRF/Build_WRF
> setenv WRF_UTIL_LIB_PATH $WRF_BUILD_PATH/LIBRARIES
> setenv NETCDF $WRF_UTIL_LIB_PATH/netcdf
> setenv GRIB2 $WRF_BUILD_PATH/LIBRARIES/grib2
> setenv JASPERLIB $GRIB2/jasper/lib
> setenv JASPERINC $GRIB2/jasper/include
>
> setenv MET_BASE /Users/wrf/WRF/METV6.0
> setenv MET_NETCDFLIB $NETCDF/lib
> setenv MET_NETCDFINC $NETCDF/include
> setenv MET_GSLINC /usr/local/include
> setenv MET_GSLLIB /usr/local/lib
> setenv MET_GRIB2CLIB /usr/local/src/g2clib-1.6.0
> setenv MET_GRIB2CINC /usr/local/src/g2clib-1.6.0
> setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-3/libbufr.a
>
> On my second question, I’m assuming that if I want to use MET 6.0 to
> evaluate WRF-ARW model output, I’ll need UPP to convert WRF NetCDF
output
> to GRIB format (either GRIB1 or GRIB2)—let me know if that’s no
longer
> true. However, I can’t find a copy of UPP v2.2 (which I assume is
the most
> recent version). Access seems to be through WRF-NMM support Web
pages at
> DTC, but since support for WRF-NMM has been discontinued, so has
access to
> UPP v2.2.
>
> I’ve been running WRF-ARW, UPP v.2.1, and MET v.4.1 for 3+ years
(under
> Mac OS X v10.6 [Snow Leopard]), so all of my questions above are
about
> upgrading to a more recent version of Mac OS X, GNU compilers, and
WRF,
> WPS, UPP, and MET software.
>
> — Dave
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
)
> ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Tue Jun 13 02:11:14 2017
On Jun 12, 2017, at 11:55 AM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
It looks like you have some issues with compiling MET v6.0 and are
also
wondering if you need to install the UPPv2.2.
1) Compiling issue
Based on your environment variables, it looks like you incorrectly set
the
MET_BUFRLIB to the actual library file, when you only needed to
indicate
the directory. Please replace
setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-
3/libbufr.a
with
setenv MET_BUFRLIB /usr/local/src/BUFRLIB_v10-2-3
Fixed.
Based on your config.log, it looks like you did not install HDF5.
That’s correct. The “MET
Downloads<http://www.dtcenter.org/met/users/downloads/index.php>”
page, under “External Libraries Needed to Build MET”, doesn’t mention
HDF5. It mentions HDF4, but only as an option for people who want to
install the MODIS-Regrid tool, which I don’t. (That is, the "MET
Downloads” page and the MET v.6.0 Tutorial under “Compilation” are not
entirely consistent with each other.)
In METv6.0, NetCDF has dependencies on HDF5, so you will need to
build HDF5 first, then build NetCDF. For instructions on installing
HDF5, please refer to the online tutorial under the heading "Compiling
HDF5", located at:
http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs
I deleted the NetCDF-C installation (v.4.4.1.1) that I’d created to
support MET v.6.0, installed zlib v.1.2.11, installed HDF5 v.1.8.18,
and reinstalled NetCDF v.4.4.1.1. I also installed NetCDF-Fortran
v.4.4.4, and I tried to install NetCDF-CXX4 v.4.3.0 (which the MET
v.6.0 tutorial, under
“Compilation<http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs>”,
says is a required library), but when I run “configure”, it keeps
issuing the error message: "configure: error: NetCDF must be built
with netCDF-4 enabled”, no matter what I’ve tried so far—the configure
command doesn’t understand arguments such as —enable-netcdf-4 or
—enable-cxx-4, both of which are suggested in the netCDF-CXX README
file.
Remember to perform a 'make clean' then re-run your config command
before rebuilding METv6.0.
I did this, then ran
configure --enable-hdf5 --enable-hdf5-file-tests CPPFLAGS="-
I${H5DIR}/include" LDFLAGS="-L${H5DIR}/lib" --prefix=$MET_LIB_DIR
though configure issued a "WARNING: unrecognized options: --enable-
hdf5, --enable-hdf5-file-tests.” (It didn’t recognize options
"—enable-hdf4” for “—enable-hdf4-file-tests”, either, for that
matter). When I then ran “make install” anyway, I got the same
compiler error that prompted my first request for help:
In file included from nc_var_info.cc:24:0:
nc_utils.h:22:10: fatal error: netcdf: No such file or directory
#include <netcdf>
^~~~~~~~
compilation terminated.
make[3]: *** [libvx_nc_util_a-nc_var_info.o] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
I don’t have any deep insight about what I should try next.
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
) ) ) ~ ~ ~ ~ *
***************************************************************
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Tue Jun 13 02:29:21 2017
On Jun 12, 2017, at 11:55 AM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
It looks like you have some issues with compiling MET v6.0.
Based on your config.log, it looks like you did not install HDF5.
I forgot to attach some files possibly relevant to my latest attempt
to install netCDF v.4.4.1.1 to support MET v.6.0. They are attached.
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Tue Jun 13 12:48:42 2017
Hello Dr. Dempsey,
I think I found the issue causing your missing netcdf compiler error.
In
your config.log, it appears that you have set the following three MET
environment variables:
MET_NETCDF='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf'
MET_NETCDFINC='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/include'
MET_NETCDFLIB='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/lib'
You only need to set either the MET_NETCDF environment variable, OR
the
MET_NETCDFINC and MET_NETCDFLIB. When all three environment variables
are
set, this "confuses" the build script. Other users have encountered
this
issue and it is rectified by selecting the correct combination of the
MET
NetCDF environment variables. You can remove your MET_NETCDFINC and
MET_NETCDFLIB from your .cshrc (or K-shell equivalent) and repeat your
configuration and build steps.
Please let us know if you are still experiencing any issues.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Jun 13, 2017 at 8:29 AM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 12, 2017, at 11:55 AM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> It looks like you have some issues with compiling MET v6.0.
>
> Based on your config.log, it looks like you did not install HDF5.
>
> I forgot to attach some files possibly relevant to my latest attempt
to
> install netCDF v.4.4.1.1 to support MET v.6.0. They are attached.
>
> — Dave
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Tue Jun 13 14:56:46 2017
On Jun 13, 2017, at 11:48 AM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
I think I found the issue causing your missing netcdf compiler error.
In
your config.log, it appears that you have set the following three MET
environment variables:
MET_NETCDF='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf'
MET_NETCDFINC='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/include'
MET_NETCDFLIB='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/lib'
You only need to set either the MET_NETCDF environment variable, OR
the
MET_NETCDFINC and MET_NETCDFLIB. When all three environment variables
are
set, this "confuses" the build script. Other users have encountered
this
issue and it is rectified by selecting the correct combination of the
MET
NetCDF environment variables. You can remove your MET_NETCDFINC and
MET_NETCDFLIB from your .cshrc (or K-shell equivalent) and repeat your
configuration and build steps.
Minna,
Thanks for staying engaged!
I tried the following steps:
unsetenv MET_NETCDF (leaving MET_NETCDFINC and MET_NETCDFLIB set)
make clean
configure —prefix=`pwd` —enable-grib2
make install |& tee make_install.log
The results produced the same compiler error as before. From
make_install.log:
In file included from nc_var_info.cc:24:0:
nc_utils.h:22:10: fatal error: netcdf: No such file or directory
#include <netcdf>
^~~~~~~~
compilation terminated.
(For what it’s worth, somewhere in the MET v.6.0 documentation it says
that if all MET_NETCDF, MET_NETCDFINC, and MET_NETCDFLIB are set, then
MET_NETCDF is ignored, so if the documentation is correct—never a
given—then the steps above shouldn’t have produced a different result,
and in fact it doesn’t appear to be any different. Perhaps the
documentation is right about the more specific environment variables
overriding the more general one (MET_NETCDF)?)
I also tried unsetting MET_NETCDFINC and MET_NETCDFLIB while leaving
MET_NETCDF set, and repeating the other steps above, but the results
are the same.
I’ve attached the latest versions of config.log, make_install.log, and
src/libcode/vx_nc_util/Makefile.
On a side note, I also just noticed the existence of met-
6.0_patches_20170419.tar.gz, so I installed the patches. This
reintroduced a compiler error that I’d fixed in my initial attempts to
compile MET v.6.0:
config_util.cc: In function ‘void parse_sid_mask(const ConcatString&,
StringArray&, ConcatString&)’:
config_util.cc:361:17: error: ‘PATH_MAX’ was not declared in this
scope
char sid_str[PATH_MAX];
^~~~~~~~
config_util.cc:361:17: note: suggested alternative: ‘RAND_MAX’
Introducing the suggested alternative in config_util.cc eliminates the
compiler problem.
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Tue Jun 13 15:47:16 2017
Hello Dr. Dempsey,
Thank you for your patience while we try to track down a solution to
your
compile issues. The METv6.0 tutorial does indeed state that the
MET_NETCDF
env var is ignored when the MET_NETCDFLIB and MET_NETCDFINC are set
-but
also when the include and lib files are in separate locations. In
your
case, the lib and include are all found under your MET_NETCDF dir..
I'll enlist the aid of some other MET developers to see if there is
something I missed in your logs.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Jun 13, 2017 at 8:56 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 13, 2017, at 11:48 AM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello Dr. Dempsey,
>
> I think I found the issue causing your missing netcdf compiler
error. In
> your config.log, it appears that you have set the following three
MET
> environment variables:
> MET_NETCDF='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf'
> MET_NETCDFINC='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/include'
> MET_NETCDFLIB='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/lib'
>
> You only need to set either the MET_NETCDF environment variable, OR
the
> MET_NETCDFINC and MET_NETCDFLIB. When all three environment
variables are
> set, this "confuses" the build script. Other users have encountered
this
> issue and it is rectified by selecting the correct combination of
the MET
> NetCDF environment variables. You can remove your MET_NETCDFINC and
> MET_NETCDFLIB from your .cshrc (or K-shell equivalent) and repeat
your
> configuration and build steps.
>
> Minna,
>
> Thanks for staying engaged!
>
> I tried the following steps:
>
> unsetenv MET_NETCDF (leaving MET_NETCDFINC and MET_NETCDFLIB set)
> make clean
> configure —prefix=`pwd` —enable-grib2
> make install |& tee make_install.log
>
> The results produced the same compiler error as before. From
> make_install.log:
>
> In file included from nc_var_info.cc:24:0:
> nc_utils.h:22:10: fatal error: netcdf: No such file or directory
> #include <netcdf>
> ^~~~~~~~
> compilation terminated.
>
> (For what it’s worth, somewhere in the MET v.6.0 documentation it
says
> that if all MET_NETCDF, MET_NETCDFINC, and MET_NETCDFLIB are set,
then
> MET_NETCDF is ignored, so if the documentation is correct—never a
> given—then the steps above shouldn’t have produced a different
result, and
> in fact it doesn’t appear to be any different. Perhaps the
documentation is
> right about the more specific environment variables overriding the
more
> general one (MET_NETCDF)?)
>
> I also tried unsetting MET_NETCDFINC and MET_NETCDFLIB while leaving
> MET_NETCDF set, and repeating the other steps above, but the results
are
> the same.
>
> I’ve attached the latest versions of config.log, make_install.log,
and
> src/libcode/vx_nc_util/Makefile.
>
> On a side note, I also just noticed the existence of
> met-6.0_patches_20170419.tar.gz, so I installed the patches. This
> reintroduced a compiler error that I’d fixed in my initial attempts
to
> compile MET v.6.0:
>
> config_util.cc: In function ‘void parse_sid_mask(const
ConcatString&,
> StringArray&, ConcatString&)’:
> config_util.cc:361:17: error: ‘PATH_MAX’ was not declared in this
scope
> char sid_str[PATH_MAX];
> ^~~~~~~~
> config_util.cc:361:17: note: suggested alternative: ‘RAND_MAX’
>
> Introducing the suggested alternative in config_util.cc eliminates
the
> compiler problem.
>
> — Dave
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Tue Jun 13 15:58:12 2017
Hello Dr. Dempsey,
In your latest Makefile, it looks like your MET_HDF5 environment
variables
aren't getting picked up- (line235 in your makefile shows nothing is
assigned to your MET_HDF5 environment variable). Could you please
set
your MET_HDF5 environment variable and try again? Unfortunately in
METv6.0, NetCDF has dependencies on HDF5 which might be the cause of
your
'missing netcdf' errors. Thanks again for your patience while we try
to
find a solution.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Jun 13, 2017 at 9:46 PM, Minna Win-Gildenmeister
<minnawin at ucar.edu>
wrote:
> Hello Dr. Dempsey,
>
> Thank you for your patience while we try to track down a solution to
your
> compile issues. The METv6.0 tutorial does indeed state that the
MET_NETCDF
> env var is ignored when the MET_NETCDFLIB and MET_NETCDFINC are set
-but
> also when the include and lib files are in separate locations. In
your
> case, the lib and include are all found under your MET_NETCDF dir..
>
> I'll enlist the aid of some other MET developers to see if there is
> something I missed in your logs.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423 <(303)%20497-8423>
> Fax: 302-497-8401 <(302)%20497-8401>
>
>
> On Tue, Jun 13, 2017 at 8:56 PM, David P Dempsey via RT
<met_help at ucar.edu
> > wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>>
>>
>> On Jun 13, 2017, at 11:48 AM, Minna Win via RT
<met_help at ucar.edu<mailto:
>> met_help at ucar.edu>> wrote:
>>
>> Hello Dr. Dempsey,
>>
>> I think I found the issue causing your missing netcdf compiler
error. In
>> your config.log, it appears that you have set the following three
MET
>> environment variables:
>> MET_NETCDF='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf'
>> MET_NETCDFINC='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/include'
>> MET_NETCDFLIB='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/lib'
>>
>> You only need to set either the MET_NETCDF environment variable, OR
the
>> MET_NETCDFINC and MET_NETCDFLIB. When all three environment
variables are
>> set, this "confuses" the build script. Other users have
encountered this
>> issue and it is rectified by selecting the correct combination of
the MET
>> NetCDF environment variables. You can remove your MET_NETCDFINC
and
>> MET_NETCDFLIB from your .cshrc (or K-shell equivalent) and repeat
your
>> configuration and build steps.
>>
>> Minna,
>>
>> Thanks for staying engaged!
>>
>> I tried the following steps:
>>
>> unsetenv MET_NETCDF (leaving MET_NETCDFINC and MET_NETCDFLIB set)
>> make clean
>> configure —prefix=`pwd` —enable-grib2
>> make install |& tee make_install.log
>>
>> The results produced the same compiler error as before. From
>> make_install.log:
>>
>> In file included from nc_var_info.cc:24:0:
>> nc_utils.h:22:10: fatal error: netcdf: No such file or directory
>> #include <netcdf>
>> ^~~~~~~~
>> compilation terminated.
>>
>> (For what it’s worth, somewhere in the MET v.6.0 documentation it
says
>> that if all MET_NETCDF, MET_NETCDFINC, and MET_NETCDFLIB are set,
then
>> MET_NETCDF is ignored, so if the documentation is correct—never a
>> given—then the steps above shouldn’t have produced a different
result, and
>> in fact it doesn’t appear to be any different. Perhaps the
documentation is
>> right about the more specific environment variables overriding the
more
>> general one (MET_NETCDF)?)
>>
>> I also tried unsetting MET_NETCDFINC and MET_NETCDFLIB while
leaving
>> MET_NETCDF set, and repeating the other steps above, but the
results are
>> the same.
>>
>> I’ve attached the latest versions of config.log, make_install.log,
and
>> src/libcode/vx_nc_util/Makefile.
>>
>> On a side note, I also just noticed the existence of
>> met-6.0_patches_20170419.tar.gz, so I installed the patches. This
>> reintroduced a compiler error that I’d fixed in my initial attempts
to
>> compile MET v.6.0:
>>
>> config_util.cc: In function ‘void parse_sid_mask(const
ConcatString&,
>> StringArray&, ConcatString&)’:
>> config_util.cc:361:17: error: ‘PATH_MAX’ was not declared in this
scope
>> char sid_str[PATH_MAX];
>> ^~~~~~~~
>> config_util.cc:361:17: note: suggested alternative: ‘RAND_MAX’
>>
>> Introducing the suggested alternative in config_util.cc eliminates
the
>> compiler problem.
>>
>> — Dave
>>
>>
>>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Tue Jun 13 16:45:28 2017
Hello Dr. Dempsey,
A colleague has suggested that there is a missing header file at
$MET_NETCDF/include or at $MET_NETCDFINC.
Could you please check for the existence of NetCDF header files and
library
files? Also, I need to make a clarification:
HDF4 is required 1) to build HDFEOS and 2) to build MET.
HDF5 is required 1) to build NetCDF and 2) to run MET. Once NetcDF4
is
built, there is NO dependency between MET and HDF5 at compile time.
But there is a runtime dependency with HDF5. That's why there are
two
environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
variable
needs to be set to where HDF4 is
located to build MET.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423 <%28303%29%20497-8423>
Fax: 302-497-8401 <%28302%29%20497-8401>
On Tue, Jun 13, 2017 at 9:57 PM, Minna Win-Gildenmeister
<minnawin at ucar.edu>
wrote:
> Hello Dr. Dempsey,
>
> In your latest Makefile, it looks like your MET_HDF5 environment
variables
> aren't getting picked up- (line235 in your makefile shows nothing is
> assigned to your MET_HDF5 environment variable). Could you please
set
> your MET_HDF5 environment variable and try again? Unfortunately in
> METv6.0, NetCDF has dependencies on HDF5 which might be the cause of
your
> 'missing netcdf' errors. Thanks again for your patience while we
try to
> find a solution.
>
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423 <%28303%29%20497-8423>
> Fax: 302-497-8401 <%28302%29%20497-8401>
>
>
> On Tue, Jun 13, 2017 at 9:46 PM, Minna Win-Gildenmeister <
> minnawin at ucar.edu> wrote:
>
>> Hello Dr. Dempsey,
>>
>> Thank you for your patience while we try to track down a solution
to your
>> compile issues. The METv6.0 tutorial does indeed state that the
MET_NETCDF
>> env var is ignored when the MET_NETCDFLIB and MET_NETCDFINC are set
-but
>> also when the include and lib files are in separate locations. In
your
>> case, the lib and include are all found under your MET_NETCDF dir..
>>
>> I'll enlist the aid of some other MET developers to see if there is
>> something I missed in your logs.
>>
>> Regards,
>> Minna
>>
>> ---------------
>> Minna Win
>> NCAR
>> Research Applications Lab
>> Phone: 303-497-8423 <%28303%29%20497-8423>
>> Fax: 302-497-8401 <%28302%29%20497-8401>
>>
>>
>> On Tue, Jun 13, 2017 at 8:56 PM, David P Dempsey via RT <
>> met_help at ucar.edu> wrote:
>>
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>>>
>>>
>>> On Jun 13, 2017, at 11:48 AM, Minna Win via RT <met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>> wrote:
>>>
>>> Hello Dr. Dempsey,
>>>
>>> I think I found the issue causing your missing netcdf compiler
error. In
>>> your config.log, it appears that you have set the following three
MET
>>> environment variables:
>>> MET_NETCDF='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf'
>>>
MET_NETCDFINC='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/include'
>>> MET_NETCDFLIB='/Users/wrf/WRF/Build_MET/LIBRARIES/netcdf/lib'
>>>
>>> You only need to set either the MET_NETCDF environment variable,
OR the
>>> MET_NETCDFINC and MET_NETCDFLIB. When all three environment
variables
>>> are
>>> set, this "confuses" the build script. Other users have
encountered this
>>> issue and it is rectified by selecting the correct combination of
the MET
>>> NetCDF environment variables. You can remove your MET_NETCDFINC
and
>>> MET_NETCDFLIB from your .cshrc (or K-shell equivalent) and repeat
your
>>> configuration and build steps.
>>>
>>> Minna,
>>>
>>> Thanks for staying engaged!
>>>
>>> I tried the following steps:
>>>
>>> unsetenv MET_NETCDF (leaving MET_NETCDFINC and MET_NETCDFLIB set)
>>> make clean
>>> configure —prefix=`pwd` —enable-grib2
>>> make install |& tee make_install.log
>>>
>>> The results produced the same compiler error as before. From
>>> make_install.log:
>>>
>>> In file included from nc_var_info.cc:24:0:
>>> nc_utils.h:22:10: fatal error: netcdf: No such file or directory
>>> #include <netcdf>
>>> ^~~~~~~~
>>> compilation terminated.
>>>
>>> (For what it’s worth, somewhere in the MET v.6.0 documentation it
says
>>> that if all MET_NETCDF, MET_NETCDFINC, and MET_NETCDFLIB are set,
then
>>> MET_NETCDF is ignored, so if the documentation is correct—never a
>>> given—then the steps above shouldn’t have produced a different
result, and
>>> in fact it doesn’t appear to be any different. Perhaps the
documentation is
>>> right about the more specific environment variables overriding the
more
>>> general one (MET_NETCDF)?)
>>>
>>> I also tried unsetting MET_NETCDFINC and MET_NETCDFLIB while
leaving
>>> MET_NETCDF set, and repeating the other steps above, but the
results are
>>> the same.
>>>
>>> I’ve attached the latest versions of config.log, make_install.log,
and
>>> src/libcode/vx_nc_util/Makefile.
>>>
>>> On a side note, I also just noticed the existence of
>>> met-6.0_patches_20170419.tar.gz, so I installed the patches. This
>>> reintroduced a compiler error that I’d fixed in my initial
attempts to
>>> compile MET v.6.0:
>>>
>>> config_util.cc: In function ‘void parse_sid_mask(const
ConcatString&,
>>> StringArray&, ConcatString&)’:
>>> config_util.cc:361:17: error: ‘PATH_MAX’ was not declared in this
scope
>>> char sid_str[PATH_MAX];
>>> ^~~~~~~~
>>> config_util.cc:361:17: note: suggested alternative: ‘RAND_MAX’
>>>
>>> Introducing the suggested alternative in config_util.cc eliminates
the
>>> compiler problem.
>>>
>>> — Dave
>>>
>>>
>>>
>>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Tue Jun 13 18:12:50 2017
On Jun 13, 2017, at 3:45 PM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
A colleague has suggested that there is a missing header file at
$MET_NETCDF/include or at $MET_NETCDFINC. Could you please check for
the existence of NetCDF header files and library files?
Minna,
Here’s what resides in $MET_NETCDF/lib and $MET_NETCDF/include:
wrf_cyclone% ls $MET_NETCDF/lib
libnetcdf.11.dylib* libnetcdf.settings libnetcdff.la*
libnetcdf.a libnetcdff.6.dylib* pkgconfig/
libnetcdf.dylib@ libnetcdff.a
libnetcdf.la* libnetcdff.dylib@
wrf_cyclone% ls $MET_NETCDF/include
netcdf.h netcdf_meta.h
netcdf.inc netcdf_nc_data.mod
netcdf.mod netcdf_nc_interfaces.mod
netcdf_f03.mod netcdf_nf_data.mod
netcdf_fortv2_c_interfaces.mod netcdf_nf_interfaces.mod
netcdf_mem.h typesizes.mod
And here is what is in $MET_HDF5/lib and $MET_HDF5/include:
wrf_cyclone% ls $MET_HDF5
bin/ include/ lib/ share/
wrf_cyclone% ls $MET_HDF5/lib
libhdf5.10.dylib* libhdf5.la* libhdf5_hl.a
libhdf5.a libhdf5.settings libhdf5_hl.dylib@
libhdf5.dylib@ libhdf5_hl.10.dylib* libhdf5_hl.la*
wrf_cyclone% ls $MET_HDF5/include
H5ACpublic.h H5FDdirect.h H5Fpublic.h H5PLpublic.h H5overflow.h
H5Apublic.h H5FDfamily.h H5Gpublic.h H5PTpublic.h H5pubconf.h
H5Cpublic.h H5FDlog.h H5IMpublic.h H5Ppublic.h H5public.h
H5DOpublic.h H5FDmpi.h H5Ipublic.h H5Rpublic.h H5version.h
H5DSpublic.h H5FDmpio.h H5LTpublic.h H5Spublic.h hdf5.h
H5Dpublic.h H5FDmulti.h H5Lpublic.h H5TBpublic.h hdf5_hl.h
H5Epubgen.h H5FDpublic.h H5MMpublic.h H5Tpublic.h
H5Epublic.h H5FDsec2.h H5Opublic.h H5Zpublic.h
H5FDcore.h H5FDstdio.h H5PLextern.h H5api_adpt.h
Someone at DTC will have to comment on whether or not something used
by MET v6.0 is missing from any of these directories.
Also, I need to make a clarification:
HDF4 is required 1) to build HDFEOS and 2) to build MET. HDF5 is
required 1) to build NetCDF and 2) to run MET. Once NetcDF4 is built,
there is NO dependency between MET and HDF5 at compile time. But there
is a runtime dependency with HDF5. That's why there are two
environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
variable needs to be set to where HDF4 is located to build MET.
I don’t have HDF4 installed. I tried to install it the other day but
experienced compilation errors. Sounds like I need to try again, if
it’s necessary to build MET. However, if I don’t intend to use MODIS-
Regrid, do I still need to install HDF4? I got the impression that
this is optional:
"The
<http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs>
HDF<http://www.hdfgroup.org/ftp/HDF/releases/HDF4.2r3/src/HDF4.2r3.tar.gz>
and HDF-
EOS<ftp://edhs1.gsfc.nasa.gov/edhs/hdfeos/previous_releases/HDF-
EOS2.16v1.00.tar.Z> libraries for using the MODIS-Regrid tool
(optional)"
(Note that I tried configuring and compiling MET v6.0 after defining
$MET_HDF5, but that didn’t resolve the compiler problem:
In file included from nc_var_info.cc:24:0:
nc_utils.h:22:10: fatal error: netcdf: No such file or directory
#include <netcdf>
^~~~~~~~
compilation terminated.
Latest versions of config.log, make_install.log, and
src/libcode/vx_nc_util/Makefile are attached.
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Howard Soh
Time: Tue Jun 13 21:07:49 2017
NetCDF4 C was installed but NetCDF4 C++ did not.
- netcdf.h exists but not netcdf.
- libnetcdf.a exists but not libnetcdf_c++4.a or libnetcdf_c++4.so
The NetCDF C++ was not built. Based on the previous message (copied
below), NetCDF4 C seems to be compiled with "--disable-netcdf-4"
option.
I copied our NetCDF4 build instruction from the online tutorial:
Note: MET_LIB_DIR should be adjusted to point HDF5.
Prior to running the NetCDF configure script, users are encouraged to
explicitly specify the compilers to be used by setting the following
variables:
Set CC to the C compiler to be used: setenv CC /path/to/c/compiler
Set CXX to the C++ compiler to be used:setenv CXX
/path/to/c++/compiler
Set FC to the Fortran compiler to be used (not used by MET) or set
to an empty string ("") to disable:setenv FC ''
Set F90 to the Fortran90 to be used (not used by MET) or set to an
empty string ("") to disable:setenv F90 ''
Set MET_LIB_DIR to your installation directory.
Checklist for NetCDF4 C++ installation Files for NetCDF4 C:
$MET_NETCDF/include/netcdf.h
$MET_NETCDF/lib/libnetcdf.a
$MET_NETCDF/lib/libnetcdf.so
Files for NetCDF4 C++ (MET-6.0):
$MET_NETCDF/include/netcdf
$MET_NETCDF/lib/libnetcdf_c++4.a
$MET_NETCDF/lib/libnetcdf_c++4.so
Files to check NetCDF C++ if netcdf4 was disabled (not correct):
$MET_NETCDF/include/netcdf.hh
$MET_NETCDF/lib/libnetcdf_c++.a
$MET_NETCDF/lib/libnetcdf_c++.so
NetCDF-C
wget https://github.com/Unidata/netcdf-c/archive/v4.4.1.1.zip
unzip v4.4.1.1.zip
cd netcdf-c-4.4.1.1
./configure --prefix=${MET_LIB_DIR}/external_libs LDFLAGS=-
L${MET_LIB_DIR}/external_libs/lib CPPFLAGS=-
I${MET_LIB_DIR}/external_libs/include
make install
NetCDF-CXX
wget https://github.com/Unidata/netcdf-cxx4/archive/v4.3.0.tar.gz
tar -xvzf v4.3.0.tar.gz
cd netcdf-cxx4-4.3.0
./configure --prefix=${MET_LIB_DIR}/external_libs LDFLAGS=-
L${MET_LIB_DIR}/external_libs/lib CPPFLAGS=-
I${MET_LIB_DIR}/external_libs/include
make install
>From the previous message:
-------------- Copy start ------------
I deleted the NetCDF-C installation (v.4.4.1.1) that I’d created to
support MET v.6.0, installed zlib v.1.2.11, installed HDF5 v.1.8.18,
and reinstalled NetCDF v.4.4.1.1. I also installed NetCDF-Fortran
v.4.4.4, and I tried to install NetCDF-CXX4 v.4.3.0 (which the MET
v.6.0 tutorial, under
“Compilation<http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs>”,
says is a required library), but when I run “configure”, it keeps
issuing the error message: "configure: error: NetCDF must be built
with netCDF-4 enabled”, no matter what I’ve tried so far—the configure
command doesn’t understand arguments such as —enable-netcdf-4 or
—enable-cxx-4, both of which are suggested in the netCDF-CXX README
file.
Remember to perform a 'make clean' then re-run your config command
before rebuilding METv6.0.
I did this, then ran
configure --enable-hdf5 --enable-hdf5-file-tests CPPFLAGS="-
I${H5DIR}/include" LDFLAGS="-L${H5DIR}/lib" --prefix=$MET_LIB_DIR
-------------- Copy end ------------
Cheers,
Howard
On Tue Jun 13 18:12:50 2017, dempsey at sfsu.edu wrote:
>
> On Jun 13, 2017, at 3:45 PM, Minna Win via RT
> <met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
>
> A colleague has suggested that there is a missing header file at
> $MET_NETCDF/include or at $MET_NETCDFINC. Could you please check for
> the existence of NetCDF header files and library files?
>
> Minna,
>
> Here’s what resides in $MET_NETCDF/lib and $MET_NETCDF/include:
>
> wrf_cyclone% ls $MET_NETCDF/lib
> libnetcdf.11.dylib* libnetcdf.settings libnetcdff.la*
> libnetcdf.a libnetcdff.6.dylib* pkgconfig/
> libnetcdf.dylib@ libnetcdff.a
> libnetcdf.la* libnetcdff.dylib@
>
> wrf_cyclone% ls $MET_NETCDF/include
> netcdf.h netcdf_meta.h
> netcdf.inc netcdf_nc_data.mod
> netcdf.mod netcdf_nc_interfaces.mod
> netcdf_f03.mod netcdf_nf_data.mod
> netcdf_fortv2_c_interfaces.mod netcdf_nf_interfaces.mod
> netcdf_mem.h typesizes.mod
>
> And here is what is in $MET_HDF5/lib and $MET_HDF5/include:
>
> wrf_cyclone% ls $MET_HDF5
> bin/ include/ lib/ share/
> wrf_cyclone% ls $MET_HDF5/lib
> libhdf5.10.dylib* libhdf5.la* libhdf5_hl.a
> libhdf5.a libhdf5.settings libhdf5_hl.dylib@
> libhdf5.dylib@ libhdf5_hl.10.dylib* libhdf5_hl.la*
>
> wrf_cyclone% ls $MET_HDF5/include
> H5ACpublic.h H5FDdirect.h H5Fpublic.h H5PLpublic.h H5overflow.h
> H5Apublic.h H5FDfamily.h H5Gpublic.h H5PTpublic.h H5pubconf.h
> H5Cpublic.h H5FDlog.h H5IMpublic.h H5Ppublic.h H5public.h
> H5DOpublic.h H5FDmpi.h H5Ipublic.h H5Rpublic.h H5version.h
> H5DSpublic.h H5FDmpio.h H5LTpublic.h H5Spublic.h hdf5.h
> H5Dpublic.h H5FDmulti.h H5Lpublic.h H5TBpublic.h hdf5_hl.h
> H5Epubgen.h H5FDpublic.h H5MMpublic.h H5Tpublic.h
> H5Epublic.h H5FDsec2.h H5Opublic.h H5Zpublic.h
> H5FDcore.h H5FDstdio.h H5PLextern.h H5api_adpt.h
>
> Someone at DTC will have to comment on whether or not something used
> by MET v6.0 is missing from any of these directories.
>
>
> Also, I need to make a clarification:
>
> HDF4 is required 1) to build HDFEOS and 2) to build MET. HDF5 is
> required 1) to build NetCDF and 2) to run MET. Once NetcDF4 is
built,
> there is NO dependency between MET and HDF5 at compile time. But
there
> is a runtime dependency with HDF5. That's why there are two
> environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
> variable needs to be set to where HDF4 is located to build MET.
>
> I don’t have HDF4 installed. I tried to install it the other day but
> experienced compilation errors. Sounds like I need to try again, if
> it’s necessary to build MET. However, if I don’t intend to use
MODIS-
> Regrid, do I still need to install HDF4? I got the impression that
> this is optional:
>
> "The
>
<http://www.dtcenter.org/met/users/support/online_tutorial/METv6.0/tutorial.php?name=compilation&category=req_libs>
>
HDF<http://www.hdfgroup.org/ftp/HDF/releases/HDF4.2r3/src/HDF4.2r3.tar.gz>
> and HDF-
> EOS<ftp://edhs1.gsfc.nasa.gov/edhs/hdfeos/previous_releases/HDF-
> EOS2.16v1.00.tar.Z> libraries for using the MODIS-Regrid tool
> (optional)"
>
> (Note that I tried configuring and compiling MET v6.0 after defining
> $MET_HDF5, but that didn’t resolve the compiler problem:
>
> In file included from nc_var_info.cc:24:0:
> nc_utils.h:22:10: fatal error: netcdf: No such file or directory
> #include <netcdf>
> ^~~~~~~~
> compilation terminated.
>
> Latest versions of config.log, make_install.log, and
> src/libcode/vx_nc_util/Makefile are attached.
>
> — Dave
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Tue Jun 13 21:50:38 2017
On Jun 13, 2017, at 3:45 PM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
A colleague has suggested that there is a missing header file at
$MET_NETCDF/include or at $MET_NETCDFINC.
Could you please check for the existence of NetCDF header files and
library
files? Also, I need to make a clarification:
HDF4 is required 1) to build HDFEOS and 2) to build MET.
HDF5 is required 1) to build NetCDF and 2) to run MET. Once NetcDF4 is
built, there is NO dependency between MET and HDF5 at compile time.
But there is a runtime dependency with HDF5. That's why there are two
environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
variable
needs to be set to where HDF4 is
located to build MET.
Minna,
I managed to install HDF4 v.4.2r3, and I reinstalled HDF5 v.1.8.18,
NetCDF-C v.4.4.1.1, and NETCDF-C++ v.4.3.0 (in that order), apparently
successfully.
I then attempted to install MET v.6.0 again (starting with “make
clean” and “configure —prefix=`pwd` —enable-grib2”, then “make”, which
went a lot farther than before and didn’t produce the same error as
before. However, there were new compilation errors. All of them are in
src/libcode/vx_statistics/compute_ci.cc and all involve “invalid
conversion from ‘char’ to ‘const char*’ when trying to create a
temporary file name by prepending a “0” to an existing file name.
I’m not a C programmer, and although I can sometimes grope my way
through C codes to fix errors, I don’t know what to do about this
particular error.
However, this does feel like progress!
The latest config.log and make_install.log files are attached.
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Thu Jun 15 12:27:04 2017
Hello Dr. Dempsey,
I suspect that the latest error you are observing may be due to a
compiler
issue. I'm consulting with our MET expert to see if this is the case.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Wed, Jun 14, 2017 at 3:50 AM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 13, 2017, at 3:45 PM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello Dr. Dempsey,
>
> A colleague has suggested that there is a missing header file at
> $MET_NETCDF/include or at $MET_NETCDFINC.
> Could you please check for the existence of NetCDF header files and
library
> files? Also, I need to make a clarification:
>
> HDF4 is required 1) to build HDFEOS and 2) to build MET.
> HDF5 is required 1) to build NetCDF and 2) to run MET. Once NetcDF4
is
> built, there is NO dependency between MET and HDF5 at compile time.
> But there is a runtime dependency with HDF5. That's why there are
two
> environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
variable
> needs to be set to where HDF4 is
> located to build MET.
>
> Minna,
>
> I managed to install HDF4 v.4.2r3, and I reinstalled HDF5 v.1.8.18,
> NetCDF-C v.4.4.1.1, and NETCDF-C++ v.4.3.0 (in that order),
apparently
> successfully.
>
> I then attempted to install MET v.6.0 again (starting with “make
clean”
> and “configure —prefix=`pwd` —enable-grib2”, then “make”, which went
a lot
> farther than before and didn’t produce the same error as before.
However,
> there were new compilation errors. All of them are in
> src/libcode/vx_statistics/compute_ci.cc and all involve “invalid
> conversion from ‘char’ to ‘const char*’ when trying to create a
temporary
> file name by prepending a “0” to an existing file name.
>
> I’m not a C programmer, and although I can sometimes grope my way
through
> C codes to fix errors, I don’t know what to do about this particular
error.
>
> However, this does feel like progress!
>
> The latest config.log and make_install.log files are attached.
>
> — Dave
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Thu Jun 15 16:34:24 2017
Hello Dr. Dempsey,
Do you have access to an earlier version of the GCC compiler? We
haven't
tested METv6.0 with your compiler, which, according to your config log
is
7.1- we know that the 4.9 series works for building MET.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Thu, Jun 15, 2017 at 6:26 PM, Minna Win-Gildenmeister
<minnawin at ucar.edu>
wrote:
> Hello Dr. Dempsey,
>
> I suspect that the latest error you are observing may be due to a
compiler
> issue. I'm consulting with our MET expert to see if this is the
case.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423 <(303)%20497-8423>
> Fax: 302-497-8401 <(302)%20497-8401>
>
>
> On Wed, Jun 14, 2017 at 3:50 AM, David P Dempsey via RT
<met_help at ucar.edu
> > wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>>
>>
>> On Jun 13, 2017, at 3:45 PM, Minna Win via RT
<met_help at ucar.edu<mailto:
>> met_help at ucar.edu>> wrote:
>>
>> Hello Dr. Dempsey,
>>
>> A colleague has suggested that there is a missing header file at
>> $MET_NETCDF/include or at $MET_NETCDFINC.
>> Could you please check for the existence of NetCDF header files and
>> library
>> files? Also, I need to make a clarification:
>>
>> HDF4 is required 1) to build HDFEOS and 2) to build MET.
>> HDF5 is required 1) to build NetCDF and 2) to run MET. Once NetcDF4
is
>> built, there is NO dependency between MET and HDF5 at compile time.
>> But there is a runtime dependency with HDF5. That's why there are
two
>> environment variables: MET_HDF and MET_HDF5. So the MET_HDF env
variable
>> needs to be set to where HDF4 is
>> located to build MET.
>>
>> Minna,
>>
>> I managed to install HDF4 v.4.2r3, and I reinstalled HDF5 v.1.8.18,
>> NetCDF-C v.4.4.1.1, and NETCDF-C++ v.4.3.0 (in that order),
apparently
>> successfully.
>>
>> I then attempted to install MET v.6.0 again (starting with “make
clean”
>> and “configure —prefix=`pwd` —enable-grib2”, then “make”, which
went a lot
>> farther than before and didn’t produce the same error as before.
However,
>> there were new compilation errors. All of them are in
>> src/libcode/vx_statistics/compute_ci.cc and all involve “invalid
>> conversion from ‘char’ to ‘const char*’ when trying to create a
temporary
>> file name by prepending a “0” to an existing file name.
>>
>> I’m not a C programmer, and although I can sometimes grope my way
through
>> C codes to fix errors, I don’t know what to do about this
particular error.
>>
>> However, this does feel like progress!
>>
>> The latest config.log and make_install.log files are attached.
>>
>> — Dave
>>
>>
>>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Sat Jun 17 00:27:07 2017
On Jun 15, 2017, at 3:34 PM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
Do you have access to an earlier version of the GCC compiler? We
haven't
tested METv6.0 with your compiler, which, according to your config log
is
7.1- we know that the 4.9 series works for building MET.
Minna,
I did the following:
— Installed gcc v.4.9.2 (in a separate location from gcc v.7.1)
— Set CC, FC, CXX, etc. to employ the v.4.9.2 versions of gcc,
gfortran, and g++
— Tried to compile MET v.6.0, but this failed. Thinking that this
might be due to the fact that the supporting libraries were all
compiled using gcc v.7.1, I tried recompiling some of those libraries.
— Recompiled zlib (v.1.2.11)
— Recompiled JPEG (v.6b).
— Recompiled HDF4 (v.4.2r3)
— Tried to recompile HDF5 (v.1.8.18), but this failed after many
warnings. The compiler errors look like variations of this:
/var/folders/dg/p8pgc1jd7fs7ls9t8dmz8ntm00009d/T//ccndwNxO.s:62093:2:
error: ambiguous instructions require an explicit suffix (could be
'filds', or 'fildl')
fild (%rsp)
^
So, kept HDF5 that I’d compiled using gcc v.7.1 instead.
— Tried to recompile NetCDF (v.4.4.1.1), but running "configure
--enable-hdf4 --enable-hdf4-file-tests” produced the error: "Can't
find or link to the hdf4 df library.” These seemed to be related to
JPEG, so tried explicitly pointing to the JPEG v.6b library directory
(and also the JPEG include directory), but that didn’t change
anything.
So, kept NetCDF that I’d compiled using gcc v.7.1 instead.
— Tried to compile MET v.6.0. This failed with undefined symbols.
(I’ve attached the config.log and make.log files for this attempt.)
Trying to compile MET with a mixed set of libraries compiled using
different versions of gcc might be a non-starter.
How hard would it be to try to fix the benign-looking compiler error
in MET software that gcc v.7.1 produced, and go from there?
— Dave
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Mon Jun 19 14:23:08 2017
Hello Dr. Dempsey,
I'm sorry to hear that an earlier version of the gcc compiler did not
work
for you. The gcc7.1 compiler you initially used is quite recent and we
didn't have access to it. There are numerous combinations of
compilers and
operating systems in use by MET users and we try our best to test on
as
many combinations that are available to us. I created a MET ticket to
test
the installation with gcc 7.1 on future MET releases. We are in the
process of making another MET release. I'll need to see whether we
can get
this version of the GNU compiler tested with this upcoming release.
Thank you for you diligence and patience with this issue.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Sat, Jun 17, 2017 at 6:27 AM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 15, 2017, at 3:34 PM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello Dr. Dempsey,
>
> Do you have access to an earlier version of the GCC compiler? We
haven't
> tested METv6.0 with your compiler, which, according to your config
log is
> 7.1- we know that the 4.9 series works for building MET.
>
> Minna,
>
> I did the following:
>
> — Installed gcc v.4.9.2 (in a separate location from gcc v.7.1)
>
> — Set CC, FC, CXX, etc. to employ the v.4.9.2 versions of gcc,
gfortran,
> and g++
>
> — Tried to compile MET v.6.0, but this failed. Thinking that this
might be
> due to the fact that the supporting libraries were all compiled
using gcc
> v.7.1, I tried recompiling some of those libraries.
>
> — Recompiled zlib (v.1.2.11)
>
> — Recompiled JPEG (v.6b).
>
> — Recompiled HDF4 (v.4.2r3)
>
> — Tried to recompile HDF5 (v.1.8.18), but this failed after many
warnings.
> The compiler errors look like variations of this:
>
>
/var/folders/dg/p8pgc1jd7fs7ls9t8dmz8ntm00009d/T//ccndwNxO.s:62093:2:
> error: ambiguous instructions require an explicit suffix (could be
'filds',
> or 'fildl')
> fild (%rsp)
> ^
>
> So, kept HDF5 that I’d compiled using gcc v.7.1 instead.
>
> — Tried to recompile NetCDF (v.4.4.1.1), but running "configure
> --enable-hdf4 --enable-hdf4-file-tests” produced the error: "Can't
find or
> link to the hdf4 df library.” These seemed to be related to JPEG, so
tried
> explicitly pointing to the JPEG v.6b library directory (and also the
JPEG
> include directory), but that didn’t change anything.
>
> So, kept NetCDF that I’d compiled using gcc v.7.1 instead.
>
> — Tried to compile MET v.6.0. This failed with undefined symbols.
(I’ve
> attached the config.log and make.log files for this attempt.)
>
>
> Trying to compile MET with a mixed set of libraries compiled using
> different versions of gcc might be a non-starter.
>
> How hard would it be to try to fix the benign-looking compiler error
in
> MET software that gcc v.7.1 produced, and go from there?
>
> — Dave
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Mon Jun 19 14:51:26 2017
Hello Dr. Dempsey,
Since you are still experiencing issues with building MET v6.0,
perhaps you
might be interested in accessing METv6.0 through our Docker container?
You
will need to install Docker for your Mac. If you are interested,
please
refer to the following link for instructions:
http://www.dtcenter.org/met/users/support/online_tutorial/ncwcp_201704.php
The information is located near the bottom of the page (we will need
to
move this to a more conspicuous area in the tutorial). Please let us
know
if you encounter any issues should you decide to access METv6.0 in
this
manner.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Mon, Jun 19, 2017 at 8:22 PM, Minna Win-Gildenmeister
<minnawin at ucar.edu>
wrote:
> Hello Dr. Dempsey,
>
> I'm sorry to hear that an earlier version of the gcc compiler did
not work
> for you. The gcc7.1 compiler you initially used is quite recent and
we
> didn't have access to it. There are numerous combinations of
compilers and
> operating systems in use by MET users and we try our best to test on
as
> many combinations that are available to us. I created a MET ticket
to test
> the installation with gcc 7.1 on future MET releases. We are in the
> process of making another MET release. I'll need to see whether we
can get
> this version of the GNU compiler tested with this upcoming release.
>
> Thank you for you diligence and patience with this issue.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423 <(303)%20497-8423>
> Fax: 302-497-8401 <(302)%20497-8401>
>
>
> On Sat, Jun 17, 2017 at 6:27 AM, David P Dempsey via RT
<met_help at ucar.edu
> > wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>>
>>
>> On Jun 15, 2017, at 3:34 PM, Minna Win via RT
<met_help at ucar.edu<mailto:
>> met_help at ucar.edu>> wrote:
>>
>> Hello Dr. Dempsey,
>>
>> Do you have access to an earlier version of the GCC compiler? We
haven't
>> tested METv6.0 with your compiler, which, according to your config
log is
>> 7.1- we know that the 4.9 series works for building MET.
>>
>> Minna,
>>
>> I did the following:
>>
>> — Installed gcc v.4.9.2 (in a separate location from gcc v.7.1)
>>
>> — Set CC, FC, CXX, etc. to employ the v.4.9.2 versions of gcc,
gfortran,
>> and g++
>>
>> — Tried to compile MET v.6.0, but this failed. Thinking that this
might
>> be due to the fact that the supporting libraries were all compiled
using
>> gcc v.7.1, I tried recompiling some of those libraries.
>>
>> — Recompiled zlib (v.1.2.11)
>>
>> — Recompiled JPEG (v.6b).
>>
>> — Recompiled HDF4 (v.4.2r3)
>>
>> — Tried to recompile HDF5 (v.1.8.18), but this failed after many
>> warnings. The compiler errors look like variations of this:
>>
>>
/var/folders/dg/p8pgc1jd7fs7ls9t8dmz8ntm00009d/T//ccndwNxO.s:62093:2:
>> error: ambiguous instructions require an explicit suffix (could be
'filds',
>> or 'fildl')
>> fild (%rsp)
>> ^
>>
>> So, kept HDF5 that I’d compiled using gcc v.7.1 instead.
>>
>> — Tried to recompile NetCDF (v.4.4.1.1), but running "configure
>> --enable-hdf4 --enable-hdf4-file-tests” produced the error: "Can't
find or
>> link to the hdf4 df library.” These seemed to be related to JPEG,
so tried
>> explicitly pointing to the JPEG v.6b library directory (and also
the JPEG
>> include directory), but that didn’t change anything.
>>
>> So, kept NetCDF that I’d compiled using gcc v.7.1 instead.
>>
>> — Tried to compile MET v.6.0. This failed with undefined symbols.
(I’ve
>> attached the config.log and make.log files for this attempt.)
>>
>>
>> Trying to compile MET with a mixed set of libraries compiled using
>> different versions of gcc might be a non-starter.
>>
>> How hard would it be to try to fix the benign-looking compiler
error in
>> MET software that gcc v.7.1 produced, and go from there?
>>
>> — Dave
>>
>>
>>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Wed Jun 21 11:44:57 2017
On Jun 19, 2017, at 1:51 PM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
Since you are still experiencing issues with building MET v6.0,
perhaps you
might be interested in accessing METv6.0 through our Docker container?
Minna,
Thanks for the suggestion—it adds another avenue to explore. The
options as I see them:
(1) Try to get MET v.6.0 to compile and install using gcc v.4.9. [That
looks daunting on my machine.]
(2) See if my MET v.4.1 executables compiled under Mac OS X v.10.6
(Snow Leopard) will run on my new machine under Mac OS X v.10.12.5
(Sierra) and forego any of the new features and (any) other changes in
MET v.6.0. [For my purposes, that might be sufficient, though I’d
prefer to keep my software up to date if I can.]
(3) Set up a Docker container and run MET v.6.0 from that. [I’ve
played around a little bit with Docker in another context, but I felt
a little out of my depth and didn’t manage to get it to do what I
wanted to. That previous experience might or might not be relevant to
running MET v.6.0 using Docker, though.]
(4) Try to get MET v.6.0 to compile and install using gcc v.7.1. [I
took a deep breath, and although I am not a C++ programmer (my
training is in Fortran and c-shell and Bourne shell scripting), I made
a guess about fixing the syntax error on which gcc v.7.1 choked, and
it worked, and I’ve now got a set of MET v.6.0 binaries.]
The syntax errors that gcc v.7.1 flagged were in
src/libcode/vx_statistics/compute_ci.cc, and they were all the same:
Making all in vx_statistics
.
.
.
compute_ci.cc:351:55: error: invalid conversion from ‘char’ to
‘const char*’ [-fpermissive]
cts_r_file[i] = make_temp_file_name(prefix, '\0');
.
.
.
../../../src/basic/vx_util/temp_file.h:20:21: note:
initializing argument 2 of ‘ConcatString make_temp_file_name(const
char*, const char*)’
extern ConcatString make_temp_file_name(const char *, const char
*);
^~~~~~~~~~~~~~~~~~~
compute_ci.cc: In function ‘void compute_mcts_stats_ci_bca(const
gsl_rng*, const NumArray&, const NumArray&, int, MCTSInfo&, int, int,
const char*)’:
I changed ‘\0’ to “\0” wherever it appeared in the call to
make_temp_file_name, and all of the errors went away.
The same error popped up in
src/tools/core/stat_analysis/stat_analysis.cc and in
src/tools/other/pb2nc/pb2nc.cc<http://pb2nc.cc> (once each), and the
fix is the same.
That’s all it took to compile and install. Now we’ll see if there are
any obvious run time problems.
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
) ) ) ~ ~ ~ ~ *
***************************************************************
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Wed Jun 21 12:10:26 2017
Hello Dr. Dempsey,
I'm glad you got past the errors within vx_statistics and hope you
don't
run into any problems while trying to run MET. Please don't hesitate
to
contact us if you experience any further problems or have any
questions.
Thank you for your diligence and patience in installing MET.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Wed, Jun 21, 2017 at 5:44 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 19, 2017, at 1:51 PM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello Dr. Dempsey,
>
> Since you are still experiencing issues with building MET v6.0,
perhaps you
> might be interested in accessing METv6.0 through our Docker
container?
>
> Minna,
>
> Thanks for the suggestion—it adds another avenue to explore. The
options
> as I see them:
>
> (1) Try to get MET v.6.0 to compile and install using gcc v.4.9.
[That
> looks daunting on my machine.]
>
> (2) See if my MET v.4.1 executables compiled under Mac OS X v.10.6
(Snow
> Leopard) will run on my new machine under Mac OS X v.10.12.5
(Sierra) and
> forego any of the new features and (any) other changes in MET v.6.0.
[For
> my purposes, that might be sufficient, though I’d prefer to keep my
> software up to date if I can.]
>
> (3) Set up a Docker container and run MET v.6.0 from that. [I’ve
played
> around a little bit with Docker in another context, but I felt a
little out
> of my depth and didn’t manage to get it to do what I wanted to. That
> previous experience might or might not be relevant to running MET
v.6.0
> using Docker, though.]
>
> (4) Try to get MET v.6.0 to compile and install using gcc v.7.1. [I
took a
> deep breath, and although I am not a C++ programmer (my training is
in
> Fortran and c-shell and Bourne shell scripting), I made a guess
about
> fixing the syntax error on which gcc v.7.1 choked, and it worked,
and I’ve
> now got a set of MET v.6.0 binaries.]
>
> The syntax errors that gcc v.7.1 flagged were in
src/libcode/vx_statistics/compute_ci.cc,
> and they were all the same:
>
> Making all in vx_statistics
> .
> .
> .
> compute_ci.cc:351:55: error: invalid conversion from ‘char’ to
‘const
> char*’ [-fpermissive]
> cts_r_file[i] = make_temp_file_name(prefix, '\0');
> .
> .
> .
> ../../../src/basic/vx_util/temp_file.h:20:21: note:
initializing
> argument 2 of ‘ConcatString make_temp_file_name(const char*, const
char*)’
> extern ConcatString make_temp_file_name(const char *, const
char *);
> ^~~~~~~~~~~~~~~~~~~
> compute_ci.cc: In function ‘void compute_mcts_stats_ci_bca(const
> gsl_rng*, const NumArray&, const NumArray&, int, MCTSInfo&, int,
int, const
> char*)’:
>
> I changed ‘\0’ to “\0” wherever it appeared in the call to
> make_temp_file_name, and all of the errors went away.
>
> The same error popped up in
src/tools/core/stat_analysis/stat_analysis.cc
> and in src/tools/other/pb2nc/pb2nc.cc<http://pb2nc.cc> (once each),
and
> the fix is the same.
>
> That’s all it took to compile and install. Now we’ll see if there
are any
> obvious run time problems.
>
> — Dave
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
)
> ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Wed Jun 21 15:47:22 2017
On Jun 21, 2017, at 11:10 AM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello Dr. Dempsey,
I'm glad you got past the errors within vx_statistics and hope you
don't
run into any problems while trying to run MET. Please don't hesitate
to
contact us if you experience any further problems or have any
questions.
Thank you for your diligence and patience in installing MET.
Minna,
Sadly, successful compilation doesn’t always imply successful running.
I’m testing my newly compiled MET v6.0 version of point_stat and
getting warnings and an error. Among other things, I’m providing on
the command line an explicit path to a configuration file, but
point_stat seems to ignore it. (All of the files and the directory
referred to on the command line exist.)
wrf_cyclone% echo $MET_BASE
/Users/wrf/WRF/METV6.0
wrf_cyclone% $MET_BASE/bin/point_stat /data/wrf/postprd/WRFPRS_2017-
06-19_00_NAM_CenCal.06.grb /data/wrf/obs/20170619_0600.met.nc
$MET_BASE/scripts/config/PointStatConfig -point_obs
/data/wrf/obs/20170619_0500.met.nc -outdir /data/wrf/stats/20170619 -v
2
WARNING:
WARNING: get_filenames() -> can't stat
"/Users/wrf/WRF/METV6.0/table_files"
WARNING:
WARNING:
WARNING: get_filenames() -> can't stat
"/Users/wrf/WRF/METV6.0/table_files"
WARNING:
ERROR :
ERROR : MetConfig::read(const char *) -> unable to open input file
"/Users/wrf/WRF/METV6.0/config/ConfigConstants"
ERROR :
“ConfigConstants" actually resides in two directories:
$MET_BASE/data/config and $MET_BASE/share/met/config, both of which
are default locations.
“table_files" also resides in two directories: $MET_BASE/data and in
$MET_BASE/share/met, also default locations.
Why would point_stat look in the wrong places for table_files and
ConfigConstants? How should I tell point_stat where these files
actually reside? (In a pinch, I could move the files to the locations
where point_stat looks for them, but that would be clunky.)
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
) ) ) ~ ~ ~ ~ *
***************************************************************
------------------------------------------------
Subject: MET v6.0 compilation problem
From: John Halley Gotway
Time: Wed Jun 21 16:58:08 2017
Hello,
This is John Halley Gotway. I work on MET development and support
with
Minna.
The short answer is this... just unset the MET_BASE environment
variable
and try again.
The long answer is this...
When you run the configure script and then compile MET, it keeps track
of
the path where you installed it, lets call that MET_INSTALL_DIR.
Following
conventions used by autoconf, the data files needed by MET are copied
in
MET_INSTALL_DIR/share/met and MET_BASE is defined as MET_BASE =
MET_INSTALL_DIR/share/met.
If you install MET and run it, it'll look for files in the MET_BASE
location defined at compilation time. But if you set the MET_BASE
environment variable, it'll look in the new location you've defined.
So there are really two options. Either unset MET_BASE or set it
correctly. And the only reason why you'd need to set it is if you
*move*
MET from it's installed location to some other location.
Hope that helps clarify.
Thanks,
John
On Wed, Jun 21, 2017 at 3:47 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 21, 2017, at 11:10 AM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello Dr. Dempsey,
>
> I'm glad you got past the errors within vx_statistics and hope you
don't
> run into any problems while trying to run MET. Please don't
hesitate to
> contact us if you experience any further problems or have any
questions.
> Thank you for your diligence and patience in installing MET.
>
>
> Minna,
>
> Sadly, successful compilation doesn’t always imply successful
running.
>
> I’m testing my newly compiled MET v6.0 version of point_stat and
getting
> warnings and an error. Among other things, I’m providing on the
command
> line an explicit path to a configuration file, but point_stat seems
to
> ignore it. (All of the files and the directory referred to on the
command
> line exist.)
>
> wrf_cyclone% echo $MET_BASE
> /Users/wrf/WRF/METV6.0
>
> wrf_cyclone% $MET_BASE/bin/point_stat /data/wrf/postprd/WRFPRS_2017-
06-19_00_NAM_CenCal.06.grb
> /data/wrf/obs/20170619_0600.met.nc
$MET_BASE/scripts/config/PointStatConfig
> -point_obs /data/wrf/obs/20170619_0500.met.nc -outdir
> /data/wrf/stats/20170619 -v 2
>
> WARNING:
> WARNING: get_filenames() -> can't stat
"/Users/wrf/WRF/METV6.0/table_
> files"
> WARNING:
> WARNING:
> WARNING: get_filenames() -> can't stat
"/Users/wrf/WRF/METV6.0/table_
> files"
> WARNING:
> ERROR :
> ERROR : MetConfig::read(const char *) -> unable to open input file
> "/Users/wrf/WRF/METV6.0/config/ConfigConstants"
> ERROR :
>
> “ConfigConstants" actually resides in two directories:
> $MET_BASE/data/config and $MET_BASE/share/met/config, both of which
are
> default locations.
>
> “table_files" also resides in two directories: $MET_BASE/data and in
> $MET_BASE/share/met, also default locations.
>
> Why would point_stat look in the wrong places for table_files and
> ConfigConstants? How should I tell point_stat where these files
actually
> reside? (In a pinch, I could move the files to the locations where
> point_stat looks for them, but that would be clunky.)
>
> — Dave
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
)
> ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Wed Jun 21 17:27:15 2017
On Jun 21, 2017, at 3:58 PM, John Halley Gotway via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
The short answer is this... just unset the MET_BASE environment
variable and try again.
.
.
.
So there are really two options. Either unset MET_BASE or set it
correctly. And the only reason why you'd need to set it is if you
*move* MET from it's installed location to some other location.
John,
Thanks for the response. Both solutions do indeed seem to work. It
might have taken me a very long time to figure that out myself (if
ever). :-)
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
) ) ) ~ ~ ~ ~ *
***************************************************************
------------------------------------------------
Subject: MET v6.0 compilation problem
From: John Halley Gotway
Time: Wed Jun 21 17:30:56 2017
Great, glad that did the trick. Lots of little details here.
Please let us know what other questions or suggestions you have.
Thanks,
John
On Wed, Jun 21, 2017 at 5:27 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 21, 2017, at 3:58 PM, John Halley Gotway via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>> wrote:
>
> The short answer is this... just unset the MET_BASE environment
variable
> and try again.
> .
> .
> .
> So there are really two options. Either unset MET_BASE or set it
> correctly. And the only reason why you'd need to set it is if you
*move*
> MET from it's installed location to some other location.
>
> John,
>
> Thanks for the response. Both solutions do indeed seem to work. It
might
> have taken me a very long time to figure that out myself (if ever).
:-)
>
> — Dave
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
)
> ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Wed Jun 28 08:06:45 2017
Hello,
It appears that your issues have been resolved. We will be closing
this help ticket. If you have any further issues, please do not
hesitate to open another MET Help ticket.
Regards,
Minna
On Wed Jun 21 17:27:15 2017, dempsey at sfsu.edu wrote:
>
> On Jun 21, 2017, at 3:58 PM, John Halley Gotway via RT
> <met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
>
> The short answer is this... just unset the MET_BASE environment
> variable and try again.
> .
> .
> .
> So there are really two options. Either unset MET_BASE or set it
> correctly. And the only reason why you'd need to set it is if you
> *move* MET from it's installed location to some other location.
>
> John,
>
> Thanks for the response. Both solutions do indeed seem to work. It
> might have taken me a very long time to figure that out myself (if
> ever). :-)
>
> — Dave
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
> ) ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
------------------------------------------------
Subject: MET v6.0 compilation problem
From: David P Dempsey
Time: Wed Jun 28 10:57:50 2017
On Jun 28, 2017, at 7:06 AM, Minna Win via RT
<met_help at ucar.edu<mailto:met_help at ucar.edu>> wrote:
Hello,
It appears that your issues have been resolved. We will be closing
this help ticket. If you have any further issues, please do not
hesitate to open another MET Help ticket.
Minna,
My issues are resolved for the time being—thanks very much for the
responsive help.
FYI, with a couple of tweaks, I managed to get UPP v.2.1 to compile
under Mac OS X v.10.12.5 (Sierra), using gcc v.7.1. However, I was
compiling a version of the UPP v.2.1 code that I had to hack
extensively several years ago to compile under Mac OS X v.10.6 (Snow
Leopard) using gcc v.4.9, so my most recent success in getting UPP
v.2.1 to compile simply says that the additional hacks need are small,
not that extensive hacking of the original distributed code isn’t
necessary. This would no doubt be true of the latest version of UPP,
too.
— Dave
***************************************************************
* Dr. Dave Dempsey, Chair | ^ ___ \|/ *
* Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
* San Francisco State University | ) ) / ||_|| \ /|\ *
* 1600 Holloway Ave. | ) ) / ||_|| \ *
* San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
* | ) ) ) ||_|| \ *
* Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
* FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
* Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
) ) ) ~ ~ ~ ~ *
***************************************************************
------------------------------------------------
Subject: MET v6.0 compilation problem
From: Minna Win
Time: Wed Jun 28 11:05:36 2017
Hello,
Thanks for this valuable information. We'll most likely need this
when we
finally get access to the gccv7.1 compiler.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Wed, Jun 28, 2017 at 4:57 PM, David P Dempsey via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80828 >
>
>
> On Jun 28, 2017, at 7:06 AM, Minna Win via RT
<met_help at ucar.edu<mailto:
> met_help at ucar.edu>> wrote:
>
> Hello,
>
> It appears that your issues have been resolved. We will be closing
this
> help ticket. If you have any further issues, please do not hesitate
to
> open another MET Help ticket.
>
> Minna,
>
> My issues are resolved for the time being—thanks very much for the
> responsive help.
>
> FYI, with a couple of tweaks, I managed to get UPP v.2.1 to compile
under
> Mac OS X v.10.12.5 (Sierra), using gcc v.7.1. However, I was
compiling a
> version of the UPP v.2.1 code that I had to hack extensively several
years
> ago to compile under Mac OS X v.10.6 (Snow Leopard) using gcc v.4.9,
so my
> most recent success in getting UPP v.2.1 to compile simply says that
the
> additional hacks need are small, not that extensive hacking of the
original
> distributed code isn’t necessary. This would no doubt be true of the
latest
> version of UPP, too.
>
> — Dave
>
>
> ***************************************************************
> * Dr. Dave Dempsey, Chair | ^ ___ \|/ *
> * Dept. of Earth & Climate Sciences | ) ^ /||_||\ —-0—- *
> * San Francisco State University | ) ) / ||_|| \ /|\ *
> * 1600 Holloway Ave. | ) ) / ||_|| \ *
> * San Francisco, CA 94132 | ) ) / ||_|| \ ^ *
> * | ) ) ) ||_|| \ *
> * Phone: (415) 338-7716 | ) ) )~~||~||~~~~~\~~ *
> * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~ *
> * Email: dempsey at sfsu.edu<mailto:dempsey at sfsu.edu> | ) )
)
> ) ) ~ ~ ~ ~ *
> ***************************************************************
>
>
>
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list