Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design and expression of compilation and run time options #447

Open
suvarchal opened this issue Mar 29, 2023 · 0 comments
Open

Design and expression of compilation and run time options #447

suvarchal opened this issue Mar 29, 2023 · 0 comments
Milestone

Comments

@suvarchal
Copy link
Collaborator

Consider the following points:

  • CMakeLists.txt in the root directory has a few options :

    fesom2/CMakeLists.txt

    Lines 13 to 19 in 21470c4

    option(BUILD_SHARED_LIBS "Build using shared libraries" OFF) # cmake-internal switch to toggle if library targets are being build as STATIC or SHARED, see https://cmake.org/cmake/help/latest/guide/tutorial/Selecting%20Static%20or%20Shared%20Libraries.html
    set(TOPLEVEL_DIR ${CMAKE_CURRENT_LIST_DIR})
    set(FESOM_COUPLED OFF CACHE BOOL "compile fesom standalone or with oasis support (i.e. coupled)")
    set(OIFS_COUPLED OFF CACHE BOOL "compile fesom coupled to OpenIFS. (Also needs FESOM_COUPLED to work)")
    set(CRAY OFF CACHE BOOL "compile with cray ftn")
    set(USE_ICEPACK OFF CACHE BOOL "compile fesom with the Iceapck modules for sea ice column physics.")
    set(OPENMP_REPRODUCIBLE OFF CACHE BOOL "serialize OpenMP loops that are critical for reproducible results")

    that seems could be a nice way to consolidate all fesom specific build options into one file but then there are fesom specific options like ENABLE_OPENMP, others defined in src/CMakeLists.txt. This, apart from making main CMakeLists.txt somewhat irrelevant and makes one not to trust the options in it and one always has to check whats set in src/CMakeLists.txt.
  • I am finding it hard to take scattered machine specific options in src/CMakeLists.txt, for instance machine specific options exist based on FESOM_PLATFORM_STRATEGY for levante, albedo, aleph etc and are further split using ifs based on what compiler is used . It is not like if based on $FESOM_PLATFORM_STRATEGY is in one block if it can be at-times scattered at different locations. e.g,
    if(${FESOM_PLATFORM_STRATEGY} STREQUAL levante.dkrz.de )
    message(STATUS "multithreading disabled for Levante") # multithreading suddenly produces an error, disable it until a fix is found. issue #413
    option(DISABLE_MULTITHREADING "disable asynchronous operations" ON)
    and compiler ifs

    fesom2/src/CMakeLists.txt

    Lines 147 to 154 in 21470c4

    if(${CMAKE_Fortran_COMPILER_ID} STREQUAL Intel )
    if(${BUILD_FESOM_AS_LIBRARY})
    target_compile_options(${PROJECT_NAME} PRIVATE -r8 -i4 -fp-model precise -no-prec-div -no-prec-sqrt -fimf-use-svml -xHost -ip -init=zero -no-wrap-margin -fpe0) # add -fpe0 for RAPS environment
    else()
    target_compile_options(${PROJECT_NAME} PRIVATE -r8 -i4 -fp-model precise -no-prec-div -no-prec-sqrt -fimf-use-svml -ip -init=zero -no-wrap-margin)
    endif()
    if(${FESOM_PLATFORM_STRATEGY} STREQUAL levante.dkrz.de )
    target_compile_options(${PROJECT_NAME} PRIVATE -march=core-avx2 -mtune=core-avx2)
  • env/machine/shell.xx seems to me a somewhat modular/elegant way to add a new machine with different compilers, this is currently just part of the story for building and running on that machine: one may need to add machine and compiler specific options in src/CMakelists.txt and at run time also change paths for input data for a machine in namelist.forcing,config even though we know we are on a specific machine paths are likely to be same, and find template job script from a different directory work. I wonder can this all be simplified by putting all relevant files for a particular machine in env. This also i think can reduce maintaining src/CMakeLists.txt (for example a machine reached EOL) and delegate burden of maintenance of machine specific options to users of the machine.

I think this needs to be thought of otherwise we make a mini RAPS, that may become a burden on developers and new comers.

This is to open a discussion on the issue and solutions.

@JanStreffing JanStreffing added this to the FESOM 2.6.1 milestone Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants