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

(*)+Restore USE_WRIGHT_2ND_DERIV_BUG functionality #686

Conversation

Hallberg-NOAA
Copy link
Member

This commit restores the effectiveness of the runtime parameter USE_WRIGHT_2ND_DERIV_BUG in determining whether a bug is corrected in the calculation of two of the second derivative terms returned by calculate_density_second_derivs_elem() with the "WRIGHT" equation of state, recreating the behavior (and answers) that are currently on the main branch of MOM6. To do this, it adds and calls the new routine set_params_buggy_Wright() when appropriate, and adds the new element "three" to the buggy_Wright_EOS type. When the bug is fixed, buggy_Wright_EOS%three = 3, but ...%three = 2 to recreate the bug. This commit does change answers for cases using the "WRIGHT" equation of state and one of the "USE_STANLEY_..." parameterizations from those on the dev/gfdl branch of MOM6, but in so doing it restores the answers on the main branch of MOM6. There is also a new publicly visible subroutine.

  This commit restores the effectiveness of the runtime parameter
USE_WRIGHT_2ND_DERIV_BUG in determining whether a bug is corrected in the
calculation of two of the second derivative terms returned by
calculate_density_second_derivs_elem() with the "WRIGHT" equation of state,
recreating the behavior (and answers) that are currently on the main branch of
MOM6.  To do this, it adds and calls the new routine set_params_buggy_Wright()
when appropriate, and adds the new element "three" to the buggy_Wright_EOS type.
When the bug is fixed, buggy_Wright_EOS%three = 3, but ...%three = 2 to
recreate the bug.  This commit does change answers for cases using the "WRIGHT"
equation of state and one of the "USE_STANLEY_..." parameterizations from those
on the dev/gfdl branch of MOM6, but in so doing it restores the answers on the
main branch of MOM6.  There is also a new publicly visible subroutine.
@Hallberg-NOAA Hallberg-NOAA added bug Something isn't working answer-changing A change in results (actual or potential) labels Jul 14, 2024
@alperaltuntas
Copy link

This PR fixes the baseline comparison failures for all but one CESM test: All of the tests using our workhorse configuration are now passing, but a quarter-degree test is failing the bitwise reproducibility test. The failing test configuration was initially based on GFDL's quarter-degree setup, with some changes over time. Note, however, that changing DEFAULT_ANSWER_DATE = 99991231 to DEFAULT_ANSWER_DATE = 20231231 fixes the baseline comparison failure for this test as well.

@Hallberg-NOAA
Copy link
Member Author

This has passed pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/24117. Because that test is comparing MOM_parameter_doc files with the results from dev/gfdl, it is falsely reporting parameter changes, but the answers are bitwise identical.

@adcroft adcroft merged commit 00f7d23 into NOAA-GFDL:gfdl-to-main-2024-05-31 Jul 17, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
answer-changing A change in results (actual or potential) bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants