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

Fix USE_CONT_THICKNESS bug #697

Merged
merged 2 commits into from
Aug 21, 2024
Merged

Conversation

awallcraft
Copy link

Optionally correct a bug due to a missing halo exchange. This likely isn't needed when compiled for nonsymmetric memory, but the added halo exchange does no harm in such cases. The pass_vector call could probably be replaced with fill_symmetric_edges, except there is no subroutine fill_vector_symmetric_edges_3d.

USE_CONT_THICKNESS is not yet widely used, so rather than preserving the old (incorrect) solutions by default, this bug is corrected by default. However, the previous answers can be recovered by setting the new runtime parameter USE_CONT_THICKNESS_BUG to true. This parameter is only used (and logged) when USE_CONT_THICKNESS set to true.

By default, this commit does change answers in symmetric memory cases with USE_CONT_THICKNESS = True, and there is a new runtime parameter in such cases.

Optionally correct a bug due to a missing halo exchange.  This likely
isn't needed when compiled for nonsymmetric memory, but the added halo
exchange does no harm in such cases.  The pass_vector call could probably
be replaced with fill_symmetric_edges, except there is no subroutine
fill_vector_symmetric_edges_3d.

USE_CONT_THICKNESS is not yet widely used, so rather than preserving the old
(incorrect) solutions by default, this bug is corrected by default.  However,
the previous answers can be recovered by setting the new runtime parameter
USE_CONT_THICKNESS_BUG to true.  This parameter is only used (and logged)
when USE_CONT_THICKNESS set to true.

By default, this commit does change answers in symmetric memory cases with
USE_CONT_THICKNESS = True, and there is a new runtime parameter in such cases.
Copy link
Member

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that these changes are necessary.

However, I think that it would be more efficient if the extra halo update were moved outside of horizontal_viscosity() and instead were a part of the group pass for the other variables that come out of the continuity solver calls in step_MOM_dyn_split_RK2(). This would also allow for the intent of the hu_cont and hv_cont arguments to be kept as intent(in), which is more consistent with how they are actually used.

For now, I am going to suggest that we accept this PR as it stands, but with a plan to explore whether moving the new halo update outside of horizontal_viscosity() would be cleaner and more efficient.

@Hallberg-NOAA Hallberg-NOAA added bug Something isn't working Parameter change Input parameter changes (addition, removal, or description) labels Aug 20, 2024
@marshallward
Copy link
Member

@marshallward marshallward merged commit 42c1a32 into NOAA-GFDL:dev/gfdl Aug 21, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Parameter change Input parameter changes (addition, removal, or description)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants