+Add CPP macro _USE_OCEAN_BGC_PR20 to avoid bug #279
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added the new CPP macro _USE_OCEAN_BGC_PR20 to deal with the fact that the recently added element runoff_added_to_stf does not yet exist within the ocean_BGC version of the g_tracer_type, although it was added to the version in confic_src/external/GFDL_ocean_BGC/generic_tracer_utils.F90 as a part of PR#246. This caused the latest version of MOM6 to be unable to compile with the ocean_BGC code. With this new CPP macro, the code will once again compile, and these bits of code can be enabled once the ocean_BGC code has this new element in its version of the g_tracer_type. Once there is sufficiently widespread adoption of newer versions of the ocean_BGC code, these newly added macros can be eliminated altogether. This commit should address the issued documented under github.com/NOAA-GFDL/issues/278. Note that the use of CPP macros in this way is generally strongly discouraged in MOM6, but it does seem like a viable solution for addressing an interface change across two separately managed code repositories.
Codecov Report
@@ Coverage Diff @@
## dev/gfdl #279 +/- ##
=========================================
Coverage 37.13% 37.13%
=========================================
Files 263 263
Lines 73444 73443 -1
Branches 13674 13674
=========================================
+ Hits 27272 27274 +2
+ Misses 41147 41145 -2
+ Partials 5025 5024 -1
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
I'm not comfortable adding a CPP macro to solve this. We know it will cause trouble to remove if it ever gets in the code. And to use it you have to change your build scripts, which is no less disruptive than commenting out the offending line of code. Alternatively, we could comment out the line of code now and line up another PR to uncomment it once the BGC code is updated. |
|
I agree with the arguments that these CPP macros are not the right solution for the long-term, and I am withdrawing this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added the new CPP macro _USE_OCEAN_BGC_PR20 to deal with the fact that the recently added element runoff_added_to_stf does not yet exist within the ocean_BGC version of the g_tracer_type, although it was added to the version in confic_src/external/GFDL_ocean_BGC/generic_tracer_utils.F90 as a part of PR#246. This caused the latest version of MOM6 to be unable to compile with the ocean_BGC code. With this new CPP macro, the code will once again compile, and these bits of code can be enabled once the ocean_BGC code has this new element in its version of the g_tracer_type. Once there is sufficiently widespread adoption of newer versions of the ocean_BGC code, these newly added macros can be eliminated altogether. This commit should address the issued documented under github.com//issues/278. Note that the use of CPP macros in this way is generally strongly discouraged in MOM6, but it does seem like a viable solution for addressing an interface change across two separately managed code repositories.