REcoM code is not updated during recompilation

[a270105]

We found something really odd (in different branches) and I also reported here:
#681 (comment)

I added a new feature in the recom code (src/int_recom/recom_sms.F90) and recompiled fesom. However, a fully identical executable file was created (the build folder was deleted before compilation). This did not happen as I changed the fesom code (or cmake options in src/CMakeLists for recom). It seems that the recom files were not updated during recompilation. Others in our recom group have the same problem with other branches like fesom-2.6-recom-tra-diags.

Can someone have a look at the compilation with REcoM?

[mueller79]

The HPC team identified that in FESOM 2.6 the library (libfbesom.so) is dynamically loaded from the lib64/ folder, hence the fesom.x file remains the same. When the code is running, always the latest created libfesom.x file in the lib64/ folder is used and therefore will produce the same output. In FESOM 2.1 the library file (libfesom.x) was statically integrated in the executable fesom.x in the compilation process, that's why the fesom.x file was differing between different compilations.
Therefore, the fesom.x and the libfesom.so files are needed to represent the current code version.

[patrickscholz]

@a270105: This should not happen to my understanding! We have in moment in src/CMakeFile.txt

if(RECOM_COUPLED)
   file(GLOB sources_recom ${src_home}/int_recom/*.F90
                           ${src_home}/int_recom/recom/*.F90)
   list(APPEND sources_Fortran ${sources_recom})
endif()

This adds all the RECOM files to the FESOM2 library target. If those files change CMake should recompile them automatically.
and rebuild the library target (libfesom) and fesom.x.
The only problem that might occur is when you add new files to the RECOM folder, this new files are not part of the library target that cmake check for, thus a recompilation will not be triggered unless you make a ./configure.sh --clean and build a completely new target

However chatgpt suggests:

💡 Tip: If you want automatic detection of new files

Replace the GLOB with CONFIGURE_DEPENDS:

file(GLOB_RECURSE sources_recom CONFIGURE_DEPENDS
     ${src_home}/int_recom/*.F90
     ${src_home}/int_recom/recom/*.F90)

Then CMake automatically reconfigures when new files appear (modern CMake feature).

Can you try the chatgpt suggestion?

[a270105]

You mean like this?

if(${RECOM_COUPLED})  # ADD RECOM FILES
        #   file(GLOB sources_Fortran ${src_home}/*.F90
        #                     ${src_home}/int_recom/*.F90
        #                     ${src_home}/int_recom/recom/*.F90)
    file(GLOB_RECURSE sources_recom CONFIGURE_DEPENDS
         ${src_home}/int_recom/*.F90
         ${src_home}/int_recom/recom/*.F90)
endif()

I can't compile with this and the error message is:
[ 82%] Building Fortran object src/CMakeFiles/fesom.dir/oce_ale_ssh_splitexpl_subcycl.F90.o /home/a/a270105/fesom-2.6/fesom2/src/gen_surface_forcing.F90(48): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [RECOM_CONFIG] use recom_config -------^
recom files don't seem to be considered...

[a270105]

The only problem that might occur is when you add new files to the RECOM folder, this new files are not part of the library target that cmake check for, thus a recompilation will not be triggered unless you make a ./configure.sh --clean and build a completely new target

I did ./configure.sh --clean as well and still got the same fesom.x files, whereas libfesom.so differs.

[JanStreffing]

You always get the same fesom.x now. All the actual code is in the library. fesom.x is just a husk. It's done this way so the fesom library can be included in IFS.

[a270105]

The HPC team identified that in FESOM 2.6 the library (libfbesom.so) is dynamically loaded from the lib64/ folder, hence the fesom.x file remains the same. When the code is running, always the latest created libfesom.x file in the lib64/ folder is used and therefore will produce the same output. In FESOM 2.1 the library file (libfesom.x) was statically integrated in the executable fesom.x in the compilation process, that's why the fesom.x file was differing between different compilations. Therefore, the fesom.x and the libfesom.so files are needed to represent the current code version.

@JanStreffing that is what the HPC team told us. That means that we need to save different libraries and let fesom.x find the right one? What would be the solution for us if we run the model with different recom versions at the same time?

[JanStreffing]

Correct. I consider the library the new binary with esm_tools. I always copy it into the experiment folder and automatically point to that one.

[JudithHauck]

can you propose a job_albedo file that works with the library version, @JanStreffing (https://github.com/FESOM/fesom2/blob/main/work/job_albedo) ?
i.e.
cp -n ../bin/fesom.x cp -n ../bin/libfesom.so
?
anything else?

[JanStreffing]

Yes, I suggest you also prepend the folder you copy the library to to your LD_LIBRARY path. I do that like so:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/work/bb1469/a270092/runtime/awiesm3-develop//test_names_01/run_19000101-19000101/work//lib/fesom/
That would make the job_albedo more save to use. It would always pick up the library that was copied to the experiment dir, rather than whatever has most recently been compiled.