arango wrote:Yes. It can be adjointed. But we have several modules in ROMS/Nonlinear that are used in the ROMS/Utility directory. This includes the bc2d.F, bc3d.F, exchange_2d.F, exchage_3d.F, scale_omega, and so on. I don't understand why uv_rotate.F has to be different. This cross-directory references are used extensively in 4D-Var and we never heard about dependency problems with these algorithms.
Perhaps the difference is that these other modules are referenced by code in
Nonlinear as well as by code in
Utility.
As I understand it, the way most (many?) Unix linkers work when given a list of libraries to process is to take out of each library only the symbols that are known to be needed
at the time that library is processed. So if the linker command is (in cut down form)
Code: Select all
/usr/bin/gfortran -o oceanS ocean_control.o libNLM.a libUTIL.a libMODS.a -lnetcdf
then the linker will pull out a given symbol from libNLM.a only if that is referenced by ocean_control.o or libNLM.a. If the first time it comes across a reference to that symbol is in libUTIL.a then the linker won't know to go back and look for it in libNLM.a, therefore linking fails.
Why hasn't this been a problem before? Possibly because the modules that Hernan lists are referred to by code in the Nonlinear subdirectory, as well as code in the Utility subdirectory. (In the case of scale_omega, the only place this particular subroutine is called is in Utility/wrt_his.F, but the Fortran module that contains it, namely omega_mod, is used by Nonlinear/initial.F and Nonlinear/main3d.F. The fact that the current problem is not encountered for scale_omega suggests that Fortran linkers import all the public symbols from a given Fortran module when that module is used.)
In the case of uv_rotate (or, to be more exact, module uv_rotate_mod which has public subroutines uv_rotate2d and uv_rotate3d) this is used by Nonlinear/set_avg.F as well as Utility/wrt_his.F. But the former only gets past the preprocessor when AVERAGES is defined. So I expect that the uv_rotate problem will only crop up when AVERAGES is not defined. This is consistent with my own experience, though I haven't yet checked it out systematically.
