You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the model doesn't compile when using Intel compilers, as shown by the log files attached to #183 (comment)
Attempting to compile results in a number of errors like
src/adams_bashforth.f90(19): error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name. [AB_ORDER]
integer, intent(in) :: nx, ny, layers, AB_order
and then stops without trying to compile any source files after adams_bashforth.f90.
This appears to be due to ifort being picky about the size variables being declared before they are used, see here for a discussion. Changing the order of the declarations allows the code to compile. Doing this without also changing the order of arguments in the subroutine call breaks our coding style that requires all subroutine arguments be be declared in the order they appear in the subroutine call. Not a big deal, but is kind of fiddly to fix since every subroutine call will need to be changed.
I've pushed a branch, ifort_compatability, that contains a quick and dirty fix for this, but it is far from ready to merge.
Given that the Intel compilers generally produce faster binaries, it would be nice to be able to use them when they are available.
Other issues I identified while playing with this:
the two relative wind tests fail with segfaults.
the current method for defining output 17 for std_err is gfortran specific.
ifort has an intrinsic procedure to do an equivalent thing, but I haven't yet found a compiler agnostic way to do this. As the Travis test of this branch shows, gfortran complains about the ifort method.
ifort and gfortran have different compiler options, which leads to lots of noise in std_out when compiling, especially for the test binaries, e.g. on our local cluster I get these:
[ewd@c084 aronnax]$ make aronnax_test
...
mpif90 src/declarations_TEST.o src/advection_schemes_TEST.o src/adams_bashforth_TEST.o src/end_run_TEST.o src/enforce_thickness_TEST.o src/boundaries_TEST.o src/vorticity_TEST.o src/momentum_TEST.o src/io_TEST.o src/thickness_TEST.o src/bernoulli_TEST.o src/state_deriv_TEST.o src/time_stepping_TEST.o src/barotropic_mode_TEST.o src/model_main_TEST.o src/aronnax_TEST.o -g -fprofile-arcs -ftest-coverage -O1 -fcheck=all -ffpe-trap=invalid,zero,overflow,underflow -Wuninitialized -Werror -o aronnax_test -cpp
ifort: command line warning #10006: ignoring unknown option '-fprofile-arcs'
ifort: command line warning #10006: ignoring unknown option '-ftest-coverage'
ifort: command line warning #10006: ignoring unknown option '-fcheck=all'
ifort: command line warning #10006: ignoring unknown option '-ffpe-trap=invalid,zero,overflow,underflow'
ifort: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifort: command line remark #10148: option '-Werror' not supported
Currently the model doesn't compile when using Intel compilers, as shown by the log files attached to #183 (comment)
Attempting to compile results in a number of errors like
and then stops without trying to compile any source files after
adams_bashforth.f90
.This appears to be due to
ifort
being picky about the size variables being declared before they are used, see here for a discussion. Changing the order of the declarations allows the code to compile. Doing this without also changing the order of arguments in the subroutine call breaks our coding style that requires all subroutine arguments be be declared in the order they appear in the subroutine call. Not a big deal, but is kind of fiddly to fix since every subroutine call will need to be changed.I've pushed a branch,
ifort_compatability
, that contains a quick and dirty fix for this, but it is far from ready to merge.Given that the Intel compilers generally produce faster binaries, it would be nice to be able to use them when they are available.
Other issues I identified while playing with this:
std_err
isgfortran
specific.aronnax/aronnax/aronnax
Line 25 in 87c7232
gfortran specific
.aronnax/src/model_main.f90
Line 140 in b7471e9
ifort
has an intrinsic procedure to do an equivalent thing, but I haven't yet found a compiler agnostic way to do this. As the Travis test of this branch shows,gfortran
complains about theifort
method.ifort
andgfortran
have different compiler options, which leads to lots of noise instd_out
when compiling, especially for the test binaries, e.g. on our local cluster I get these:The text was updated successfully, but these errors were encountered: