a problem in compiling ROMS

[isopycnal]

hello ,every one,
I am trying to compile ROMS in my linux FC6 platform, with g95 and Intel C++ compilers, and a problem appears such as that,
"make: *** No rule to make target `netcdf.inc', needed by `mod_netcdf.f90'. Stop.
rm mod_kinds.f90"
I have installed the Netcdf library. I don't know how to solve this problem. I wonder if somebody can please help me in this matter.Thank you very much

[jcwarner]

the system is having difficulty finding the include file called 'netcdf.inc'. Either your environment needs to be set to include the path to this file or you need to explicitly add the path during the build. If you copy and paste the actual lines of error that are listed during the build, that helps the rest of us to see what all is going on. Show the last 20 - 30 lines of the buyild process so we can see the actual problem.

[isopycnal]

thank you very much.
i have set the the path including the file "netcdf.inc" in my environment settings, but it doesn't work. the complete error lines are as below
"/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/analytical.F > analytical.f90
Bin/cpp_clean analytical.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/exchange_2d.F > exchange_2d.f90
Bin/cpp_clean exchange_2d.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_param.F > mod_param.f90
Bin/cpp_clean mod_param.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_kinds.F > mod_kinds.f90
Bin/cpp_clean mod_kinds.f90
g95 -c -O3 -ffast-math mod_kinds.f90
g95 -c -O3 -ffast-math mod_param.f90
g95 -c -O3 -ffast-math exchange_2d.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/exchange_3d.F > exchange_3d.f90
Bin/cpp_clean exchange_3d.f90
g95 -c -O3 -ffast-math exchange_3d.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_biology.F > mod_biology.f90
Bin/cpp_clean mod_biology.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_eclight.F > mod_eclight.f90
Bin/cpp_clean mod_eclight.f90
g95 -c -O3 -ffast-math mod_eclight.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_scalars.F > mod_scalars.f90
Bin/cpp_clean mod_scalars.f90
g95 -c -O3 -ffast-math mod_scalars.f90
g95 -c -O3 -ffast-math mod_biology.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_boundary.F > mod_boundary.f90
Bin/cpp_clean mod_boundary.f90
g95 -c -O3 -ffast-math mod_boundary.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_clima.F > mod_clima.f90
Bin/cpp_clean mod_clima.f90
g95 -c -O3 -ffast-math mod_clima.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_forces.F > mod_forces.f90
Bin/cpp_clean mod_forces.f90
g95 -c -O3 -ffast-math mod_forces.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_grid.F > mod_grid.f90
Bin/cpp_clean mod_grid.f90
g95 -c -O3 -ffast-math mod_grid.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_iounits.F > mod_iounits.f90
Bin/cpp_clean mod_iounits.f90
g95 -c -O3 -ffast-math mod_iounits.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_mixing.F > mod_mixing.f90
Bin/cpp_clean mod_mixing.f90
g95 -c -O3 -ffast-math mod_mixing.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_ocean.F > mod_ocean.f90
Bin/cpp_clean mod_ocean.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_sediment.F > mod_sediment.f90
Bin/cpp_clean mod_sediment.f90
g95 -c -O3 -ffast-math mod_sediment.f90
g95 -c -O3 -ffast-math mod_ocean.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_parallel.F > mod_parallel.f90
Bin/cpp_clean mod_parallel.f90
g95 -c -O3 -ffast-math mod_parallel.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_sources.F > mod_sources.f90
Bin/cpp_clean mod_sources.f90
g95 -c -O3 -ffast-math mod_sources.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_stepping.F > mod_stepping.f90
Bin/cpp_clean mod_stepping.f90
g95 -c -O3 -ffast-math mod_stepping.f90
g95 -c -O3 -ffast-math analytical.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/atm_coupler.F > atm_coupler.f90
Bin/cpp_clean atm_coupler.f90
g95 -c -O3 -ffast-math atm_coupler.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/bbl.F > bbl.f90
Bin/cpp_clean bbl.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/bc_2d.F > bc_2d.f90
Bin/cpp_clean bc_2d.f90
g95 -c -O3 -ffast-math bc_2d.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_bbl.F > mod_bbl.f90
Bin/cpp_clean mod_bbl.f90
g95 -c -O3 -ffast-math mod_bbl.f90
g95 -c -O3 -ffast-math bbl.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/bc_3d.F > bc_3d.f90
Bin/cpp_clean bc_3d.f90
g95 -c -O3 -ffast-math bc_3d.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/biology.F > biology.f90
Bin/cpp_clean biology.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_diags.F > mod_diags.f90
Bin/cpp_clean mod_diags.f90
g95 -c -O3 -ffast-math mod_diags.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_ncparam.F > mod_ncparam.f90
Bin/cpp_clean mod_ncparam.f90
g95 -c -O3 -ffast-math mod_ncparam.f90
g95 -c -O3 -ffast-math biology.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/bulk_flux.F > bulk_flux.f90
Bin/cpp_clean bulk_flux.f90
g95 -c -O3 -ffast-math bulk_flux.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/bvf_mix.F > bvf_mix.f90
Bin/cpp_clean bvf_mix.f90
g95 -c -O3 -ffast-math bvf_mix.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/diag.F > diag.f90
Bin/cpp_clean diag.f90
g95 -c -O3 -ffast-math diag.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/get_data.F > get_data.f90
Bin/cpp_clean get_data.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_obs.F > mod_obs.f90
Bin/cpp_clean mod_obs.f90
g95 -c -O3 -ffast-math mod_obs.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_tides.F > mod_tides.f90
Bin/cpp_clean mod_tides.f90
g95 -c -O3 -ffast-math mod_tides.f90
g95 -c -O3 -ffast-math get_data.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/gls_corstep.F > gls_corstep.f90
Bin/cpp_clean gls_corstep.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/tkebc_im.F > tkebc_im.f90
Bin/cpp_clean tkebc_im.f90
g95 -c -O3 -ffast-math tkebc_im.f90
g95 -c -O3 -ffast-math gls_corstep.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/gls_prestep.F > gls_prestep.f90
Bin/cpp_clean gls_prestep.f90
g95 -c -O3 -ffast-math gls_prestep.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Nonlinear/initial.F > initial.f90
Bin/cpp_clean initial.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Utility/horz_mix.F > horz_mix.f90
Bin/cpp_clean horz_mix.f90
g95 -c -O3 -ffast-math horz_mix.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Utility/ini_adjust.F > ini_adjust.f90
Bin/cpp_clean ini_adjust.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_coupling.F > mod_coupling.f90
Bin/cpp_clean mod_coupling.f90
g95 -c -O3 -ffast-math mod_coupling.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_fourdvar.F > mod_fourdvar.f90
Bin/cpp_clean mod_fourdvar.f90
make: *** No rule to make target `netcdf.inc', needed by `mod_netcdf.f90'. Stop.
rm mod_kinds.f90
""
thanks again!

[isopycnal]

jcwarner, thanks for your reply.
I modified the path of netcdf.inc in the file 'mod_netcdf.F' under the directory 'Modules', and it works. a new problem appears such as belows,
"....
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Utility/wrt_station.F > wrt_station.f90
Bin/cpp_clean wrt_station.f90
g95 -c -O3 -ffast-math wrt_station.f90
ar -r libUTIL.a back_cost.o back_cov.o back_misfit.o bcov_2d_ex.o bcov_3d_ex.o checkdefs.o close_io.o def_avg.o def_diags.o def_floats.o def_his.o def_info.o def_ini.o def_rst.o def_station.o def_var.o descent.o distribute.o dotproduct.o extract_obs.o extract_sta.o get_2dfld.o get_2dfldr.o get_3dfld.o get_3dfldr.o get_bounds.o get_cycle.o get_date.o get_grid.o get_ngfld.o get_ngfldr.o get_state.o grid_coords.o horz_mix.o ini_adjust.o inp_par.o metrics.o mp_routines.o nf_fread.o nf_fwrite.o obs_cost.o obs_initial.o obs_norm.o obs_read.o obs_write.o oi_update.o opencdf.o packing.o set_2dfld.o set_2dfldr.o set_3dfld.o set_3dfldr.o set_diags.o set_ngfld.o set_ngfldr.o set_nudgcof.o set_scoord.o set_weights.o stiffness.o timers.o utility.o wpoints.o wrt_avg.o wrt_diags.o wrt_floats.o wrt_his.o wrt_info.o wrt_ini.o wrt_rst.o wrt_station.o
ar: creating libUTIL.a
ranlib libUTIL.a
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_arrays.F > mod_arrays.f90
Bin/cpp_clean mod_arrays.f90
g95 -c -O3 -ffast-math mod_arrays.f90
ar -r libMODS.a mod_arrays.o mod_average.o mod_bbl.o mod_biology.o mod_boundary.o mod_clima.o mod_coupling.o mod_diags.o mod_eclight.o mod_eoscoef.o mod_floats.o mod_forces.o mod_fourdvar.o mod_grid.o mod_iounits.o mod_kinds.o mod_mixing.o mod_ncparam.o mod_netcdf.o mod_obs.o mod_ocean.o mod_parallel.o mod_param.o mod_scalars.o mod_sediment.o mod_sources.o mod_stepping.o mod_storage.o mod_strings.o mod_tides.o
ar: creating libMODS.a
ranlib libMODS.a
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Drivers/master.F > master.f90
Bin/cpp_clean master.f90
/usr/bin/cpp -P -traditional -I/usr/local/include -DLINUX -DX86_64 -DG95 -IInclude -INonlinear -IDrivers -ISeaIce Drivers/ocean_control.F > ocean_control.f90
Bin/cpp_clean ocean_control.f90
g95 -c -O3 -ffast-math ocean_control.f90
g95 -c -O3 -ffast-math master.f90
g95 -O3 -ffast-math master.o ocean_control.o -o oceanS libNLM.a libUTIL.a libMODS.a -L/usr/local/lib -lnetcdf
libNLM.a(output.o):(.data+0x400): undefined reference to `nf_set_log_level__'
libUTIL.a(close_io.o):(.data+0x3c8): undefined reference to `nf_set_log_level__'
libUTIL.a(def_avg.o):(.data+0x3b8): undefined reference to `nf_set_log_level__'
libUTIL.a(def_diags.o):(.data+0x3b8): undefined reference to `nf_set_log_level__'
libUTIL.a(def_his.o):(.data+0x3b8): undefined reference to `nf_set_log_level__'
libUTIL.a(def_info.o):(.data+0x3d0): more undefined references to `nf_set_log_level__' follow
make: *** [oceanS] Error 1
rm mod_kinds.f90
"
I wonder if someone had the similar problem before. thank you very much!

[jcwarner]

You should not modify the paths in the .F files.
The next problem you are having is basically a repeat of the first problem, but looking for a different file.
All of these issues are related to settings of your PATH or INCLUDE system settings.
I do not work on that Linux system, so maybe someone else can step in here but ... you need to change your system to find these files, or change the compilers file, but do not change the .F files.

[shchepet]

Yes, it is better to fix the problem by controlling your environment rather that hardcoding parth inside FORTRAN code, so you are better off by setting

Code: Select all

          -I/directory/of/netcdf/include/lile

among you CPP flags, and

Code: Select all

          -L/directory/of/netcdf/library -lnetcdf

among your linker flags, but this time it is actually not the LD_LIBRARY_PATH problem any more, but it rather looks like either

(a) single vs. double underscore conflict, or

(b) internal netcdf problem associated with particular version of netcdf library associated with specific function "nf_set_log_level".


The first issue, (a), comes from GCC fortran undescoring rules, which are non-standard relative to all other compilers: GCC adds a single underscore to a fotran name (function, subroutine, or common block) if it does not contain underscore, other than trailing underscore; it adds TWO trailing undescores if name already has an underscore (except trailing). To make complex rules simples, here are few examples:

Code: Select all

          common /ocean3d/      ----->  ocean3d_  (single underscore added)

          ierr=nf_open     ---> nf_open__     (double underscore added)

          call step2d      ---> step2d_        (single added)

          call step2d_FB_tile    ---> step2d_FB_tile__  (two underscores added)

          flush_    --->   flush__ (one underscore added to already present one at the end)

          whatever_name_   ---->  whatever_name__

Virtually all other compilers just add a single trailing underscore to fortran names regardles of the presense of any other undescores. A notable exception is IBM XLF compiler on Mac: it adds leading underscores (this complicates the cross-compiler matching, but yes, it is possible to run this code on Mac ising IBM XLF90 compiler and C from GCC to compile netCDF) .


The above behavior of GCC is default. It can be owerwritten by compiler flag

Code: Select all

        -fno-second-underscore

To check whether there is single vs. double undescore conflict use "nm" command, for example

Code: Select all

/home/alex/MP 66> nm wrt_his.o | grep nf_
                 U nf_close_
                 U nf_fwrite_
                 U nf_put_var1_double_
                 U nf_put_vara_int_
                 U nf_strerror_
                 U nf_sync_

this means that ROMS object file wrt_his.o wants to use (hence "U" on the left) external object nf_close_ (with single trailing underscore at the end);

similarly, go to you netCDF library and use command

Code: Select all

/usr/local/lib 69> cd /opt/intel/fce91/lib
/opt/intel/fce91/lib 70> nm libnetcdf.a | grep nf_
.....
....
0000000000000000 T nf_def_var_
0000000000000178 T nf_inq_var_
00000000000006be T nf_inq_vardimid_
00000000000003b8 T nf_inq_varid_
00000000000004da T nf_inq_varname_
0000000000000710 T nf_inq_varnatts_
0000000000000698 T nf_inq_varndims_
0000000000000672 T nf_inq_vartype_
0000000000000736 T nf_rename_var_
0000000000000a0e T nf_abort_
0000000000000520 T nf_close_
0000000000000120 T nf__create_
0000000000000000 T nf_create_
000000000000062e T nf__create_mp_
....
....

to see exactly what functions are available in that library. TO LINK CORRECTLY you must see exactly the same number of underscores in both roms object file and library. If you see conflict use -fsecond-underscore or -fno-second-underscore flags when compiling your code or netcdf library (which ever is appropriate).

(Note that underscoring conflict leads to a popular belief that one must use "matching" compilers when compiling code and netCDF library. This is actually not true. For example, one can use GCC with -fno-second-underscore flags to compile netcdf fibrary and PGF or Intel compiler for rest of your model.)

The second possible issue, (b), is periodic appearance and disappearance of specific netCDF function nf_set_log_level. This function is absent in netcdf 3.6.2 (the newest), but interestingly enough, netcdf.inc from that version contains lines

Code: Select all

!      integer nf_set_log_level
!      external nf_set_log_level

which are commented out, and

Code: Select all

nm libnetcdf.a | grep nf_set_log_level

returns nothing. Earlier version, 3.6.1 does not contain any mentioning of this function at
all. So try to use another version of netCDF library to see whether the problem remains.

[m.hadfield]

The nf_set_log_level thing is a bug in the build system in one or two of the recent netCDF betas. (The function is actually part of netCDF 4 and shouldn't be in there at all.) The bug affects some compilers and not others because of differences in the way they handle undefined references. The best solution is to upgrade to netCDF 3.6.2 final.

[isopycnal]

thank you for all of your replies. I very appreciate your patience to a new ROMS player.

Now, I downloaded the Netcdf3.6.2, and Specify the Environment for Building as that
"export CC=gcc
export CPPFLAGS=""
export FC=/root/g95/g95-install/bin/x86_64-linux-gnu-g95
export FFLAGS=-O
export CXX=/opt/intel/fc/bin/icc
export CXXFLAGS=-O "
and when I compile the netCDF llibrary (typing make check), there are some erros as belows,
"
ncvalues.cpp:(.text+0x286b): undefined reference to `std::ostream::operator<<(float)'
ncvalues.cpp:(.text+0x2876): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
ncvalues.cpp:(.text+0x289f): undefined reference to `std::ostream::operator<<(float)'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o): In function `NcValues_double::print(std::ostream&) const':
ncvalues.cpp:(.text+0x2900): undefined reference to `std::ostream::operator<<(double)'
ncvalues.cpp:(.text+0x290b): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
ncvalues.cpp:(.text+0x293b): undefined reference to `std::ostream::operator<<(double)'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o): In function `__sti__$E':
ncvalues.cpp:(.text+0x295a): undefined reference to `std::ios_base::Init::Init()'
ncvalues.cpp:(.text+0x2969): undefined reference to `std::ios_base::Init::~Init()'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x14): undefined reference to `__cxa_pure_virtual'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x18): undefined reference to `__cxa_pure_virtual'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x1c): undefined reference to `__cxa_pure_virtual'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x20): undefined reference to `__cxa_pure_virtual'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x24): undefined reference to `__cxa_pure_virtual'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTV8NcValues[.gnu.linkonce.d._ZTV8NcValues]+0x28): more undefined references to `__cxa_pure_virtual' follow
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI8NcValues[.gnu.linkonce.d._ZTI8NcValues]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI15NcValues_ncbyte[.gnu.linkonce.d._ZTI15NcValues_ncbyte]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI13NcValues_char[.gnu.linkonce.d._ZTI13NcValues_char]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI14NcValues_short[.gnu.linkonce.d._ZTI14NcValues_short]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI12NcValues_int[.gnu.linkonce.d._ZTI12NcValues_int]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI15NcValues_nclong[.gnu.linkonce.d._ZTI15NcValues_nclong]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.gnu.linkonce.d._ZTI13NcValues_long[.gnu.linkonce.d._ZTI13NcValues_long]+0x0): more undefined references to `vtable for __cxxabiv1::__si_class_type_info' follow
../cxx/.libs/libnetcdf_c++.a(ncvalues.o):(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
make[2]: *** [nctst] Error 1
make[2]: Leaving directory `/root/netcdf/netcdf-3.6.2/cxx'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/root/netcdf/netcdf-3.6.2/cxx'
make: *** [check-recursive] Error 1
""
And I use the 2-core intel processors, X86-64-FC6 Linux platform. I wonder anyone can help me to deal with these? thank you very much.

[shchepet]

First, Intel Core 2 dual core processors is a good choice, by far the best computing power per unit price. However, to utilize this fully, you must use Intel IFC compiler: no substitution. You can download a free non-commercial version of it from Intel's web suite

Code: Select all

http://www.intel.com/cd/software/products/asmo-na/eng/340679.htm

then click on link "Intel Fortran Compiler for Linux" just after bold-face "Compilers" section. Then fill out the forms and do whatever is necessary. When using late Intel's processors (Pentium 4 "Prescott"; Pentium D; Core 2, etc) Intel compilers boost you performance of ROMS type code by as much as 30% relative to Gfortran, PGI, and PathScale. (To my experience, on AMD Opteron processors Intel, PGI, and PathScale end up close to even.)

Second note, latest Mandriva 2007 (and I presume, Fedora Core 6 as well) GCC compilers provide Fortran 95 compiler as part of GCC 4.1.x package:

Code: Select all

/home/alex/BRC4_test 304> rpm -qa | grep gcc
gcc-gfortran-4.1.1-3mdk
gcc-c++-4.1.1-3mdk
gcc3.3-3.3.6-3mdk
gcc3.3-g77-3.3.6-3mdk
gcc-cpp-4.1.1-3mdk
libgcc1-4.1.1-3mdk
gcc-4.1.1-3mdk
gcc3.3-cpp-3.3.6-3mdk

The name of Fortran 90 compiler command coming from this package is "f95": it is not "g95". Given that you have rather exotic path,

Code: Select all

export FC=/root/g95/g95-install/bin/x86_64-linux-gnu-g95

what exact compiler you are using?

Previously g95 compiler was available only as a 3rd-party software from GNU G95 project web site, and I remember it was discussed on ROMS Discussion Board (with, I believe, Rob Hetland starting the thread). I found that "gfortran" from GCC-4.1.1 is now much more mature, and its single-processor performance on Opteron is only slightly lags behind Intel's Ifort. However, GCC compiler is still not OpenMP capable, so if you have a dual core CPU(which you do), this is a factor of 2 penalty. (GCC plans to add OpenMP support at some time in future.)

Another aspect is that Intel adds SSE3 (latest version of "streaming instructions") support available only on late CPUs (Pentium 4 "Prescott" and later, including fancy "Core Duo" laptops), which leads to some performance gain relative to AMD Opteron processors. As far as I can tell, these can be utilized only by Intel compiler. For reference, my compiler flag settings are

Code: Select all

OMP_FLAG = -fpp2 -openmp
CFT = ifort $(OMP_FLAG) -pc80 -tpp7 -axP -xP -msse3 -align dcommon -auto -stack_temps
FFLAGS = -O3 -IPF_fma -ip

Finally, If you have more that 2 GBytes of memory on your machine (not exotic today) AND your hardware is EM64T (which you have), AND your operating system is 64-bit (which you have), THEN you can run exceed 2 GByte limit by adding large memory flag

Code: Select all

 LARGE_MEM_FLAG = -mcmodel=medium -i-dynamic

into compiler options [netCDF library must be recompiled using similar flag]. PGI and PathScale have similar functionality, but f95 from GCC does not.

To my experience, f95 from GCC has the best instrumentation for debugging, including logical analysis and identification of danger of use of uninitialized variables (I have examples when GCC identifies them, but Ifort misses them, despite activation of all warning flags).

Now back to netCDF business.

Recent Mandriva 2006, 2007, Redhat Fedora Core 4 (and I presume 5, and 6, but I do not have direct experience) come with pre-compiled netCDF libraries available as rpm packages. You (or somebody else) may have temptation to install them by simply typing

Code: Select all

rpm -ivh netcdf-X.Y.Z.rpm

DO NOT DO THAT. These are most likely to be buggy and lack support of files in excess of 2 GBytes because of obsolete version of netCDF. They also use suboptimal set of compiler flags (leaving -g among other things), and the result is a slow netcdf library.

Instead you have to go through pain and suffering of compiling netCDF library yourself. In good old days this was as simple as "configure; make; make install; make test". Not any more.

Your specific problem is that you tried to compile c++ interface, and then you got all that error messages.

Advise: DO NOT BOTHER WITH C++ INTERFACE OF NETCDF. This is just a waste of time. This was buggy several years ago, and is still buggy now, even with 3.6.2 release (actually 3.6.1-beta3 is better than 3.6.2 in this respect: in compiles and goes through self-tests without a glitch by configure ---> make ---> make test): after some trial-and-error you may succeed in compiling it, but it will fail a few built-in tests. ROMS codes and related software do not need C++ interface. Frankly, I would also get rid of FORTRAN 90 module support of netCDF. ROMS relies on old-style F77 interface using netCDF.inc file, and Hernan made a wrapper around it to make it look like F90 module, but the truth is that we do not need F90 support from netCDF.

The fundamental difference between netcdf-3.6.1 and netcdf-3.6.2 is that for the sake of user convenience 3.6.2 comes with an improved mechanism for generating Makefiles. And as the result of improvement it got screwed up as usual. All earlier versions (up to 3.6.1-beta3) had a very smart way of controlling your compiler options by keeping them in a SINGLE file called "macros.make", while the actual Makefiles use the statement

Code: Select all

include macros.make

or

Code: Select all

include ../macros.make

depending on in which directory a particular Makefile is located.
This results in two consequences.

(a) all Makefiles are actually machine independent and compiler independent, because all machine- and compiler-dependent definitions are collected in "macros.make". In its turn, "macros.make" was generated by "configure" script from "rules.make", while all Makefiles were simply kept unchanged and come with netCDF package; and

(b) user can easily "hack" into "macros.make" and manipulate compiler settings according to his needs to optimize for performance, for example.

[A side note: this mechanism was adopted in UCLA and AGRIF ROMS codes, where makefile comes in three pieces: as single, machine-independent Makefile; a collection of swappable Makedefs.XXXXX files which are tuned for particular compiler and operating system setup; and an automatically generated dependency list Make.depend.]

With the release of version 3.6.2 this possibility was taken away, and now "configure" script generates about two dozen Makefiles containing all compiler settings within. Thus, the only way to change compiler settings consistently is to rerun "configure" again and again.

At first, lets try to make it easy way: go to you netcdf source code directory and type

Code: Select all

configure --disable-cxx --disable-f90 --prefix=/home/alex/netcdf/netcdf-3.6.2

where --prefix=/home/alex/netcdf/netcdf-3.6.2 sets installation path where you want netcdf library to be installed. The default is "/usr/local" or
something like that. Change it to whatever is appropriate.

Then type "make" and "make test". See what happens. Observe compiler flags it is using. Make sure that all tests passed OK. If not, correct the problem before you proceed with ROMS: having buggy netCDF library causes more headache later than not having it at all.

These are the settings to compile 3.6.2 netcdf library using Intel compiler (I am using C-shell, so type "tcsh", if your native shell is not C, otherwise setenv command is not recognized).

To compile for normal memory size

Code: Select all

setenv CFLAGS "-tpp7 -O3 -mp -IPF_fma -ip"
setenv FCFLAGS "-pc80 -tpp7 -axW -xW -w95 -align dcommon -auto -stack_temps -O3 -IPF_fma -ip"
setenv FFLAGS "-pc80 -tpp7 -axW -xW -w95 -align dcommon -auto -stack_temps -O3 -IPF_fma -ip"

then type

Code: Select all

configure --disable-cxx --disable-f90 --prefix=/home/alex/netcdf/netcdf-3.6.2
make
make test

To compile for large memory

Code: Select all

setenv CFLAGS "-tpp7 -O3 -mp -IPF_fma -ip -mcmodel=medium -i-dynamic"
setenv FCFLAGS "-pc80 -tpp7 -axW -xW -w95 -align dcommon -auto -stack_temps -O3 -IPF_fma -ip -mcmodel=medium -i-dynamic"
setenv FFLAGS "-pc80 -tpp7 -axW -xW -w95 -align dcommon -auto -stack_temps -O3 -IPF_fma -ip -mcmodel=medium -i-dynamic"

then proceed with configure, make, make test as above.

NOTE: Observe flags "-O3 -mp" among others in C- and Fortran compilers. This is important. Flag -mp prevents certain optimizations which are not IEEE compliant. Not doing so causes netcdf to fail some of the tests. Depending on Intel compiler version, you may have to drop to "-O2 -mp", if it fails some of the tests.

[m.hadfield]

Replying to isopycnal...

ncvalues.cpp:(.text+0x286b): undefined reference to `std::ostream::operator<<(float)'
ncvalues.cpp:(.text+0x2876): undefined reference to `std::basic_ostream<char, s

These are C++ errors. You can avoid them by passing the --disable-cxx switch to configure. Sacha's post above also suggested --disable-f90. This is OK for ROMS, which doesn't use the Fortran 90 interface, but if you can build the Fortran interface I guess you might as well.

[isopycnal]

thank you very much. I'll try as your instructions.

[isopycnal]

