[Met_help] [rt.rap.ucar.edu #96356] History for Unable to compile MET-9.1 with grib2 enabled
Julie Prestopnik via RT
met_help at ucar.edu
Mon Sep 21 15:54:30 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi:
I'm attempting to compile MET-9.1 on a linux machine under Fedora 31
with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
My build syntax is ./configure --prefix=/work/models/MET/met
--enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3 without
--enable-grib2 generates 33 of the 36 executables)
The error messages are ....
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
undefined reference to `g2_free'
/bin/ld:
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-data2d_grib2.o):
in function `MetGrib2DataFile::read_grib2_record_dat
Similar undefined references in trying to compile the code
"data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info', and
'g2_getfld'.
I've confirmed that libgrib2c.a (683774 Aug 19 13:10 libgrib2c.a) is
produced.
Can you supply some tips on how to move foreard?
Thanks,
T. W. Tesche
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: George McCabe
Time: Wed Aug 19 15:09:33 2020
Hi,
I see you are having issues installing MET with grib2 enabled. I
assigned
this ticket to Julie Prestopnik. Please allow a few business days for
a
response.
Thanks,
George
On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu> wrote:
>
> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
> Transaction: Ticket created by twt at iac.net
> Queue: met_help
> Subject: Unable to compile MET-9.1 with grib2 enabled
> Owner: Nobody
> Requestors: twt at iac.net
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>
>
> Hi:
>
> I'm attempting to compile MET-9.1 on a linux machine under Fedora 31
> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>
> My build syntax is ./configure --prefix=/work/models/MET/met
> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3 without
> --enable-grib2 generates 33 of the 36 executables)
>
> The error messages are ....
>
>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
> undefined reference to `g2_free'
> /bin/ld:
>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>
> in function `MetGrib2DataFile::read_grib2_record_dat
>
> Similar undefined references in trying to compile the code
> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info', and
> 'g2_getfld'.
>
> I've confirmed that libgrib2c.a (683774 Aug 19 13:10 libgrib2c.a)
is
> produced.
>
> Can you supply some tips on how to move foreard?
>
> Thanks,
>
> T. W. Tesche
>
>
>
>
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: Julie Prestopnik
Time: Wed Aug 19 15:53:38 2020
Hi.
I see that you are having trouble compiling MET-9.1 due to an issue
with
g2clib. Thank you for sending along your install.log file! I would
also
like to take a look at your config.log file. Could you please reply
with
that file attached.
I typically compile using the Intel or GNU family of compilers. If
your config.log file doesn't shed any light on the situation, I will
try to
reproduce the problem that you are experiencing and will follow up
once I
know more.
Julie
On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu> wrote:
>
> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
> Transaction: Ticket created by twt at iac.net
> Queue: met_help
> Subject: Unable to compile MET-9.1 with grib2 enabled
> Owner: Nobody
> Requestors: twt at iac.net
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>
>
> Hi:
>
> I'm attempting to compile MET-9.1 on a linux machine under Fedora 31
> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>
> My build syntax is ./configure --prefix=/work/models/MET/met
> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3 without
> --enable-grib2 generates 33 of the 36 executables)
>
> The error messages are ....
>
>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
> undefined reference to `g2_free'
> /bin/ld:
>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>
> in function `MetGrib2DataFile::read_grib2_record_dat
>
> Similar undefined references in trying to compile the code
> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info', and
> 'g2_getfld'.
>
> I've confirmed that libgrib2c.a (683774 Aug 19 13:10 libgrib2c.a)
is
> produced.
>
> Can you supply some tips on how to move foreard?
>
> Thanks,
>
> T. W. Tesche
>
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: twt
Time: Wed Aug 19 16:35:47 2020
Hi Julie:
I've attached the config.log and configure.log files for your review.
Also attached is my .cshrc file if this would be of any help.
I appreciate your looking into this issue with me.
Tom
On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
> Hi.
>
> I see that you are having trouble compiling MET-9.1 due to an issue
with
> g2clib. Thank you for sending along your install.log file! I would
also
> like to take a look at your config.log file. Could you please reply
with
> that file attached.
>
> I typically compile using the Intel or GNU family of compilers. If
> your config.log file doesn't shed any light on the situation, I will
try to
> reproduce the problem that you are experiencing and will follow up
once I
> know more.
>
> Julie
>
>
> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
wrote:
>
>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>> Transaction: Ticket created by twt at iac.net
>> Queue: met_help
>> Subject: Unable to compile MET-9.1 with grib2 enabled
>> Owner: Nobody
>> Requestors: twt at iac.net
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>
>>
>> Hi:
>>
>> I'm attempting to compile MET-9.1 on a linux machine under Fedora
31
>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>>
>> My build syntax is ./configure --prefix=/work/models/MET/met
>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
>> --enable-grib2 generates 33 of the 36 executables)
>>
>> The error messages are ....
>>
>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>> undefined reference to `g2_free'
>> /bin/ld:
>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>>
>> in function `MetGrib2DataFile::read_grib2_record_dat
>>
>> Similar undefined references in trying to compile the code
>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info', and
>> 'g2_getfld'.
>>
>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a) is
>> produced.
>>
>> Can you supply some tips on how to move foreard?
>>
>> Thanks,
>>
>> T. W. Tesche
>>
>>
>>
>>
>>
>>
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: twt
Time: Wed Aug 19 16:40:37 2020
Somehow the .cshrc file wasn't attached. I've renamed it cshrc.twt
and
resent.
Tom
On 8/19/20 4:32 PM, twt wrote:
> Hi Julie:
>
> I've attached the config.log and configure.log files for your
review.
> Also attached is my .cshrc file if this would be of any help.
>
> I appreciate your looking into this issue with me.
>
> Tom
>
> On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
>> Hi.
>>
>> I see that you are having trouble compiling MET-9.1 due to an issue
with
>> g2clib. Thank you for sending along your install.log file! I would
also
>> like to take a look at your config.log file. Could you please
reply
>> with
>> that file attached.
>>
>> I typically compile using the Intel or GNU family of compilers. If
>> your config.log file doesn't shed any light on the situation, I
will
>> try to
>> reproduce the problem that you are experiencing and will follow up
>> once I
>> know more.
>>
>> Julie
>>
>>
>> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
wrote:
>>
>>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>>> Transaction: Ticket created by twt at iac.net
>>> Queue: met_help
>>> Subject: Unable to compile MET-9.1 with grib2 enabled
>>> Owner: Nobody
>>> Requestors: twt at iac.net
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>
>>>
>>> Hi:
>>>
>>> I'm attempting to compile MET-9.1 on a linux machine under Fedora
31
>>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>>>
>>> My build syntax is ./configure --prefix=/work/models/MET/met
>>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
>>> --enable-grib2 generates 33 of the 36 executables)
>>>
>>> The error messages are ....
>>>
>>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>>> undefined reference to `g2_free'
>>> /bin/ld:
>>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>>>
>>>
>>> in function `MetGrib2DataFile::read_grib2_record_dat
>>>
>>> Similar undefined references in trying to compile the code
>>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info',
and
>>> 'g2_getfld'.
>>>
>>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a) is
>>> produced.
>>>
>>> Can you supply some tips on how to move foreard?
>>>
>>> Thanks,
>>>
>>> T. W. Tesche
>>>
>>>
>>>
>>>
>>>
>>>
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: twt
Time: Wed Aug 19 16:40:37 2020
#echo 'starting .cshrc'
# Plotting directories
setenv display /home/twt/diskc/display
setenv plotout /home/twt/diskc/plotout
# Working directories
setenv ada /home/twt/diskc/ada
setenv WRF /home/twt/diskc/wrf4.2/wrf #wrf.pgi/wrf
setenv pnw /home/twt/diskc/pnw
setenv hgb /home/twt/diskc/hgb
# R libraries and environmental variables
setenv R_LIBS_USER /home/twt/R/site-library # /usr/lib64/R/library
# /usr/local/R/library
setenv R_HOME_DIR /usr/lib64/R
setenv TMPDIR /home/twt/R/tmpdir
# Directories for MADIS
setenv MADIS /work/models/MADIS
setenv MADIS_BIN /work/models/MADIS/bin
setenv MADIS_DATA /work/models/MADIS/data
setenv MADIS_STATIC /work/models/MADIS/static
# Directories for MET
setenv MET /work/models/MET
setenv MET_BASE /work/models/MET/met/share/met
setenv MET_TUTORIAL_DATA /work/models/MET/met/tutorial
setenv MET_BUFRINC /work/models/MET/met/BUFRLIB
setenv MET_BUFRLIB /work/models/MET/met/BUFRLIB
setenv MET_NETCDF /work/models/NVIDIA-20.5
setenv MET_HDF4 /work/models/NVIDIA-20.5
setenv MET_HDFEOS /work/models/NVIDIA-20.5
setenv MET_HDF5 /work/models/NVIDIA-20.5
setenv MET_HDFEOS /work/local/hdfeos5-1.16
setenv MET_GSLINC /usr/local/include/gsl
setenv MET_GSLLIB /usr/local/lib
setenv MET_GRIB2CINC /usr/local/g2lib-3.1.0
setenv MET_GRIB2CLIB /usr/local/g2lib-3.1.0
setenv NCEPLIBS_DIR /work/models/MET/UPP/NCEP/NCEPLIBS_DIR
setenv JASPER_INC /work/models/NVIDIA-20.5/include
setenv PNG_INC /work/models/NVIDIA-20.5/include
#setenv MET_PYTHON_CC /usr/include/python3.8
#setenv MET_PYTHON_LD /usr/lib/python3.8/config-x86_64-linux-gnu
-lpython3.7m
# WRF environmental variables
setenv WRF_DIR /home/twt/diskc/wrf4.2/wrf
setenv NETCDF /work/models/NVIDIA-20.5
setenv HDF5 /work/models/NVIDIA-20.5
setenv MPICH /work/models/NVIDIA-20.5
setenv JASPERLIB /work/models/NVIDIA-20.5/lib
setenv JASPERINC /work/models/NVIDIA-20.5/include
setenv NCARG_ROOT /home/twt/.conda/pkgs/ncl-6.6.2-h1549c47_10/
setenv CPATH /usr/include/tirpc
setenv WRF_CHEM 0
setenv WRF_KPP 0
setenv FLEX_LIB_DIR /usr/lib64/
setenv RDAPSWD OSgXcuN1 # password for NCAR Data Achive (RDA)
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
setenv WRF_EM_CORE 1
setenv BUFR 1
setenv CRTM 1
setenv J "-j 2"
setenv YACC '/usr/bin/bison -d'
setenv HYDRA_HOST_FILE /home/twt/host
setenv PKG_CONFIG_PATH
/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib64
#==================================================
# NVIDIA 20.5 compilers
setenv nvidia
/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers
setenv FC pgf90
setenv F77 pgf77
setenv F90 pgf90
setenv CC gcc
setenv MPICC mpicc
setenv CXX g++
setenv FFLAGS -m64
setenv FCFLAGS -m64
setenv LDFLAGS -L/work/models/NVIDIA-20.5/lib
setenv CPPFLAGS -I/work/models/NVIDIA-20.5/include
setenv CFLAGS "-I/usr/local/include -I/work/models/NVIDIA-
20.5/include -I/usr/local/libtirpc-1.1.4/include/tirpc/rpc
-I/home/twt/.conda/pkgs/python-3.7.7-
hcf32534_0_cpython/include/python3.7m -I/usr/include
-I/home/twt/.conda/pkgs/ncl-6.6.2-h1549c47_10/include/ncarg
-I/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/include
-I/work/models/MADIS/include -I/usr/local/g2lib-3.1.0"
setenv LDFLAGS "-L/usr/lib64 -L/usr/local/lib -L/work/models/NVIDIA-
20.5/lib
-L/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/lib"
setenv CPPFLAGS "-I/usr/local/include -I/usr/local/libtirpc-
1.1.4/include/tirpc/rpc -I/home/twt/.conda/envs/ncl-
py/include/python3.7m -I/usr/local/libtirpc-1.1.4/include/tirpc/rpc
-I/work/models/NVIDIA-20.5/include -I/usr/local/include/freetype2
-I/usr/include/GL -I/home/twt/.conda/pkgs/ncl-6.6.2-
h1549c47_10/include/ncarg
-I/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/include
-I/work/models/MADIS/include -I/usr/local/g2lib-3.1.0"
setenv LD_LIBRARY_PATH
/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/lib:/home/twt/.conda/pkgs/python-
3.7.7-
hcf32534_0_cpython/lib/libpython3.7m.so.1.0:/usr/local/lib:/usr/lib64:/usr/lib:/lib64:/work/models/NVIDIA-
20.5/lib:/home/twt/.conda/pkgs/ncl-6.6.2-
h1549c47_10/include/ncarg/lib:/work/models/MADIS/lib:/usr/local/g2lib-
3.1.0
set path =
(/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/bin:/work/models/NVIDIA-
20.5/bin:/work/models/NVIDIA-
20.5/include:/usr/lib64:/usr/lib64/pkgconfig:/usr/local/bin:/usr/local/include:/bin:/usr/bin:/usr/sbin:/usr/local/include/GL:/usr/include:/usr/include/X11:/usr/include/tirpc:/home/twt/.conda/pkgs/ncl-
6.6.2-
h1549c47_10/include/ncarg/bin:/work/models/MET/met/bin:/work/models/MADIS/bin
$path)
setenv MANPATH '$MANPATH':/usr/share/man:/home/twt/.conda/pkgs/ncl-
6.6.2-
h1549c47_10/include/ncarg/man:/work/compilers/nvidia/hpc_sdk/Linux_x86_64/20.5/compilers/man
#=================================================
setenv OMP_STACKSIZE 50000000 #was 500000000 but caused "libgomp:
Thread creation failed: Resource temporarily unavailable"
setenv OMP_NUM_THREADS 12
setenv MAGICK_HOME /usr/lib64/ImageMagick-6.9.10
setenv CONVERT /usr/bin
setenv GRAPHCAP X11
setenv DISPLAY :0.0
setenv AUTO_DELETE N
setenv OMP_NUM_THREADS 12
# Finish up....
umask 002
set number
set history=256
alias ls ls -F --color=auto
alias h history
alias df df -h
alias ll ls -lag
alias idlde idlde -outofprocess
alias rm rm -f
# End
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: Julie Prestopnik
Time: Wed Aug 19 17:00:38 2020
Hi Tom. Thanks so much for sending those files. They are really
helpful.
I could tell the following from your config.log file, but seeing your
cshrc
file really helped as well.
In your cshrc file I see the following:
setenv FC pgf90
>
> setenv F77 pgf77
>
> setenv F90 pgf90
>
> setenv CC gcc
>
> setenv CXX g++
>
You are using the GNU family of compilers for CC and CXX, but the PGI
family of compilers for FC, F77, and F90. Mixing compiler families
can
cause problems. That could be the cause of your problem.
You should either switch to using the GNU family for all like this
(recommended):
setenv FC gfortran
>
> setenv F77 gfortran
>
> setenv F90 gfortran
>
> setenv CC gcc
>
> setenv CXX g++
>
Or you should switch to using to using the PGI family for all like
this:
setenv FC pgf90
>
> setenv F77 pgf77
>
> setenv F90 pgf90
>
> setenv CC pgcc
>
> setenv CXX pgc++
>
You'll need to compile all of the supporting libraries as well using
the
same family of compilers. I see that you are using some libraries in
the
/usr/local/ area (for example /usr/local/g2lib-3.1.0 and
/usr/local/include/gsl), so if you would like to use those, please
make
sure you are using the same family of compilers that they were
compiled
with and make sure that they (for example, g2lib and gsl) were
compiled
with the same family of compilers.
Please let us know how it goes and whether or not you're able to get a
successful build after ensuring the use of the same family of
compilers.
Thanks!
Julie
On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>
> Somehow the .cshrc file wasn't attached. I've renamed it cshrc.twt
and
> resent.
>
> Tom
>
> On 8/19/20 4:32 PM, twt wrote:
> > Hi Julie:
> >
> > I've attached the config.log and configure.log files for your
review.
> > Also attached is my .cshrc file if this would be of any help.
> >
> > I appreciate your looking into this issue with me.
> >
> > Tom
> >
> > On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
> >> Hi.
> >>
> >> I see that you are having trouble compiling MET-9.1 due to an
issue with
> >> g2clib. Thank you for sending along your install.log file! I
would also
> >> like to take a look at your config.log file. Could you please
reply
> >> with
> >> that file attached.
> >>
> >> I typically compile using the Intel or GNU family of compilers.
If
> >> your config.log file doesn't shed any light on the situation, I
will
> >> try to
> >> reproduce the problem that you are experiencing and will follow
up
> >> once I
> >> know more.
> >>
> >> Julie
> >>
> >>
> >> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
wrote:
> >>
> >>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
> >>> Transaction: Ticket created by twt at iac.net
> >>> Queue: met_help
> >>> Subject: Unable to compile MET-9.1 with grib2 enabled
> >>> Owner: Nobody
> >>> Requestors: twt at iac.net
> >>> Status: new
> >>> Ticket <URL:
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
> >>>
> >>>
> >>> Hi:
> >>>
> >>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora 31
> >>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
> >>>
> >>> My build syntax is ./configure --prefix=/work/models/MET/met
> >>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
> >>> --enable-grib2 generates 33 of the 36 executables)
> >>>
> >>> The error messages are ....
> >>>
> >>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
> >>> undefined reference to `g2_free'
> >>> /bin/ld:
> >>>
>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>
> >>>
> >>>
> >>> in function `MetGrib2DataFile::read_grib2_record_dat
> >>>
> >>> Similar undefined references in trying to compile the code
> >>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info',
and
> >>> 'g2_getfld'.
> >>>
> >>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a) is
> >>> produced.
> >>>
> >>> Can you supply some tips on how to move foreard?
> >>>
> >>> Thanks,
> >>>
> >>> T. W. Tesche
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: Julie Prestopnik
Time: Wed Aug 26 11:43:28 2020
Hi Tom.
I just wanted to check in and see if you have been able to get a
successful
build after ensuring the use of the same family of compilers?
Julie
On Wed, Aug 19, 2020 at 5:00 PM Julie Prestopnik <jpresto at ucar.edu>
wrote:
> Hi Tom. Thanks so much for sending those files. They are really
> helpful. I could tell the following from your config.log file, but
seeing
> your cshrc file really helped as well.
>
> In your cshrc file I see the following:
>
> setenv FC pgf90
>>
>> setenv F77 pgf77
>>
>> setenv F90 pgf90
>>
>> setenv CC gcc
>>
>> setenv CXX g++
>>
>
> You are using the GNU family of compilers for CC and CXX, but the
PGI
> family of compilers for FC, F77, and F90. Mixing compiler families
can
> cause problems. That could be the cause of your problem.
>
> You should either switch to using the GNU family for all like this
> (recommended):
>
> setenv FC gfortran
>>
>> setenv F77 gfortran
>>
>> setenv F90 gfortran
>>
>> setenv CC gcc
>>
>> setenv CXX g++
>>
>
> Or you should switch to using to using the PGI family for all like
this:
>
> setenv FC pgf90
>>
>> setenv F77 pgf77
>>
>> setenv F90 pgf90
>>
>> setenv CC pgcc
>>
>> setenv CXX pgc++
>>
>
> You'll need to compile all of the supporting libraries as well using
the
> same family of compilers. I see that you are using some libraries
in the
> /usr/local/ area (for example /usr/local/g2lib-3.1.0 and
> /usr/local/include/gsl), so if you would like to use those, please
make
> sure you are using the same family of compilers that they were
compiled
> with and make sure that they (for example, g2lib and gsl) were
compiled
> with the same family of compilers.
>
> Please let us know how it goes and whether or not you're able to get
a
> successful build after ensuring the use of the same family of
compilers.
>
> Thanks!
>
> Julie
>
>
>
>
>
>
>
> On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu>
wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>
>> Somehow the .cshrc file wasn't attached. I've renamed it cshrc.twt
and
>> resent.
>>
>> Tom
>>
>> On 8/19/20 4:32 PM, twt wrote:
>> > Hi Julie:
>> >
>> > I've attached the config.log and configure.log files for your
review.
>> > Also attached is my .cshrc file if this would be of any help.
>> >
>> > I appreciate your looking into this issue with me.
>> >
>> > Tom
>> >
>> > On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
>> >> Hi.
>> >>
>> >> I see that you are having trouble compiling MET-9.1 due to an
issue
>> with
>> >> g2clib. Thank you for sending along your install.log file! I
would
>> also
>> >> like to take a look at your config.log file. Could you please
reply
>> >> with
>> >> that file attached.
>> >>
>> >> I typically compile using the Intel or GNU family of compilers.
If
>> >> your config.log file doesn't shed any light on the situation, I
will
>> >> try to
>> >> reproduce the problem that you are experiencing and will follow
up
>> >> once I
>> >> know more.
>> >>
>> >> Julie
>> >>
>> >>
>> >> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
wrote:
>> >>
>> >>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>> >>> Transaction: Ticket created by twt at iac.net
>> >>> Queue: met_help
>> >>> Subject: Unable to compile MET-9.1 with grib2 enabled
>> >>> Owner: Nobody
>> >>> Requestors: twt at iac.net
>> >>> Status: new
>> >>> Ticket <URL:
>> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>> >>>
>> >>>
>> >>> Hi:
>> >>>
>> >>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora 31
>> >>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>> >>>
>> >>> My build syntax is ./configure --prefix=/work/models/MET/met
>> >>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
>> >>> --enable-grib2 generates 33 of the 36 executables)
>> >>>
>> >>> The error messages are ....
>> >>>
>> >>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>> >>> undefined reference to `g2_free'
>> >>> /bin/ld:
>> >>>
>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>>
>> >>>
>> >>>
>> >>> in function `MetGrib2DataFile::read_grib2_record_dat
>> >>>
>> >>> Similar undefined references in trying to compile the code
>> >>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info',
and
>> >>> 'g2_getfld'.
>> >>>
>> >>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a)
>> is
>> >>> produced.
>> >>>
>> >>> Can you supply some tips on how to move foreard?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> T. W. Tesche
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>>
>>
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #96356] Unable to compile MET-9.1 with grib2 enabled
From: twt
Time: Wed Aug 26 16:27:25 2020
Julie:
Thanks for writing back. Since we last corresponded, I crashed my
system with MET and decided to reload the OS (Fedora 32) and compilers
across the entire cluster. I'm just now getting back to where I was.
In my rebuild, I stayed with the PGI/NVIDIA fortran compilers and the
GNU c compilers. I'm ready to go deeper with MET but I have a couple
of
questions.
First, I've long heard the admonition to stay with the 'same set of
compilers'. But I've not had any problems I can recall over the past
25
years with PGI fortran/Gnu c. In fact, over the past year I've
successfully used this pairing with CAMx, CMAQ, GEOS-Chem, WRFv3 thru
v5.2.1, NCL, SMOKE, AMET and other codes. So, the notion that my issue
of getting met to compile all 36 executables is the results of
compiler
mismatch is a little puzzling. But, if my problem is indeed compiler
mismatch I can rebuild the libraries and give is a try.
For the moment, with the command "./compile
--prefix=/home/twt/work/models/MET/met" is get 33 of the 36 binary
executables in the bin directory. Both MET-9.0.3 and MET-9.1
generate
the 33.
When I try to add --with-grib2 to the compile command, I get the same
error messages as before....
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
undefined reference to `g2_free'
It seems my problem is compiling & linking grib2 library. I've tried
two versions, g2clib-1.6.0-patch and g2lib-3.1.0. Both g2lib
compilations give libgrib2c.a libraries but no include files. The
error
messages with both are..................
enc_jpeg2000.c: In function ‘enc_jpeg2000_’:
enc_jpeg2000.c:142:10: error: ‘jas_image_t’ has no member named
‘inmem_’
142 | image.inmem_=1;
| ^
make: *** [makefile:116: libgrib2c.a(enc_jpeg2000.o)] Error 1
[twt at lobo g2lib-3.1.0]$
enc_jpeg2000.c: In function ‘enc_jpeg2000’:
enc_jpeg2000.c:124:10: error: ‘jas_image_t’ has no member named
‘inmem_’
124 | image.inmem_=1;
| ^
make: *** [makefile:91: libgrib2c.a(enc_jpeg2000.o)] Error 1
[twt at lobo g2clib-1.6.0-patch]$
So, I think the root of my problem is not being able to get a workable
grib2 library.
I do have another question. My overall plan is to evaluate WRFv4.2.1
over the Pacific Northwest US for boundary layer physics. I've
downloaded MADIS data for 1-31 January 2020 and run the model for
several days. My understanding is that I need to convert the WRF
netCDF
history files to grib2 format using UPP. I've compiled UPP and
generated unipost.exe but when I try to run the first 24-hr history
file, the software only runs for the first hour! Do I need to go back
and re-run all my WRF episode days and produce individual 1-hr average
output files? Or is there a way for unipost to work with a daily
history file.
Again, thanks for reaching out; I really appreciate it. I'll keep
working to see if I can solve the grib2 library issue...
best regards,
Tom Tesche
Boise, ID
On 8/26/2020 10:43 AM, Julie Prestopnik via RT wrote:
> Hi Tom.
>
> I just wanted to check in and see if you have been able to get a
successful
> build after ensuring the use of the same family of compilers?
>
> Julie
>
> On Wed, Aug 19, 2020 at 5:00 PM Julie Prestopnik <jpresto at ucar.edu>
wrote:
>
>> Hi Tom. Thanks so much for sending those files. They are really
>> helpful. I could tell the following from your config.log file, but
seeing
>> your cshrc file really helped as well.
>>
>> In your cshrc file I see the following:
>>
>> setenv FC pgf90
>>> setenv F77 pgf77
>>>
>>> setenv F90 pgf90
>>>
>>> setenv CC gcc
>>>
>>> setenv CXX g++
>>>
>> You are using the GNU family of compilers for CC and CXX, but the
PGI
>> family of compilers for FC, F77, and F90. Mixing compiler families
can
>> cause problems. That could be the cause of your problem.
>>
>> You should either switch to using the GNU family for all like this
>> (recommended):
>>
>> setenv FC gfortran
>>> setenv F77 gfortran
>>>
>>> setenv F90 gfortran
>>>
>>> setenv CC gcc
>>>
>>> setenv CXX g++
>>>
>> Or you should switch to using to using the PGI family for all like
this:
>>
>> setenv FC pgf90
>>> setenv F77 pgf77
>>>
>>> setenv F90 pgf90
>>>
>>> setenv CC pgcc
>>>
>>> setenv CXX pgc++
>>>
>> You'll need to compile all of the supporting libraries as well
using the
>> same family of compilers. I see that you are using some libraries
in the
>> /usr/local/ area (for example /usr/local/g2lib-3.1.0 and
>> /usr/local/include/gsl), so if you would like to use those, please
make
>> sure you are using the same family of compilers that they were
compiled
>> with and make sure that they (for example, g2lib and gsl) were
compiled
>> with the same family of compilers.
>>
>> Please let us know how it goes and whether or not you're able to
get a
>> successful build after ensuring the use of the same family of
compilers.
>>
>> Thanks!
>>
>> Julie
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu>
wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>
>>> Somehow the .cshrc file wasn't attached. I've renamed it
cshrc.twt and
>>> resent.
>>>
>>> Tom
>>>
>>> On 8/19/20 4:32 PM, twt wrote:
>>>> Hi Julie:
>>>>
>>>> I've attached the config.log and configure.log files for your
review.
>>>> Also attached is my .cshrc file if this would be of any help.
>>>>
>>>> I appreciate your looking into this issue with me.
>>>>
>>>> Tom
>>>>
>>>> On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
>>>>> Hi.
>>>>>
>>>>> I see that you are having trouble compiling MET-9.1 due to an
issue
>>> with
>>>>> g2clib. Thank you for sending along your install.log file! I
would
>>> also
>>>>> like to take a look at your config.log file. Could you please
reply
>>>>> with
>>>>> that file attached.
>>>>>
>>>>> I typically compile using the Intel or GNU family of compilers.
If
>>>>> your config.log file doesn't shed any light on the situation, I
will
>>>>> try to
>>>>> reproduce the problem that you are experiencing and will follow
up
>>>>> once I
>>>>> know more.
>>>>>
>>>>> Julie
>>>>>
>>>>>
>>>>> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
wrote:
>>>>>
>>>>>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>>>>>> Transaction: Ticket created by twt at iac.net
>>>>>> Queue: met_help
>>>>>> Subject: Unable to compile MET-9.1 with grib2 enabled
>>>>>> Owner: Nobody
>>>>>> Requestors: twt at iac.net
>>>>>> Status: new
>>>>>> Ticket <URL:
>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>>>>
>>>>>>
>>>>>> Hi:
>>>>>>
>>>>>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora 31
>>>>>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>>>>>>
>>>>>> My build syntax is ./configure --prefix=/work/models/MET/met
>>>>>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
>>>>>> --enable-grib2 generates 33 of the 36 executables)
>>>>>>
>>>>>> The error messages are ....
>>>>>>
>>>>>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>>>>>> undefined reference to `g2_free'
>>>>>> /bin/ld:
>>>>>>
>>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>>>
>>>>>>
>>>>>> in function `MetGrib2DataFile::read_grib2_record_dat
>>>>>>
>>>>>> Similar undefined references in trying to compile the code
>>>>>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb', 'g2_info',
and
>>>>>> 'g2_getfld'.
>>>>>>
>>>>>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a)
>>> is
>>>>>> produced.
>>>>>>
>>>>>> Can you supply some tips on how to move foreard?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> T. W. Tesche
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>> --
>> Julie Prestopnik (she/her/hers)
>> Software Engineer
>> National Center for Atmospheric Research
>> Research Applications Laboratory
>> Phone: 303.497.8399
>> Email: jpresto at ucar.edu
>>
>> My working day may not be your working day. Please do not feel
obliged to
>> reply to this email outside of your normal working hours.
>>
>
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: Julie Prestopnik
Time: Wed Aug 26 17:10:42 2020
Hi Tom
I'm surprised to hear that you haven't experienced problems with
mixing
compiler families in the past. You're welcome to give it a shot.
Please
just keep it in mind that other folks have had problems in the past.
Regarding compiling the grib2c library, unfortunately, there are hard
coded
values in the "makefile", which need to be modified:
- If using a compiler other than "gcc" please edit the value of CC
in
"makefile".
- Because the GRIB2 C-Library requires the libraries zlib, jasper
and
png to be present on your system, please edit the value of "INC" to
be the
location of the include directory for the header files of those
libraries.
- Compiling the GRIB2C library with the -D__64BIT__ option requires
that
MET also be configured with CXXFLAGS="-D__64BIT__". Compiling MET
and the
GRIB2C library inconsistently may result in a segmentation fault
when
reading GRIB2 files. Either remove the -D__64BIT__ flag from the
g2clib
library or set the CXXFLAG. The __64BIT__ option should either be
used for
both or neither.
- Once built, MET expects the GRIB2 C-Library to be named
libgrib2c.a.
Please either edit the value of LIB in "makefile" to be libgrib2c.a
or
rename the .a file after it is created.
I'll paste in the code that we use in a script to compile the grib2c
library in hopes that it will help:
echo "Compiling G2CLIB at `date`"
>
> mkdir -p ${LIB_DIR}/g2clib
>
> cd ${LIB_DIR}/g2clib
>
> rm -rf g2clib*
>
> tar -xf ${TAR_DIR}/g2clib*.tar
>
> cd g2clib*
>
> cat makefile | \
>
> sed -r 's/INC=.*/INC=-I${LIB_DIR}\/include
> -I${LIB_DIR}\/include\/jasper/g' | \
>
> sed 's/CC=gcc/CC=${CC_COMPILER}/g' | \
>
> sed 's/-D__64BIT__//g' \
>
> > makefile_new
>
> mv makefile_new makefile
>
> export CC_COMPILER=${CC}
>
> echo "cd `pwd`"
>
> echo "make > make.log 2>&1"
>
> make > make.log 2>&1
>
> ret=$?
>
> if [ $ret != 0 ]; then
>
> echo "make returned with non-zero ($ret) status"
>
> exit 1
>
> fi
>
> cp libg2c*.a ${LIB_DIR}/lib/libgrib2c.a
>
> cp *.h ${LIB_DIR}/include/.
>
Maybe you've already considered those things above, but in case not I
wanted to be sure to tell you about those issues.
One other thing to mention - We have a compile script, which takes a
configuration file as input, to install MET and its supporting
libraries.
You're welcome to try it out if you'd like. We've used it on many
platforms. You can find it and instructions for using it on the
following
page under the "Sample Script For Compiling External Libraries And
MET"
section:
https://dtcenter.org/community-code/model-evaluation-tools-
met/download
Regarding your question "Do I need to go back and re-run all my WRF
episode
days and produce individual 1-hr average output files? Or is there a
way
for unipost to work with a daily history file.", I am seeking guidance
from
the team and will follow up once I know more.
Please let us know how the compilation goes.
Julie
On Wed, Aug 26, 2020 at 4:36 PM twt via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>
> Julie:
>
> Thanks for writing back. Since we last corresponded, I crashed my
> system with MET and decided to reload the OS (Fedora 32) and
compilers
> across the entire cluster. I'm just now getting back to where I
was.
> In my rebuild, I stayed with the PGI/NVIDIA fortran compilers and
the
> GNU c compilers. I'm ready to go deeper with MET but I have a
couple of
> questions.
>
> First, I've long heard the admonition to stay with the 'same set of
> compilers'. But I've not had any problems I can recall over the
past 25
> years with PGI fortran/Gnu c. In fact, over the past year I've
> successfully used this pairing with CAMx, CMAQ, GEOS-Chem, WRFv3
thru
> v5.2.1, NCL, SMOKE, AMET and other codes. So, the notion that my
issue
> of getting met to compile all 36 executables is the results of
compiler
> mismatch is a little puzzling. But, if my problem is indeed
compiler
> mismatch I can rebuild the libraries and give is a try.
>
> For the moment, with the command "./compile
> --prefix=/home/twt/work/models/MET/met" is get 33 of the 36 binary
> executables in the bin directory. Both MET-9.0.3 and MET-9.1
generate
> the 33.
>
> When I try to add --with-grib2 to the compile command, I get the
same
> error messages as before....
>
>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
> undefined reference to `g2_free'
>
> It seems my problem is compiling & linking grib2 library. I've
tried
> two versions, g2clib-1.6.0-patch and g2lib-3.1.0. Both g2lib
> compilations give libgrib2c.a libraries but no include files. The
error
> messages with both are..................
>
> enc_jpeg2000.c: In function ‘enc_jpeg2000_’:
> enc_jpeg2000.c:142:10: error: ‘jas_image_t’ has no member named
‘inmem_’
> 142 | image.inmem_=1;
> | ^
> make: *** [makefile:116: libgrib2c.a(enc_jpeg2000.o)] Error 1
> [twt at lobo g2lib-3.1.0]$
>
> enc_jpeg2000.c: In function ‘enc_jpeg2000’:
> enc_jpeg2000.c:124:10: error: ‘jas_image_t’ has no member named
‘inmem_’
> 124 | image.inmem_=1;
> | ^
> make: *** [makefile:91: libgrib2c.a(enc_jpeg2000.o)] Error 1
> [twt at lobo g2clib-1.6.0-patch]$
>
> So, I think the root of my problem is not being able to get a
workable
> grib2 library.
>
> I do have another question. My overall plan is to evaluate
WRFv4.2.1
> over the Pacific Northwest US for boundary layer physics. I've
> downloaded MADIS data for 1-31 January 2020 and run the model for
> several days. My understanding is that I need to convert the WRF
netCDF
> history files to grib2 format using UPP. I've compiled UPP and
> generated unipost.exe but when I try to run the first 24-hr history
> file, the software only runs for the first hour! Do I need to go
back
> and re-run all my WRF episode days and produce individual 1-hr
average
> output files? Or is there a way for unipost to work with a daily
> history file.
>
> Again, thanks for reaching out; I really appreciate it. I'll keep
> working to see if I can solve the grib2 library issue...
>
> best regards,
>
> Tom Tesche
> Boise, ID
>
>
>
>
> On 8/26/2020 10:43 AM, Julie Prestopnik via RT wrote:
> > Hi Tom.
> >
> > I just wanted to check in and see if you have been able to get a
> successful
> > build after ensuring the use of the same family of compilers?
> >
> > Julie
> >
> > On Wed, Aug 19, 2020 at 5:00 PM Julie Prestopnik
<jpresto at ucar.edu>
> wrote:
> >
> >> Hi Tom. Thanks so much for sending those files. They are really
> >> helpful. I could tell the following from your config.log file,
but
> seeing
> >> your cshrc file really helped as well.
> >>
> >> In your cshrc file I see the following:
> >>
> >> setenv FC pgf90
> >>> setenv F77 pgf77
> >>>
> >>> setenv F90 pgf90
> >>>
> >>> setenv CC gcc
> >>>
> >>> setenv CXX g++
> >>>
> >> You are using the GNU family of compilers for CC and CXX, but the
PGI
> >> family of compilers for FC, F77, and F90. Mixing compiler
families can
> >> cause problems. That could be the cause of your problem.
> >>
> >> You should either switch to using the GNU family for all like
this
> >> (recommended):
> >>
> >> setenv FC gfortran
> >>> setenv F77 gfortran
> >>>
> >>> setenv F90 gfortran
> >>>
> >>> setenv CC gcc
> >>>
> >>> setenv CXX g++
> >>>
> >> Or you should switch to using to using the PGI family for all
like this:
> >>
> >> setenv FC pgf90
> >>> setenv F77 pgf77
> >>>
> >>> setenv F90 pgf90
> >>>
> >>> setenv CC pgcc
> >>>
> >>> setenv CXX pgc++
> >>>
> >> You'll need to compile all of the supporting libraries as well
using the
> >> same family of compilers. I see that you are using some
libraries in
> the
> >> /usr/local/ area (for example /usr/local/g2lib-3.1.0 and
> >> /usr/local/include/gsl), so if you would like to use those,
please make
> >> sure you are using the same family of compilers that they were
compiled
> >> with and make sure that they (for example, g2lib and gsl) were
compiled
> >> with the same family of compilers.
> >>
> >> Please let us know how it goes and whether or not you're able to
get a
> >> successful build after ensuring the use of the same family of
compilers.
> >>
> >> Thanks!
> >>
> >> Julie
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu>
wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
> >>>
> >>> Somehow the .cshrc file wasn't attached. I've renamed it
cshrc.twt and
> >>> resent.
> >>>
> >>> Tom
> >>>
> >>> On 8/19/20 4:32 PM, twt wrote:
> >>>> Hi Julie:
> >>>>
> >>>> I've attached the config.log and configure.log files for your
review.
> >>>> Also attached is my .cshrc file if this would be of any help.
> >>>>
> >>>> I appreciate your looking into this issue with me.
> >>>>
> >>>> Tom
> >>>>
> >>>> On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
> >>>>> Hi.
> >>>>>
> >>>>> I see that you are having trouble compiling MET-9.1 due to an
issue
> >>> with
> >>>>> g2clib. Thank you for sending along your install.log file! I
would
> >>> also
> >>>>> like to take a look at your config.log file. Could you please
reply
> >>>>> with
> >>>>> that file attached.
> >>>>>
> >>>>> I typically compile using the Intel or GNU family of
compilers. If
> >>>>> your config.log file doesn't shed any light on the situation,
I will
> >>>>> try to
> >>>>> reproduce the problem that you are experiencing and will
follow up
> >>>>> once I
> >>>>> know more.
> >>>>>
> >>>>> Julie
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 19, 2020 at 2:58 PM twt via RT <met_help at ucar.edu>
> wrote:
> >>>>>
> >>>>>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
> >>>>>> Transaction: Ticket created by twt at iac.net
> >>>>>> Queue: met_help
> >>>>>> Subject: Unable to compile MET-9.1 with grib2 enabled
> >>>>>> Owner: Nobody
> >>>>>> Requestors: twt at iac.net
> >>>>>> Status: new
> >>>>>> Ticket <URL:
> >>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
> >>>>>>
> >>>>>>
> >>>>>> Hi:
> >>>>>>
> >>>>>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora 31
> >>>>>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
> >>>>>>
> >>>>>> My build syntax is ./configure --prefix=/work/models/MET/met
> >>>>>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
without
> >>>>>> --enable-grib2 generates 33 of the 36 executables)
> >>>>>>
> >>>>>> The error messages are ....
> >>>>>>
> >>>>>>
>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
> >>>>>> undefined reference to `g2_free'
> >>>>>> /bin/ld:
> >>>>>>
> >>>
>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
> >>>
> >>>>>>
> >>>>>> in function `MetGrib2DataFile::read_grib2_record_dat
> >>>>>>
> >>>>>> Similar undefined references in trying to compile the code
> >>>>>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb',
'g2_info', and
> >>>>>> 'g2_getfld'.
> >>>>>>
> >>>>>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
libgrib2c.a)
> >>> is
> >>>>>> produced.
> >>>>>>
> >>>>>> Can you supply some tips on how to move foreard?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> T. W. Tesche
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> >> --
> >> Julie Prestopnik (she/her/hers)
> >> Software Engineer
> >> National Center for Atmospheric Research
> >> Research Applications Laboratory
> >> Phone: 303.497.8399
> >> Email: jpresto at ucar.edu
> >>
> >> My working day may not be your working day. Please do not feel
obliged
> to
> >> reply to this email outside of your normal working hours.
> >>
> >
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Unable to compile MET-9.1 with grib2 enabled
From: Julie Prestopnik
Time: Thu Aug 27 15:28:02 2020
Hi Tom.
Regarding:
> I do have another question. My overall plan is to evaluate
WRFv4.2.1
> over the Pacific Northwest US for boundary layer physics. I've
> downloaded MADIS data for 1-31 January 2020 and run the model for
> several days. My understanding is that I need to convert the WRF
netCDF
> history files to grib2 format using UPP. I've compiled UPP and
> generated unipost.exe but when I try to run the first 24-hr history
> file, the software only runs for the first hour! Do I need to go
back
> and re-run all my WRF episode days and produce individual 1-hr
average
> output files? Or is there a way for unipost to work with a daily
> history file.
It sounds like you are having trouble with UPP. There is a different
user
support forum for that:
http://dtcenter.org/community-code/unified-post-processor-
upp/requesting-help
We don't believe you need to rerun WRF. I don't know the details, but
I
believe there is a run script included with UPP that includes the name
"*frames*", which is used to loop over multiple output times in a
single
wrfout file. But, please contact the support forum listed above for
further information.
Julie
On Wed, Aug 26, 2020 at 5:10 PM Julie Prestopnik <jpresto at ucar.edu>
wrote:
> Hi Tom
>
> I'm surprised to hear that you haven't experienced problems with
mixing
> compiler families in the past. You're welcome to give it a shot.
Please
> just keep it in mind that other folks have had problems in the past.
>
> Regarding compiling the grib2c library, unfortunately, there are
hard
> coded values in the "makefile", which need to be modified:
>
> - If using a compiler other than "gcc" please edit the value of
CC in
> "makefile".
> - Because the GRIB2 C-Library requires the libraries zlib, jasper
and
> png to be present on your system, please edit the value of "INC"
to be the
> location of the include directory for the header files of those
libraries.
> - Compiling the GRIB2C library with the -D__64BIT__ option
requires
> that MET also be configured with CXXFLAGS="-D__64BIT__".
Compiling MET and
> the GRIB2C library inconsistently may result in a segmentation
fault when
> reading GRIB2 files. Either remove the -D__64BIT__ flag from the
g2clib
> library or set the CXXFLAG. The __64BIT__ option should either be
used for
> both or neither.
> - Once built, MET expects the GRIB2 C-Library to be named
libgrib2c.a.
> Please either edit the value of LIB in "makefile" to be
libgrib2c.a or
> rename the .a file after it is created.
>
> I'll paste in the code that we use in a script to compile the grib2c
> library in hopes that it will help:
>
> echo "Compiling G2CLIB at `date`"
>>
>> mkdir -p ${LIB_DIR}/g2clib
>>
>> cd ${LIB_DIR}/g2clib
>>
>> rm -rf g2clib*
>>
>> tar -xf ${TAR_DIR}/g2clib*.tar
>>
>> cd g2clib*
>>
>> cat makefile | \
>>
>> sed -r 's/INC=.*/INC=-I${LIB_DIR}\/include
>> -I${LIB_DIR}\/include\/jasper/g' | \
>>
>> sed 's/CC=gcc/CC=${CC_COMPILER}/g' | \
>>
>> sed 's/-D__64BIT__//g' \
>>
>> > makefile_new
>>
>> mv makefile_new makefile
>>
>> export CC_COMPILER=${CC}
>>
>> echo "cd `pwd`"
>>
>> echo "make > make.log 2>&1"
>>
>> make > make.log 2>&1
>>
>> ret=$?
>>
>> if [ $ret != 0 ]; then
>>
>> echo "make returned with non-zero ($ret) status"
>>
>> exit 1
>>
>> fi
>>
>> cp libg2c*.a ${LIB_DIR}/lib/libgrib2c.a
>>
>> cp *.h ${LIB_DIR}/include/.
>>
>
> Maybe you've already considered those things above, but in case not
I
> wanted to be sure to tell you about those issues.
>
> One other thing to mention - We have a compile script, which takes a
> configuration file as input, to install MET and its supporting
libraries.
> You're welcome to try it out if you'd like. We've used it on many
> platforms. You can find it and instructions for using it on the
following
> page under the "Sample Script For Compiling External Libraries And
MET"
> section:
> https://dtcenter.org/community-code/model-evaluation-tools-
met/download
>
> Regarding your question "Do I need to go back and re-run all my WRF
> episode days and produce individual 1-hr average output files? Or
is there
> a way for unipost to work with a daily history file.", I am seeking
> guidance from the team and will follow up once I know more.
>
> Please let us know how the compilation goes.
>
> Julie
>
>
> On Wed, Aug 26, 2020 at 4:36 PM twt via RT <met_help at ucar.edu>
wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>
>> Julie:
>>
>> Thanks for writing back. Since we last corresponded, I crashed my
>> system with MET and decided to reload the OS (Fedora 32) and
compilers
>> across the entire cluster. I'm just now getting back to where I
was.
>> In my rebuild, I stayed with the PGI/NVIDIA fortran compilers and
the
>> GNU c compilers. I'm ready to go deeper with MET but I have a
couple of
>> questions.
>>
>> First, I've long heard the admonition to stay with the 'same set of
>> compilers'. But I've not had any problems I can recall over the
past 25
>> years with PGI fortran/Gnu c. In fact, over the past year I've
>> successfully used this pairing with CAMx, CMAQ, GEOS-Chem, WRFv3
thru
>> v5.2.1, NCL, SMOKE, AMET and other codes. So, the notion that my
issue
>> of getting met to compile all 36 executables is the results of
compiler
>> mismatch is a little puzzling. But, if my problem is indeed
compiler
>> mismatch I can rebuild the libraries and give is a try.
>>
>> For the moment, with the command "./compile
>> --prefix=/home/twt/work/models/MET/met" is get 33 of the 36 binary
>> executables in the bin directory. Both MET-9.0.3 and MET-9.1
generate
>> the 33.
>>
>> When I try to add --with-grib2 to the compile command, I get the
same
>> error messages as before....
>>
>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>> undefined reference to `g2_free'
>>
>> It seems my problem is compiling & linking grib2 library. I've
tried
>> two versions, g2clib-1.6.0-patch and g2lib-3.1.0. Both g2lib
>> compilations give libgrib2c.a libraries but no include files. The
error
>> messages with both are..................
>>
>> enc_jpeg2000.c: In function ‘enc_jpeg2000_’:
>> enc_jpeg2000.c:142:10: error: ‘jas_image_t’ has no member named
‘inmem_’
>> 142 | image.inmem_=1;
>> | ^
>> make: *** [makefile:116: libgrib2c.a(enc_jpeg2000.o)] Error 1
>> [twt at lobo g2lib-3.1.0]$
>>
>> enc_jpeg2000.c: In function ‘enc_jpeg2000’:
>> enc_jpeg2000.c:124:10: error: ‘jas_image_t’ has no member named
‘inmem_’
>> 124 | image.inmem_=1;
>> | ^
>> make: *** [makefile:91: libgrib2c.a(enc_jpeg2000.o)] Error 1
>> [twt at lobo g2clib-1.6.0-patch]$
>>
>> So, I think the root of my problem is not being able to get a
workable
>> grib2 library.
>>
>> I do have another question. My overall plan is to evaluate
WRFv4.2.1
>> over the Pacific Northwest US for boundary layer physics. I've
>> downloaded MADIS data for 1-31 January 2020 and run the model for
>> several days. My understanding is that I need to convert the WRF
netCDF
>> history files to grib2 format using UPP. I've compiled UPP and
>> generated unipost.exe but when I try to run the first 24-hr history
>> file, the software only runs for the first hour! Do I need to go
back
>> and re-run all my WRF episode days and produce individual 1-hr
average
>> output files? Or is there a way for unipost to work with a daily
>> history file.
>>
>> Again, thanks for reaching out; I really appreciate it. I'll keep
>> working to see if I can solve the grib2 library issue...
>>
>> best regards,
>>
>> Tom Tesche
>> Boise, ID
>>
>>
>>
>>
>> On 8/26/2020 10:43 AM, Julie Prestopnik via RT wrote:
>> > Hi Tom.
>> >
>> > I just wanted to check in and see if you have been able to get a
>> successful
>> > build after ensuring the use of the same family of compilers?
>> >
>> > Julie
>> >
>> > On Wed, Aug 19, 2020 at 5:00 PM Julie Prestopnik
<jpresto at ucar.edu>
>> wrote:
>> >
>> >> Hi Tom. Thanks so much for sending those files. They are
really
>> >> helpful. I could tell the following from your config.log file,
but
>> seeing
>> >> your cshrc file really helped as well.
>> >>
>> >> In your cshrc file I see the following:
>> >>
>> >> setenv FC pgf90
>> >>> setenv F77 pgf77
>> >>>
>> >>> setenv F90 pgf90
>> >>>
>> >>> setenv CC gcc
>> >>>
>> >>> setenv CXX g++
>> >>>
>> >> You are using the GNU family of compilers for CC and CXX, but
the PGI
>> >> family of compilers for FC, F77, and F90. Mixing compiler
families can
>> >> cause problems. That could be the cause of your problem.
>> >>
>> >> You should either switch to using the GNU family for all like
this
>> >> (recommended):
>> >>
>> >> setenv FC gfortran
>> >>> setenv F77 gfortran
>> >>>
>> >>> setenv F90 gfortran
>> >>>
>> >>> setenv CC gcc
>> >>>
>> >>> setenv CXX g++
>> >>>
>> >> Or you should switch to using to using the PGI family for all
like
>> this:
>> >>
>> >> setenv FC pgf90
>> >>> setenv F77 pgf77
>> >>>
>> >>> setenv F90 pgf90
>> >>>
>> >>> setenv CC pgcc
>> >>>
>> >>> setenv CXX pgc++
>> >>>
>> >> You'll need to compile all of the supporting libraries as well
using
>> the
>> >> same family of compilers. I see that you are using some
libraries in
>> the
>> >> /usr/local/ area (for example /usr/local/g2lib-3.1.0 and
>> >> /usr/local/include/gsl), so if you would like to use those,
please make
>> >> sure you are using the same family of compilers that they were
compiled
>> >> with and make sure that they (for example, g2lib and gsl) were
compiled
>> >> with the same family of compilers.
>> >>
>> >> Please let us know how it goes and whether or not you're able to
get a
>> >> successful build after ensuring the use of the same family of
>> compilers.
>> >>
>> >> Thanks!
>> >>
>> >> Julie
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu>
wrote:
>> >>
>> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>> >>>
>> >>> Somehow the .cshrc file wasn't attached. I've renamed it
cshrc.twt
>> and
>> >>> resent.
>> >>>
>> >>> Tom
>> >>>
>> >>> On 8/19/20 4:32 PM, twt wrote:
>> >>>> Hi Julie:
>> >>>>
>> >>>> I've attached the config.log and configure.log files for your
review.
>> >>>> Also attached is my .cshrc file if this would be of any help.
>> >>>>
>> >>>> I appreciate your looking into this issue with me.
>> >>>>
>> >>>> Tom
>> >>>>
>> >>>> On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
>> >>>>> Hi.
>> >>>>>
>> >>>>> I see that you are having trouble compiling MET-9.1 due to an
issue
>> >>> with
>> >>>>> g2clib. Thank you for sending along your install.log file! I
would
>> >>> also
>> >>>>> like to take a look at your config.log file. Could you
please reply
>> >>>>> with
>> >>>>> that file attached.
>> >>>>>
>> >>>>> I typically compile using the Intel or GNU family of
compilers. If
>> >>>>> your config.log file doesn't shed any light on the situation,
I will
>> >>>>> try to
>> >>>>> reproduce the problem that you are experiencing and will
follow up
>> >>>>> once I
>> >>>>> know more.
>> >>>>>
>> >>>>> Julie
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Aug 19, 2020 at 2:58 PM twt via RT
<met_help at ucar.edu>
>> wrote:
>> >>>>>
>> >>>>>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>> >>>>>> Transaction: Ticket created by twt at iac.net
>> >>>>>> Queue: met_help
>> >>>>>> Subject: Unable to compile MET-9.1 with grib2 enabled
>> >>>>>> Owner: Nobody
>> >>>>>> Requestors: twt at iac.net
>> >>>>>> Status: new
>> >>>>>> Ticket <URL:
>> >>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>> >>>>>>
>> >>>>>>
>> >>>>>> Hi:
>> >>>>>>
>> >>>>>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora
>> 31
>> >>>>>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>> >>>>>>
>> >>>>>> My build syntax is ./configure --prefix=/work/models/MET/met
>> >>>>>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
>> without
>> >>>>>> --enable-grib2 generates 33 of the 36 executables)
>> >>>>>>
>> >>>>>> The error messages are ....
>> >>>>>>
>> >>>>>>
>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>> >>>>>> undefined reference to `g2_free'
>> >>>>>> /bin/ld:
>> >>>>>>
>> >>>
>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>> >>>
>> >>>>>>
>> >>>>>> in function `MetGrib2DataFile::read_grib2_record_dat
>> >>>>>>
>> >>>>>> Similar undefined references in trying to compile the code
>> >>>>>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb',
'g2_info', and
>> >>>>>> 'g2_getfld'.
>> >>>>>>
>> >>>>>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
>> libgrib2c.a)
>> >>> is
>> >>>>>> produced.
>> >>>>>>
>> >>>>>> Can you supply some tips on how to move foreard?
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>> T. W. Tesche
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>
>> >> --
>> >> Julie Prestopnik (she/her/hers)
>> >> Software Engineer
>> >> National Center for Atmospheric Research
>> >> Research Applications Laboratory
>> >> Phone: 303.497.8399
>> >> Email: jpresto at ucar.edu
>> >>
>> >> My working day may not be your working day. Please do not feel
>> obliged to
>> >> reply to this email outside of your normal working hours.
>> >>
>> >
>>
>>
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #96356] Unable to compile MET-9.1 with grib2 enabled
From: twt
Time: Thu Aug 27 15:59:14 2020
Thanks, Julie!
I'll follow up on your suggestion.
Best regards,
Tom
On 8/27/2020 2:28 PM, Julie Prestopnik via RT wrote:
> Hi Tom.
>
> Regarding:
>
>> I do have another question. My overall plan is to evaluate
WRFv4.2.1
>> over the Pacific Northwest US for boundary layer physics. I've
>> downloaded MADIS data for 1-31 January 2020 and run the model for
>> several days. My understanding is that I need to convert the WRF
netCDF
>> history files to grib2 format using UPP. I've compiled UPP and
>> generated unipost.exe but when I try to run the first 24-hr history
>> file, the software only runs for the first hour! Do I need to go
back
>> and re-run all my WRF episode days and produce individual 1-hr
average
>> output files? Or is there a way for unipost to work with a daily
>> history file.
>
> It sounds like you are having trouble with UPP. There is a
different user
> support forum for that:
>
> http://dtcenter.org/community-code/unified-post-processor-
upp/requesting-help
>
> We don't believe you need to rerun WRF. I don't know the details,
but I
> believe there is a run script included with UPP that includes the
name
> "*frames*", which is used to loop over multiple output times in a
single
> wrfout file. But, please contact the support forum listed above for
> further information.
>
> Julie
>
>
> On Wed, Aug 26, 2020 at 5:10 PM Julie Prestopnik <jpresto at ucar.edu>
wrote:
>
>> Hi Tom
>>
>> I'm surprised to hear that you haven't experienced problems with
mixing
>> compiler families in the past. You're welcome to give it a shot.
Please
>> just keep it in mind that other folks have had problems in the
past.
>>
>> Regarding compiling the grib2c library, unfortunately, there are
hard
>> coded values in the "makefile", which need to be modified:
>>
>> - If using a compiler other than "gcc" please edit the value of
CC in
>> "makefile".
>> - Because the GRIB2 C-Library requires the libraries zlib,
jasper and
>> png to be present on your system, please edit the value of
"INC" to be the
>> location of the include directory for the header files of those
libraries.
>> - Compiling the GRIB2C library with the -D__64BIT__ option
requires
>> that MET also be configured with CXXFLAGS="-D__64BIT__".
Compiling MET and
>> the GRIB2C library inconsistently may result in a segmentation
fault when
>> reading GRIB2 files. Either remove the -D__64BIT__ flag from
the g2clib
>> library or set the CXXFLAG. The __64BIT__ option should either
be used for
>> both or neither.
>> - Once built, MET expects the GRIB2 C-Library to be named
libgrib2c.a.
>> Please either edit the value of LIB in "makefile" to be
libgrib2c.a or
>> rename the .a file after it is created.
>>
>> I'll paste in the code that we use in a script to compile the
grib2c
>> library in hopes that it will help:
>>
>> echo "Compiling G2CLIB at `date`"
>>> mkdir -p ${LIB_DIR}/g2clib
>>>
>>> cd ${LIB_DIR}/g2clib
>>>
>>> rm -rf g2clib*
>>>
>>> tar -xf ${TAR_DIR}/g2clib*.tar
>>>
>>> cd g2clib*
>>>
>>> cat makefile | \
>>>
>>> sed -r 's/INC=.*/INC=-I${LIB_DIR}\/include
>>> -I${LIB_DIR}\/include\/jasper/g' | \
>>>
>>> sed 's/CC=gcc/CC=${CC_COMPILER}/g' | \
>>>
>>> sed 's/-D__64BIT__//g' \
>>>
>>> > makefile_new
>>>
>>> mv makefile_new makefile
>>>
>>> export CC_COMPILER=${CC}
>>>
>>> echo "cd `pwd`"
>>>
>>> echo "make > make.log 2>&1"
>>>
>>> make > make.log 2>&1
>>>
>>> ret=$?
>>>
>>> if [ $ret != 0 ]; then
>>>
>>> echo "make returned with non-zero ($ret) status"
>>>
>>> exit 1
>>>
>>> fi
>>>
>>> cp libg2c*.a ${LIB_DIR}/lib/libgrib2c.a
>>>
>>> cp *.h ${LIB_DIR}/include/.
>>>
>> Maybe you've already considered those things above, but in case not
I
>> wanted to be sure to tell you about those issues.
>>
>> One other thing to mention - We have a compile script, which takes
a
>> configuration file as input, to install MET and its supporting
libraries.
>> You're welcome to try it out if you'd like. We've used it on many
>> platforms. You can find it and instructions for using it on the
following
>> page under the "Sample Script For Compiling External Libraries And
MET"
>> section:
>> https://dtcenter.org/community-code/model-evaluation-tools-
met/download
>>
>> Regarding your question "Do I need to go back and re-run all my WRF
>> episode days and produce individual 1-hr average output files? Or
is there
>> a way for unipost to work with a daily history file.", I am seeking
>> guidance from the team and will follow up once I know more.
>>
>> Please let us know how the compilation goes.
>>
>> Julie
>>
>>
>> On Wed, Aug 26, 2020 at 4:36 PM twt via RT <met_help at ucar.edu>
wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>
>>> Julie:
>>>
>>> Thanks for writing back. Since we last corresponded, I crashed my
>>> system with MET and decided to reload the OS (Fedora 32) and
compilers
>>> across the entire cluster. I'm just now getting back to where I
was.
>>> In my rebuild, I stayed with the PGI/NVIDIA fortran compilers and
the
>>> GNU c compilers. I'm ready to go deeper with MET but I have a
couple of
>>> questions.
>>>
>>> First, I've long heard the admonition to stay with the 'same set
of
>>> compilers'. But I've not had any problems I can recall over the
past 25
>>> years with PGI fortran/Gnu c. In fact, over the past year I've
>>> successfully used this pairing with CAMx, CMAQ, GEOS-Chem, WRFv3
thru
>>> v5.2.1, NCL, SMOKE, AMET and other codes. So, the notion that my
issue
>>> of getting met to compile all 36 executables is the results of
compiler
>>> mismatch is a little puzzling. But, if my problem is indeed
compiler
>>> mismatch I can rebuild the libraries and give is a try.
>>>
>>> For the moment, with the command "./compile
>>> --prefix=/home/twt/work/models/MET/met" is get 33 of the 36 binary
>>> executables in the bin directory. Both MET-9.0.3 and MET-9.1
generate
>>> the 33.
>>>
>>> When I try to add --with-grib2 to the compile command, I get the
same
>>> error messages as before....
>>>
>>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>>> undefined reference to `g2_free'
>>>
>>> It seems my problem is compiling & linking grib2 library. I've
tried
>>> two versions, g2clib-1.6.0-patch and g2lib-3.1.0. Both g2lib
>>> compilations give libgrib2c.a libraries but no include files. The
error
>>> messages with both are..................
>>>
>>> enc_jpeg2000.c: In function ‘enc_jpeg2000_’:
>>> enc_jpeg2000.c:142:10: error: ‘jas_image_t’ has no member named
‘inmem_’
>>> 142 | image.inmem_=1;
>>> | ^
>>> make: *** [makefile:116: libgrib2c.a(enc_jpeg2000.o)] Error 1
>>> [twt at lobo g2lib-3.1.0]$
>>>
>>> enc_jpeg2000.c: In function ‘enc_jpeg2000’:
>>> enc_jpeg2000.c:124:10: error: ‘jas_image_t’ has no member named
‘inmem_’
>>> 124 | image.inmem_=1;
>>> | ^
>>> make: *** [makefile:91: libgrib2c.a(enc_jpeg2000.o)] Error 1
>>> [twt at lobo g2clib-1.6.0-patch]$
>>>
>>> So, I think the root of my problem is not being able to get a
workable
>>> grib2 library.
>>>
>>> I do have another question. My overall plan is to evaluate
WRFv4.2.1
>>> over the Pacific Northwest US for boundary layer physics. I've
>>> downloaded MADIS data for 1-31 January 2020 and run the model for
>>> several days. My understanding is that I need to convert the WRF
netCDF
>>> history files to grib2 format using UPP. I've compiled UPP and
>>> generated unipost.exe but when I try to run the first 24-hr
history
>>> file, the software only runs for the first hour! Do I need to go
back
>>> and re-run all my WRF episode days and produce individual 1-hr
average
>>> output files? Or is there a way for unipost to work with a daily
>>> history file.
>>>
>>> Again, thanks for reaching out; I really appreciate it. I'll keep
>>> working to see if I can solve the grib2 library issue...
>>>
>>> best regards,
>>>
>>> Tom Tesche
>>> Boise, ID
>>>
>>>
>>>
>>>
>>> On 8/26/2020 10:43 AM, Julie Prestopnik via RT wrote:
>>>> Hi Tom.
>>>>
>>>> I just wanted to check in and see if you have been able to get a
>>> successful
>>>> build after ensuring the use of the same family of compilers?
>>>>
>>>> Julie
>>>>
>>>> On Wed, Aug 19, 2020 at 5:00 PM Julie Prestopnik
<jpresto at ucar.edu>
>>> wrote:
>>>>> Hi Tom. Thanks so much for sending those files. They are
really
>>>>> helpful. I could tell the following from your config.log file,
but
>>> seeing
>>>>> your cshrc file really helped as well.
>>>>>
>>>>> In your cshrc file I see the following:
>>>>>
>>>>> setenv FC pgf90
>>>>>> setenv F77 pgf77
>>>>>>
>>>>>> setenv F90 pgf90
>>>>>>
>>>>>> setenv CC gcc
>>>>>>
>>>>>> setenv CXX g++
>>>>>>
>>>>> You are using the GNU family of compilers for CC and CXX, but
the PGI
>>>>> family of compilers for FC, F77, and F90. Mixing compiler
families can
>>>>> cause problems. That could be the cause of your problem.
>>>>>
>>>>> You should either switch to using the GNU family for all like
this
>>>>> (recommended):
>>>>>
>>>>> setenv FC gfortran
>>>>>> setenv F77 gfortran
>>>>>>
>>>>>> setenv F90 gfortran
>>>>>>
>>>>>> setenv CC gcc
>>>>>>
>>>>>> setenv CXX g++
>>>>>>
>>>>> Or you should switch to using to using the PGI family for all
like
>>> this:
>>>>> setenv FC pgf90
>>>>>> setenv F77 pgf77
>>>>>>
>>>>>> setenv F90 pgf90
>>>>>>
>>>>>> setenv CC pgcc
>>>>>>
>>>>>> setenv CXX pgc++
>>>>>>
>>>>> You'll need to compile all of the supporting libraries as well
using
>>> the
>>>>> same family of compilers. I see that you are using some
libraries in
>>> the
>>>>> /usr/local/ area (for example /usr/local/g2lib-3.1.0 and
>>>>> /usr/local/include/gsl), so if you would like to use those,
please make
>>>>> sure you are using the same family of compilers that they were
compiled
>>>>> with and make sure that they (for example, g2lib and gsl) were
compiled
>>>>> with the same family of compilers.
>>>>>
>>>>> Please let us know how it goes and whether or not you're able to
get a
>>>>> successful build after ensuring the use of the same family of
>>> compilers.
>>>>> Thanks!
>>>>>
>>>>> Julie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 19, 2020 at 4:40 PM twt via RT <met_help at ucar.edu>
wrote:
>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>>>>
>>>>>> Somehow the .cshrc file wasn't attached. I've renamed it
cshrc.twt
>>> and
>>>>>> resent.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> On 8/19/20 4:32 PM, twt wrote:
>>>>>>> Hi Julie:
>>>>>>>
>>>>>>> I've attached the config.log and configure.log files for your
review.
>>>>>>> Also attached is my .cshrc file if this would be of any help.
>>>>>>>
>>>>>>> I appreciate your looking into this issue with me.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> On 8/19/20 3:53 PM, Julie Prestopnik via RT wrote:
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> I see that you are having trouble compiling MET-9.1 due to an
issue
>>>>>> with
>>>>>>>> g2clib. Thank you for sending along your install.log file! I
would
>>>>>> also
>>>>>>>> like to take a look at your config.log file. Could you
please reply
>>>>>>>> with
>>>>>>>> that file attached.
>>>>>>>>
>>>>>>>> I typically compile using the Intel or GNU family of
compilers. If
>>>>>>>> your config.log file doesn't shed any light on the situation,
I will
>>>>>>>> try to
>>>>>>>> reproduce the problem that you are experiencing and will
follow up
>>>>>>>> once I
>>>>>>>> know more.
>>>>>>>>
>>>>>>>> Julie
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Aug 19, 2020 at 2:58 PM twt via RT
<met_help at ucar.edu>
>>> wrote:
>>>>>>>>> Wed Aug 19 14:58:14 2020: Request 96356 was acted upon.
>>>>>>>>> Transaction: Ticket created by twt at iac.net
>>>>>>>>> Queue: met_help
>>>>>>>>> Subject: Unable to compile MET-9.1 with grib2
enabled
>>>>>>>>> Owner: Nobody
>>>>>>>>> Requestors: twt at iac.net
>>>>>>>>> Status: new
>>>>>>>>> Ticket <URL:
>>>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96356 >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi:
>>>>>>>>>
>>>>>>>>> I'm attempting to compile MET-9.1 on a linux machine under
Fedora
>>> 31
>>>>>>>>> with the PGI/NVIDIA-20.5 compilers. I'm using g2lib-3.1.0.
>>>>>>>>>
>>>>>>>>> My build syntax is ./configure --prefix=/work/models/MET/met
>>>>>>>>> --enable-grib2 |& tee configure.log. (MET-9.0.3 and MET-1.3
>>> without
>>>>>>>>> --enable-grib2 generates 33 of the 36 executables)
>>>>>>>>>
>>>>>>>>> The error messages are ....
>>>>>>>>>
>>>>>>>>>
>>>
/work/models/MET/met/src/libcode/vx_data2d_grib2/data2d_grib2.cc:920:
>>>>>>>>> undefined reference to `g2_free'
>>>>>>>>> /bin/ld:
>>>>>>>>>
>>>
../../../../src/libcode/vx_data2d_grib2/libvx_data2d_grib2.a(libvx_data2d_grib2_a-
data2d_grib2.o):
>>>>>>>>> in function `MetGrib2DataFile::read_grib2_record_dat
>>>>>>>>>
>>>>>>>>> Similar undefined references in trying to compile the code
>>>>>>>>> "data2d_grib2.cc" are given for 'g2_miss', 'seekgb',
'g2_info', and
>>>>>>>>> 'g2_getfld'.
>>>>>>>>>
>>>>>>>>> I've confirmed that libgrib2c.a (683774 Aug 19 13:10
>>> libgrib2c.a)
>>>>>> is
>>>>>>>>> produced.
>>>>>>>>>
>>>>>>>>> Can you supply some tips on how to move foreard?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> T. W. Tesche
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> --
>>>>> Julie Prestopnik (she/her/hers)
>>>>> Software Engineer
>>>>> National Center for Atmospheric Research
>>>>> Research Applications Laboratory
>>>>> Phone: 303.497.8399
>>>>> Email: jpresto at ucar.edu
>>>>>
>>>>> My working day may not be your working day. Please do not feel
>>> obliged to
>>>>> reply to this email outside of your normal working hours.
>>>>>
>>>
>> --
>> Julie Prestopnik (she/her/hers)
>> Software Engineer
>> National Center for Atmospheric Research
>> Research Applications Laboratory
>> Phone: 303.497.8399
>> Email: jpresto at ucar.edu
>>
>> My working day may not be your working day. Please do not feel
obliged to
>> reply to this email outside of your normal working hours.
>>
>
------------------------------------------------
More information about the Met_help
mailing list