[Wrf-users]
Re: WRFV2.0.3.1 and IFORT 8.1 on an 32-bit i686 (not xeon)
Iain Russell
irussell30 at cogeco.ca
Thu Feb 10 18:35:14 MST 2005
Hi Jonathan
I too originally had similar ifort compiler errors reported when trying to
compile the test cases in WRF v2.0.3.1
The folks at wrf-help advised me to check my ifort compiler version - they
had tested the build of the WRF on Linux PC's using ifort version 8.1.018,
and if my version of ifort was older than this, then the advise was to see
if I could upgrade the compiler.
At the time that I was having problems compiling WRF, I had ifort version
8.0, so I upgraded to 8.1.021 I believe - anyway I basically upgraded my
ifort compiler to a more recent version than the WRF folks had done their
testing on.
The end result was that I was able to compile WRF on a Linux PC running
RedHat 7.2 ; i.e. I can compile and generate ideal.exe and wrf.exe . I have
run into some runtime problems when subsequently trying to run wrf.exe , but
that's possibly a separate story....
Hope this helps at all.
Regards
Iain
----- Original Message -----
From: <wrf-users-request at ucar.edu>
To: <wrf-users at ucar.edu>
Sent: Thursday, February 10, 2005 2:02 PM
Subject: Wrf-users Digest, Vol 7, Issue 4
> Send Wrf-users mailing list submissions to
> wrf-users at ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
> or, via email, send a message with subject or body 'help' to
> wrf-users-request at ucar.edu
>
> You can reach the person managing the list at
> wrf-users-owner at ucar.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wrf-users digest..."
>
>
> Today's Topics:
>
> 1. Re: WRFV2.0.3.1 and IFORT 8.1 on an 32-bit i686 (not xeon)
> (Jonathan Vigh)
> 2. Re: WRFV2.0.3.1 and IFORT 8.1 on an 32-bit i686 (not xeon)
> (Riwal Plougonven)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 09 Feb 2005 15:30:01 -0700
> From: Jonathan Vigh <vigh at atmos.colostate.edu>
> Subject: Re: [Wrf-users] WRFV2.0.3.1 and IFORT 8.1 on an 32-bit i686
> (not xeon)
> To: toigo at astro.cornell.edu
> Cc: wrf-users at ucar.edu
> Message-ID: <1107988201.19403.28.camel at euler.atmos.colostate.edu>
> Content-Type: text/plain
>
> Hi Anthony, Mahally, and all,
>
> Like Anthony, I am not trying to compile on i686 Xeon but on an Intel
> i686 PC (Pentium 4 chipset, with Fedora Core 2, Intel Ifort 8.1
> compiler, WRFV2.0.3.1), except that I can't even compile a test case. I
> downloaded a fresh version of the zipped tarfile WRF2.0.3.1 and have
> made no special changes to the configure file. My NetCDF path is set,
> etc.
>
> When I ran the configuration script, I chose option 7 [Intel xeon i686
> ia32 Xeon Linux, ifort compiler (single-threaded, no nesting)]. I get
> the following output (see bottom), basically a bunch of severe internal
> compiler errors.
>
> As far as I can tell, the configuration script has no defaults for
> i686 non-Xeon PC's, so I'm guessing that a bunch of the flags for the
> Xeon cases are incompatible for the PC architecture.
>
> Anyone have any thoughts on this? Is WRF supported on Intel PC
> platforms, or just Xeon workstations?
>
> Jonathan Vigh
>
>
>
> [vigh at euler WRFV2]$ ./compile em_b_wave
>
> **** Compiling: WRF_EM_CORE .
>
> make -i -r MODULE_DIRS="-I../dyn_em -I../dyn_nmm -module ../main
> -I../external/io_netcdf -I../external/io_int -I../external/esmf_time_f90
> -I../external -I../frame -I../share -I../phys -I../inc" ext
> make[1]: Entering directory `/home/vigh/WRF-NCAR/WRFV2'
> --------------------------------------
> ( cd frame ; make -i -r externals )
> make[2]: Entering directory `/home/vigh/WRF-NCAR/WRFV2/frame'
> ( cd ../external/io_netcdf ; \
> make NETCDFPATH=/usr/remote/intel/ CPP="/lib/cpp -traditional"
> FC="ifort -FR -I. -w" ; \
> /bin/cp wrf_io_flags.h wrf_status_codes.h ../../inc )
> make[3]: Entering directory
> `/home/vigh/WRF-NCAR/WRFV2/external/io_netcdf'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory
> `/home/vigh/WRF-NCAR/WRFV2/external/io_netcdf'
> ( cd ../external/io_int ; \
> make CC="icc" CPP="/lib/cpp -traditional" FC="ifort -O2 -w
> -FR -cm -I. -Vaxlib -convert big_endian -mp -w" all )
> make[3]: Entering directory `/home/vigh/WRF-NCAR/WRFV2/external/io_int'
> /bin/cp ../../frame/module_internal_header_util.F .
> /lib/cpp -traditional -I.. module_internal_header_util.F >
> module_internal_header_util.f
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -w -I..
> -I../../inc -c module_internal_header_util.f
> /lib/cpp -traditional -I.. io_int.F90 | m4 -Uinclude -Uindex -Ulen - >
> io_int.fifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -w
> -I.. -I../../inc -c io_int.f
> /bin/rm module_internal_header_util.o
> /bin/rm -f libwrfio_int.a
> ar cr libwrfio_int.a io_int.o
> echo libwrfio_int.a
> libwrfio_int.a
> Diffwrf will be built later on in this compile. No need to rerun
> compile.
> Diffwrf will be built later on in this compile. No need to rerun
> compile.
> if [ -f ../../frame/pack_utils.o ] ; then \
> /lib/cpp -traditional diffwrf.F > diffwrf.f ; \
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian
> -mp -w -c diffwrf.f ; \
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian
> -mp -w -o diffwrf diffwrf.o io_int.o \
> ../../frame/pack_utils.o
> ../../frame/module_internal_header_util.o ../../frame/module_machine.o
> ../../frame/module_wrf_error.o ; fi
> make[3]: Leaving directory `/home/vigh/WRF-NCAR/WRFV2/external/io_int'
> ( cd ../external/esmf_time_f90 ; \
> make FC="ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp "
> CPP="/lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21" )
> make[3]: Entering directory
> `/home/vigh/WRF-NCAR/WRFV2/external/esmf_time_f90'
> /lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21 -C -P -I.
> -DF90_STANDALONE ESMF_Base.F90 > ESMF_Base.f
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> ESMF_Base.f
> fortcom: Severe: **Internal compiler error: segmentation violation
> signal raised** Please report this error along with the circumstances in
> which it occurred in a Software Problem Report. Note: File and line
> given may not be explicit cause of this error.
> in file (null), line 0, column 0
>
> compilation aborted for ESMF_Base.f (code 3)
> make[3]: [ESMF_Base.o] Error 3 (ignored)
> /lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21 -C -P -I.
> -DF90_STANDALONE ESMF_BaseTime.F90 > ESMF_BaseTime.f
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> ESMF_BaseTime.f/lib/cpp -traditional -I../../inc -I. -DEM_CORE=1
> -DNMM_CORE=0 -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0
> -DNONSTANDARD_SYSTEM -DF90_STANDALONE -DCONFIG_BUF_LEN=8192
> -DMAX_DOMAINS_F=21 -C -P -I. -DF90_STANDALONE ESMF_Calendar.F90 >
> ESMF_Calendar.f
> ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> ESMF_Calendar.ffortcom: Severe: **Internal compiler error: segmentation
> violation signal raised** Please report this error along with the
> circumstances in which it occurred in a Software Problem Report. Note:
> File and line given may not be explicit cause of this error.
> in file (null), line 0, column 0
>
>
>
>
>
>
> On Wed, 2005-02-09 at 01:45, Anthony Toigo wrote:
> > Hi,
> >
> > I've also been trying to compile WRFV2.0.3.1 with the ifort v8.1
compiler
> > on an i686 processor and have been running into some problems myself.
> >
> > Starting with a fresh copy of the tar file, at this point I am simply
> > trying to get one of the ideal cases to compile and run as a test. I
have
> > been working with "em_b_wave" for now.
> >
> > I have a 32-bit Pentium 3 i686 Fedora Core 3 Linux machine that I am
> > building and testing this on. I have the ifort v8.1 compilers, and
started
> > with gcc (3.4.2-6.fc3) but just today acquired the icc v8.1 compiler as
> > well. The netCDF version I am using is v3.6.0, and was built with ifort
> > and gcc. When compiling, I chose option "7. Intel xeon i686 ia32 Xeon
> > Linux, ifort compiler (single-threaded, no nesting)" with no other
> > modifications or flags (with the one exception of using gcc vs. icc, but
> > now I have used both and that makes no difference).
> >
> > The good news is that WRF compiles just fine. And ideal.exe runs fine
to
> > completion with no errors. The problem comes with running wrf.exe. The
> > code always crashes with a SEGV (segmentation violation) in solve_em.
> > The exact line (according to the debuggers) is:
> >
> > 1080 history_outname = grid%history_outname
> >
> > This same error occurs in the exact same place no matter whether I use
gcc
> > or icc, so at least I've ruled that out.
> >
> > Adding a debug print line, like
> >
> > write(0,*) 'history_outname=',history_outname
> >
> > before the Registry-generated assignment statements also causes the code
to
> > crash. I can't understand why the character*256 variable, or using it
in
> > an assignment statement, or even just printing it, would cause a
> > segmentation violation, but I would like to know.
> >
> > Has anyone else experienced this problem? If anyone has gotten WRF to
> > compile on a 32-bit i686 machine with Fedora Core 3 or so and the ifort
v8.1
> > compilers, did you run into any problems? Did you make any changes to
the
> > configure.defaults file to get it to compile and/or run, and if so, what
> > changes did you make? Any help anyone can offer would be appreciated.
> >
> > Thanks,
> >
> > Anthony Toigo
> > Cornell University
> > _______________________________________________
> > Wrf-users mailing list
> > Wrf-users at ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/wrf-users
> --
> ---------------------------------------------------------------------
> Jonathan Vigh, Ph.D. Candidate work phone: 970.491.8633
> Department of Atmospheric Science vigh at atmos.colostate.edu
> Colorado State University http://euler.atmos.colostate.edu/~vigh/
> ---------------------------------------------------------------------
> ~
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Feb 2005 08:54:45 +0000 (GMT)
> From: Riwal Plougonven <riwal at mcs.st-and.ac.uk>
> Subject: Re: [Wrf-users] WRFV2.0.3.1 and IFORT 8.1 on an 32-bit i686
> (not xeon)
> To: Jonathan Vigh <vigh at atmos.colostate.edu>
> Cc: wrf-users at ucar.edu
> Message-ID: <Pine.LNX.4.61.0502100843120.26471 at localhost.localdomain>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> Hi Jonathan and all,
>
> I do not know if this may help, but in case it does:
>
> I am running WRF2.0.3.1 on a i686 PC. When I first tried to
> compile WRFV2.0.3.1, there were errors associated with parts of the code
> involving EMSF, as in your case.
>
> One of the scientific officers suggested that it could be due to the -g
> flag in the compilation. This -g flag is not set by either the configure
> or compile scripts. It was in a standalone Makefile found under
> external/esmf_time_f90/Makefile. Changing the following line:
>
> $(FC) -c -g $*.f
>
> to read:
>
> $(FC) -c $*.f
>
> the program then compiled fine.
> For some reason, however, I can now compile the code without making this
> change.
>
> Hope this helps,
> Riwal
>
>
>
> On Wed, 9 Feb 2005, Jonathan Vigh wrote:
>
> > Hi Anthony, Mahally, and all,
> >
> > Like Anthony, I am not trying to compile on i686 Xeon but on an Intel
> > i686 PC (Pentium 4 chipset, with Fedora Core 2, Intel Ifort 8.1
> > compiler, WRFV2.0.3.1), except that I can't even compile a test case. I
> > downloaded a fresh version of the zipped tarfile WRF2.0.3.1 and have
> > made no special changes to the configure file. My NetCDF path is set,
> > etc.
> >
> > When I ran the configuration script, I chose option 7 [Intel xeon i686
> > ia32 Xeon Linux, ifort compiler (single-threaded, no nesting)]. I get
> > the following output (see bottom), basically a bunch of severe internal
> > compiler errors.
> >
> > As far as I can tell, the configuration script has no defaults for
> > i686 non-Xeon PC's, so I'm guessing that a bunch of the flags for the
> > Xeon cases are incompatible for the PC architecture.
> >
> > Anyone have any thoughts on this? Is WRF supported on Intel PC
> > platforms, or just Xeon workstations?
> >
> > Jonathan Vigh
> >
> >
> >
> > [vigh at euler WRFV2]$ ./compile em_b_wave
> >
> > **** Compiling: WRF_EM_CORE .
> >
> > make -i -r MODULE_DIRS="-I../dyn_em -I../dyn_nmm -module ../main
> > -I../external/io_netcdf -I../external/io_int -I../external/esmf_time_f90
> > -I../external -I../frame -I../share -I../phys -I../inc" ext
> > make[1]: Entering directory `/home/vigh/WRF-NCAR/WRFV2'
> > --------------------------------------
> > ( cd frame ; make -i -r externals )
> > make[2]: Entering directory `/home/vigh/WRF-NCAR/WRFV2/frame'
> > ( cd ../external/io_netcdf ; \
> > make NETCDFPATH=/usr/remote/intel/ CPP="/lib/cpp -traditional"
> > FC="ifort -FR -I. -w" ; \
> > /bin/cp wrf_io_flags.h wrf_status_codes.h ../../inc )
> > make[3]: Entering directory
> > `/home/vigh/WRF-NCAR/WRFV2/external/io_netcdf'
> > make[3]: Nothing to be done for `all'.
> > make[3]: Leaving directory
> > `/home/vigh/WRF-NCAR/WRFV2/external/io_netcdf'
> > ( cd ../external/io_int ; \
> > make CC="icc" CPP="/lib/cpp -traditional" FC="ifort -O2 -w
> > -FR -cm -I. -Vaxlib -convert big_endian -mp -w" all )
> > make[3]: Entering directory `/home/vigh/WRF-NCAR/WRFV2/external/io_int'
> > /bin/cp ../../frame/module_internal_header_util.F .
> > /lib/cpp -traditional -I.. module_internal_header_util.F >
> > module_internal_header_util.f
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -w -I..
> > -I../../inc -c module_internal_header_util.f
> > /lib/cpp -traditional -I.. io_int.F90 | m4 -Uinclude -Uindex -Ulen - >
> > io_int.fifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -w
> > -I.. -I../../inc -c io_int.f
> > /bin/rm module_internal_header_util.o
> > /bin/rm -f libwrfio_int.a
> > ar cr libwrfio_int.a io_int.o
> > echo libwrfio_int.a
> > libwrfio_int.a
> > Diffwrf will be built later on in this compile. No need to rerun
> > compile.
> > Diffwrf will be built later on in this compile. No need to rerun
> > compile.
> > if [ -f ../../frame/pack_utils.o ] ; then \
> > /lib/cpp -traditional diffwrf.F > diffwrf.f ; \
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian
> > -mp -w -c diffwrf.f ; \
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian
> > -mp -w -o diffwrf diffwrf.o io_int.o \
> > ../../frame/pack_utils.o
> > ../../frame/module_internal_header_util.o ../../frame/module_machine.o
> > ../../frame/module_wrf_error.o ; fi
> > make[3]: Leaving directory `/home/vigh/WRF-NCAR/WRFV2/external/io_int'
> > ( cd ../external/esmf_time_f90 ; \
> > make FC="ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp "
> > CPP="/lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> > -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> > -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21" )
> > make[3]: Entering directory
> > `/home/vigh/WRF-NCAR/WRFV2/external/esmf_time_f90'
> > /lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> > -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> > -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21 -C -P -I.
> > -DF90_STANDALONE ESMF_Base.F90 > ESMF_Base.f
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> > ESMF_Base.f
> > fortcom: Severe: **Internal compiler error: segmentation violation
> > signal raised** Please report this error along with the circumstances in
> > which it occurred in a Software Problem Report. Note: File and line
> > given may not be explicit cause of this error.
> > in file (null), line 0, column 0
> >
> > compilation aborted for ESMF_Base.f (code 3)
> > make[3]: [ESMF_Base.o] Error 3 (ignored)
> > /lib/cpp -traditional -I../../inc -I. -DEM_CORE=1 -DNMM_CORE=0
> > -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0 -DNONSTANDARD_SYSTEM
> > -DF90_STANDALONE -DCONFIG_BUF_LEN=8192 -DMAX_DOMAINS_F=21 -C -P -I.
> > -DF90_STANDALONE ESMF_BaseTime.F90 > ESMF_BaseTime.f
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> > ESMF_BaseTime.f/lib/cpp -traditional -I../../inc -I. -DEM_CORE=1
> > -DNMM_CORE=0 -DNMM_MAX_DIM=1250 -DCOAMPS_CORE=0 -DEXP_CORE=0
> > -DNONSTANDARD_SYSTEM -DF90_STANDALONE -DCONFIG_BUF_LEN=8192
> > -DMAX_DOMAINS_F=21 -C -P -I. -DF90_STANDALONE ESMF_Calendar.F90 >
> > ESMF_Calendar.f
> > ifort -O2 -w -FR -cm -I. -Vaxlib -convert big_endian -mp -c -g
> > ESMF_Calendar.ffortcom: Severe: **Internal compiler error: segmentation
> > violation signal raised** Please report this error along with the
> > circumstances in which it occurred in a Software Problem Report. Note:
> > File and line given may not be explicit cause of this error.
> > in file (null), line 0, column 0
> >
> >
> >
> >
> >
> >
> > On Wed, 2005-02-09 at 01:45, Anthony Toigo wrote:
> >> Hi,
> >>
> >> I've also been trying to compile WRFV2.0.3.1 with the ifort v8.1
compiler
> >> on an i686 processor and have been running into some problems myself.
> >>
> >> Starting with a fresh copy of the tar file, at this point I am simply
> >> trying to get one of the ideal cases to compile and run as a test. I
have
> >> been working with "em_b_wave" for now.
> >>
> >> I have a 32-bit Pentium 3 i686 Fedora Core 3 Linux machine that I am
> >> building and testing this on. I have the ifort v8.1 compilers, and
started
> >> with gcc (3.4.2-6.fc3) but just today acquired the icc v8.1 compiler as
> >> well. The netCDF version I am using is v3.6.0, and was built with
ifort
> >> and gcc. When compiling, I chose option "7. Intel xeon i686 ia32 Xeon
> >> Linux, ifort compiler (single-threaded, no nesting)" with no other
> >> modifications or flags (with the one exception of using gcc vs. icc,
but
> >> now I have used both and that makes no difference).
> >>
> >> The good news is that WRF compiles just fine. And ideal.exe runs fine
to
> >> completion with no errors. The problem comes with running wrf.exe.
The
> >> code always crashes with a SEGV (segmentation violation) in solve_em.
> >> The exact line (according to the debuggers) is:
> >>
> >> 1080 history_outname = grid%history_outname
> >>
> >> This same error occurs in the exact same place no matter whether I use
gcc
> >> or icc, so at least I've ruled that out.
> >>
> >> Adding a debug print line, like
> >>
> >> write(0,*) 'history_outname=',history_outname
> >>
> >> before the Registry-generated assignment statements also causes the
code to
> >> crash. I can't understand why the character*256 variable, or using it
in
> >> an assignment statement, or even just printing it, would cause a
> >> segmentation violation, but I would like to know.
> >>
> >> Has anyone else experienced this problem? If anyone has gotten WRF to
> >> compile on a 32-bit i686 machine with Fedora Core 3 or so and the ifort
v8.1
> >> compilers, did you run into any problems? Did you make any changes to
the
> >> configure.defaults file to get it to compile and/or run, and if so,
what
> >> changes did you make? Any help anyone can offer would be appreciated.
> >>
> >> Thanks,
> >>
> >> Anthony Toigo
> >> Cornell University
> >> _______________________________________________
> >> Wrf-users mailing list
> >> Wrf-users at ucar.edu
> >> http://mailman.ucar.edu/mailman/listinfo/wrf-users
> >
>
> --
> -----------------------------o-----------
> Riwal Plougonven
> School of Mathematics and Statistics
> Mathematical Institute
> University of St Andrews, North Haugh
> StAndrews, Fife, KY16 9SS, United Kingdom
> Phone : (+44) 1334 46 37 41
>
> ------------------------------
>
> _______________________________________________
> Wrf-users mailing list
> Wrf-users at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>
>
> End of Wrf-users Digest, Vol 7, Issue 4
> ***************************************
More information about the Wrf-users
mailing list