[Workaround available] Unable to use e3sm_deoptimize_file() or e3sm_add_flags() to adjust the optimization level of eam/src/physics/cosp2/local/cosp.F90

[dqwu]

Below are typical usages to change the optimization level of some Fortran files:

set(NOOPT
  eam/src/physics/cam/zm_conv.F90)

if (NOT DEBUG)
  foreach(ITEM IN LISTS NOOPT)
    e3sm_deoptimize_file(${ITEM})
  endforeach()
endif()

set(REDOPT
  ../driver-mct/main/seq_io_mod.F90
  elm/src/biogeophys/BandDiagonalMod.F90)

if (NOT DEBUG)
  foreach(ITEM IN LISTS REDOPT)
    e3sm_add_flags("${ITEM}" "-O1 -g")
  endforeach()
endif()

However, it seems that these methods do not work for certain Fortran files, such as eam/src/physics/cosp2/local/cosp.F90.

I found this issue when I tried to use cce/16.0.1 to build SCREAM, which requires me to change the optimization level of cosp.F90 to O1 or O0 to avoid ICE. I tried the above methods in Depends.frontier-scream-gpu.crayclang-scream.cmake, but they did not work.

I think the issue here is that the build of cosp.F90 under eam/src is actually controlled by eamxx/src/physics/cosp/CMakeLists.txt as an external COSP library.

My current workaround is to change the optimization level in that CMakeLists.txt:

# Build external COSP library (this is all Fortran code)
set(EAM_COSP_DIR ${SCREAM_BASE_DIR}/../eam/src/physics/cosp2)
set(EXTERNAL_SRC
   ${EAM_COSP_DIR}/cosp_kinds.F90
   ...
   ${EAM_COSP_DIR}/local/cosp.F90
   ${EAM_COSP_DIR}/external/src/cosp_stats.F90
   ...
   ${EAM_COSP_DIR}/external/subsample_and_optics_example/optics/quickbeam_optics/mrgrnk.F90
)

# My workaround to change the optimization level for cosp.F90
# Set the -O1 flag specifically for cosp.F90 for Cray Fortran compiler 16
if(CMAKE_Fortran_COMPILER_ID STREQUAL "Cray" AND CMAKE_Fortran_COMPILER_VERSION VERSION_GREATER_EQUAL "16.0.0" AND CMAKE_Fortran_COMPILER_VERSION VERSION_LESS "17.0.0")
   set_source_files_properties(${EAM_COSP_DIR}/local/cosp.F90 PROPERTIES COMPILE_FLAGS "-O1")
endif()
# End of the workaround

add_library(cosp ${EXTERNAL_SRC})

[dqwu]

This issue has been confirmed by @jgfouca with the following comment:

if that file is processed outside the main cmake file (build_model.cmake), then you may have to do your workaround