fixed profiler dependency on new gftl-v2

[weiyuan-jiang]

Fix profiler dependency on gftl-v2

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[weiyuan-jiang]

This PR addresses issue #1334

[mathomp4]

Blocking for just a second so I can fix up the branch for release.

[mathomp4]

Actually, let me keep blocked as I run a GEOSgcm test.

[mathomp4]

Zero-diff and builds.

[weiyuan-jiang]

Add label DNA back. I want to understand what happens here

[weiyuan-jiang]

I guess I figure out what happened here. The include path can be inherited from dependence. Since profiler depends on mapl.shared, it inherits its include path. Mapl.shared depends on pflogger which has all gFTL's paths. In our GEOSgcm, we build and use pFlogger but in UFS, only pFlogger_stub is used. That is why in UFS, v2 path is missing. This PR should work for UFS, but we may add fake dependence to pfloger_stub to make it really mimic pFlogger.

[tclune]

@weiyuan-jiang Well done!

And this speaks directly to why it is so important for us to list all the explicit dependencies of each layer. Otherwise we get surprising results when unrelated layers are changed elsewhere in the model.

[mathomp4]

I guess I figure out what happened here. The include path can be inherited from dependence. Since profiler depends on mapl.shared, it inherits its include path. Mapl.shared depends on pflogger which has all gFTL's paths. In our GEOSgcm, we build and use pFlogger but in UFS, only pFlogger_stub is used. That is why in UFS, v2 path is missing. This PR should work for UFS, but we may add fake dependence to pfloger_stub to make it really mimic pFlogger.

Dang. Good job figuring this out. CMake is...fun this way!. The question for @tclune is: should @weiyuan-jiang add the fake dependence in pflogger_stub?

[mathomp4]

@weiyuan-jiang Okay. I talked with @tclune. I think what you should do is this. In both generic/CMakeLists.txt and in profiler/CMakeLists.txt, we should have:

GFTL::gftl-v1 GFTL::gftl-v2

The reason is that both are currently using both! You can see all the v2 uses:

❯ rg 'template.inc'
generic/VarConnVector.F90
8:#include "vector/template.inc"

generic/VarSpecVector.F90
8:#include "vector/template.inc"

profiler/MeterNodeStack.F90
9:#include "vector/template.inc"

but of course they use v1 in many more places!

[weiyuan-jiang]

@weiyuan-jiang Okay. I talked with @tclune. I think what you should do is this. In both generic/CMakeLists.txt and in profiler/CMakeLists.txt, we should have:

GFTL::gftl-v1 GFTL::gftl-v2

The reason is that both are currently using both! You can see all the v2 uses:

❯ rg 'template.inc'
generic/VarConnVector.F90
8:#include "vector/template.inc"

generic/VarSpecVector.F90
8:#include "vector/template.inc"

profiler/MeterNodeStack.F90
9:#include "vector/template.inc"

but of course they use v1 in many more places!

Changed

[mathomp4]

Thanks. I'll do a build-and-run test to be sure all is well.

[mathomp4]

Works for me. Approving.

[tclune]

GFTL::gftl and GFTL::gftl-v1 are the same thing. So one should not specify them both.

Someday GFTL::gftl will be an alias for gftl-v2. It sort of provides a future-safe way of upgrading, except that the Fortran files still need to change for it to help. Probably a waste of effort on my part.