hello everyone,
now, i downloaded and installed the Intel Fortran compiler. and with your helpful instructions (especially with the shchepet's advice), I successfully installed the NetCDF3.6.2 library (passed all the tests).
and when i compile the ROMS with IFC and Icc (both 32 bite , I can not install the 64 bit program on my linux system) , the erros are
"ar: creating libUTIL.a
ranlib libUTIL.a
/usr/bin/cpp -P -traditional -I/root/netcdf/netcdf-3.6.2/include -DLINUX -DX86_64 -DIFC -IInclude -INonlinear -IDrivers -ISeaIce Modules/mod_arrays.F > mod_arrays.f90
Bin/cpp_clean mod_arrays.f90
ifc -c -ip -O3 -xW mod_arrays.f90
ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet'
ar r libMODS.a mod_arrays.o mod_average.o mod_bbl.o mod_biology.o mod_boundary.o mod_clima.o mod_coupling.o mod_diags.o mod_eclight.o mod_eoscoef.o mod_floats.o mod_forces.o mod_fourdvar.o mod_grid.o mod_iounits.o mod_kinds.o mod_mixing.o mod_ncparam.o mod_netcdf.o mod_obs.o mod_ocean.o mod_parallel.o mod_param.o mod_scalars.o mod_sediment.o mod_sources.o mod_stepping.o mod_storage.o mod_strings.o mod_tides.o
ar: creating libMODS.a
ranlib libMODS.a
/usr/bin/cpp -P -traditional -I/root/netcdf/netcdf-3.6.2/include -DLINUX -DX86_64 -DIFC -IInclude -INonlinear -IDrivers -ISeaIce Drivers/master.F > master.f90
Bin/cpp_clean master.f90
/usr/bin/cpp -P -traditional -I/root/netcdf/netcdf-3.6.2/include -DLINUX -DX86_64 -DIFC -IInclude -INonlinear -IDrivers -ISeaIce Drivers/ocean_control.F > ocean_control.f90
Bin/cpp_clean ocean_control.f90
ifc -c -ip -O3 -xW ocean_control.f90
ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet'
ifc -c -ip -O3 -xW master.f90
ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet'
ifc -ip -O3 -xW -Vaxlib master.o ocean_control.o -o oceanS libNLM.a libUTIL.a libMODS.a -L/root/netcdf/netcdf-3.6.2/lib -lnetcdf
ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet'
ld: skipping incompatible /root/netcdf/netcdf-3.6.2/lib/libnetcdf.a when searching for -lnetcdf
ld: skipping incompatible /usr/local/lib/libnetcdf.a when searching for -lnetcdf
ld: cannot find -lnetcdf
make: *** [oceanS] Error 1
rm mod_kinds.f90
"
it seems that the Netcdf also has some problems. I don't konw how to do now.

Another question:
when I type 'make depend' in the ROMS directory, the results show that
"Can't find file: op_ocean.h
Can't find file: grad_ocean.h
Can't find file: tlcheck_ocean.h
Can't find file: pert_ocean.h
Can't find file: picard_ocean.h
Can't find file: s4dvar_ocean.h
Can't find file: is4dvar_ocean.h
'
and I can not find these files in my PC, anyone can tell me how i can find these files?
thank you very much.

[shchepet]

At first, I suggest you compile netCDF library and the code using GCC compilers, because now you have to solve double problem: you have code-specific problems and you have Intel specific problems as well (for example, you say that you are not able to install 64-bit version of Intel compiler on you machine).

It looks like you have essentially three errors:

1. a minor error, compiler complains that its name is "ifort" and not "ifc" any more. it appears that you are using obsolete Makefile settings in at least three aspects.
   1. you should use

      Code: Select all

       
        CFT = ifort .....
      

      
      in your Makefile instead of CFT = ifc ....
   2. Compiler flag -Vaxlib is obsolete and no longer needed; just delete it without replacing with anything else. (This flag was used to tell linker to link with library containing "iargc" and "getarg" functions; since the release of 8.1 compiler these are treated as intrinsic fortran functions and not library any more). Also, there is no need to declare iargc as INTEGER in fortran code.
   3. Compiler flag -xW means that you want to compile for instruction set of a early Northwood-core Pentium 4 CPU. Use -xT flag to compile for Core(TM)2 Duo processors, Core 2 Extreme processors, and the Dual-Core Xeon(R) processor 5100 series. Read "man ifort" for more details.
   All these are minor optimization problems so far.
2. You got a FATAL error,

   Code: Select all

   d: skipping incompatible /usr/local/lib/libnetcdf.a when searching for -lnetcdf
   ld: cannot find -lnetcdf 
   

   this is because most likely you got 32- and 64-bit incompatibility problem between netCDF library and roms object files / libraries. To chech whether you have this problem go to directory where you compiled ROMS and check what kind of, 32- or 64-bit .o files you are getting, for example

   Code: Select all

   /home/alex/BRC4_test 345> file zetabc.o
   zetabc.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
   

   Then go to directory where you have compiled netCDF library and you should see some of .o files left there (unless you did make clean). Check what are they. If it turns out that, say your ROMS .o's are 32-bit, whicle netCDF are 64-bits, then they cannot be linked together. SIMILARLY, if you used LARGE_MEMORY_FLAG (see my previous post) to compile netCDF, but did not use it to compile ROMS, your should get incompatibility. So you should used or not use large memory flag in both cases consistently.
   
   In addition, you should be able to figure out how to install 64-bit icc and ifort compilers. If it turns out that at some point of executing Intel installation script you got a warning message which looks like

   Code: Select all

   "Cannot figure out version of 32-bit glibc libraries. Installation can proceed, but it will be broken blah blah blah ..."
   

   this error message is bogus and you should overrule it by selecting the option "proceed any way" or something of this sort.
3. you third problem is that 'make depend' does not see some of the *.h files. It looks like these are related to data assimilation and can be skipped at this point.

[isopycnal]

thank you very much.
I checked the *.o files of the ROMS and the NetCDF and found they are both 32 bit.
"zetabc.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (GNU/Linux), not stripped'

Then, I changed the compiler flag as your advice and I reinstalled the NetCDF binary sources and reset the ENV settings.

Finally, I can compile and run the ROMS2.2 with Ifort and ICC compiler on my PC . but some remarks as "LOOP WAS VECTORIZED" are found in the compiling process.

Another prolem, in my last post, I said 'I can not install the 64 bit program on my linux system" for both Intel Fortran and CXX compiler. The fact is that, when i run the install script of the Intel Fortran (or CXX) compiler, the install program said "
install_fc.sh can't identify your machine type, glibc, or kernel. ..."
And then only the 32bit program can be installed successfully. I have no idea about this.

Anyway, with all of your helpful advice, I knew the basic things to compile and run the ROMS. thanks again!

[shchepet]

The remarks like "LOOP WAS VECTORIZED" are actually a good sign. It means that compiler
is able to optimize the code in some situation. Ideally every innermost loop should be
vectorized.

[ in Intel's terminology "vectorized" means that consecutive 8-byte real numbers are
loaded in quads, that is four 8-byte number at once. This translates into 4x8x8=256
bits, which is the cache line on dual-channel DDR memory system. Literally, each
DDR memory slots has 184 pins, 128 of which are used to transmit data, and you have
two independent pars of slots on your motherboard (usually they are color coded
differently and slightly spaced apart, so you see pair, then a bit of empty space, and
pair again). This way it is able to utilize memory bandwidth of the hardware. ]

...So you are able to compile and run it at last. But this is just a starting point. You loose
up to about 30% of performance of you machine because you are running in 32-bit mode.

Did you try Open MP? Are you getting and gain when set number of threads to 2
instead of 1?

What about g95 compiler you was using before?
When you compile a .F file with -c flag to create .o file, is is 32- or 64-bit .o file?
What "file" command says about it?

When you run "install.sh" script from intel, in the very beginning it gives you option to chose
between "full install, recommended" and "custom install, experienced users only" or something
like this. What happens if you go "custom". Basically it will offer you to select manually what
components you want to install, incl. 32-, 64-bit options fir "ifort" and "idb", and actually
force installer to do things it won't do in "recommended" option. Just keep trying until
you succeed.

When you execute the following commands on your system,

uname -r

uname -m

rpm -qa | grep glibc


what is the outcome for each of them?

[isopycnal]

hello, Shchepet, thank you for your interpretation of the remarks.

first, let's talk about the installation of the Intel compiler.

The basic information of my linux are as belows,

[root@localhost ~]# uname -r
2.6.18-1.2798.fc6
[root@localhost ~]# uname -m
x86_64
[root@localhost ~]# rpm -qa |grep glibc
glibc-headers-2.5-3
glibc-2.5-3
glibc-devel-2.5-3
glibc-2.5-3
glibc-common-2.5-3
glibc-devel-2.5-3

And, when I run the install scription (for example, to install I_fc_c-9.1.041)

the second step is (first step is to ask you to choose how will you do use the install scrition)

" Checking RPM version ...
Checking Dependencies ...
Checking Kernel and glibc dependencies ...

install_fc.sh can't identify your machine type, glibc, or kernel.

This product is supported for use with the following combinations :

Machine Type Kernel glibc

3. EM64T 2.4.21 2.3.2
EM64T 2.6.x. 2.3.x
EM64T 2.6.x. 2.4.x

x. Exit

If you would you like to perform an unsupported install of this product, enter the number corresponding to the platform most similar to yours. Otherwise, enter "x" to exit : "

then i input '3'

and the next step

"Which of the following would you like to do?
1. Typical Install (Recommended - Installs All Components).
2. Custom Install (Advanced Users Only).
x. Exit.

Please type a selection:
''

this time ,i type '2'

then
"Which of the following would you like to install?
1. Intel(R) Fortran Compiler for 32-bit applications, Version 9.1 (9.1.041)
2. Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1 (9.1.041)
3. Intel(R) Debugger for applications running on IA-32, Version 9.1 (9.1.041)
4. Intel(R) Debugger for applications running on Intel(R) 64, Version 26, Build 20061121 Package ID: l_fc_c_9.1.041 (9.1.041)
x. Exit
Please make a selection :

"
then '2'

then,

"
Where do you want to install to? Specify directory starting with '/'. [/opt/intel/fce/9.1.041] : /opt/intel/fce

What rpm install options would you like? [-U --replacefiles --force] : -U

--------------------------------------------------------------------------------
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1 (9.1.041)
Installing...
Installation failed.
--------------------------------------------------------------------------------

Testing Fortran compiler ...
./.././data/install_fc.sh: Cannot find ifort compiler in /opt/intel/fce/bin

"Installation is complete "
Thank you for using Intel(R) Software Development Products, tools for improving application performance.
===============================================================================


Press Enter key to continue... "

so, I can't install the 64-bit intel compiler. and I tried several times and tested 2 of intel fortran compiler products (noncommertial products), the results are identical. I found the 'glibc' is 2.5.x and is this the reason of the unsuccessful installation?



And, another aspect,

the g-95 Fortran compiler I used is 64bit program downloaded from http://g95.sourceforge.net/,so when typing "file zetabc.o",it says
"zetabc.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped"


The last,
"Did you try Open MP? Are you getting and gain when set number of threads to 2
instead of 1? "

So far, I really don't know how to set the threads to 2, . And I modified the "makefile" to

"
# If parallel applications, use at most one of these definitions
# (leave both definitions blank in serial applications):

MPI :=
OpenMP := on
"
Can this open MP?? And the compiling process is also successful with this.