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

Bugfix: FGNV streamfunction vertical bounds #1346

Merged
merged 2 commits into from
Mar 13, 2021

Conversation

marshallward
Copy link
Collaborator

This patch fixes an issue with the vertical array bounds of the Ferrari
et al. streamfunction. The array is bounded across interfaces, from 1
to nz+1, but only the interior values need to be determined due to the
arbitrary boundary value (set here to zero).

In the current source, the streamfunction is rescaled before calling
streamfn_solver, but need not be applied to the boundary values. This
is unlikely to cause errors in production, since the values are later
reset to zero, but the rescaling can raise errors in more aggressive
debugging builds, such as when the arrays are initialized with NaN
values.

Thanks to @sanAkel for reporting this bug.

This patch fixes an issue with the vertical array bounds of the Ferrari
et al. streamfunction.  The array is bounded across interfaces, from 1
to nz+1, but only the interior values need to be determined due to the
arbitrary boundary value (set here to zero).

In the current source, the streamfunction is rescaled before calling
streamfn_solver, but need not be applied to the boundary values.  This
is unlikely to cause errors in production, since the values are later
reset to zero, but the rescaling can raise errors in more aggressive
debugging builds, such as when the arrays are initialized with NaN
values.
@codecov
Copy link

codecov bot commented Mar 6, 2021

Codecov Report

Merging #1346 (125b9ed) into dev/gfdl (a6f680c) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##           dev/gfdl    #1346      +/-   ##
============================================
- Coverage     45.83%   45.82%   -0.01%     
============================================
  Files           234      234              
  Lines         72663    72667       +4     
============================================
  Hits          33302    33302              
- Misses        39361    39365       +4     
Impacted Files Coverage Δ
...arameterizations/lateral/MOM_thickness_diffuse.F90 63.96% <0.00%> (-0.27%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a6f680c...33d28f1. Read the comment docs.

@@ -993,10 +993,14 @@ subroutine thickness_diffuse_full(h, e, Kh_u, Kh_v, tv, uhD, vhD, cg1, dt, G, GV
! Solve an elliptic equation for the streamfunction following Ferrari et al., 2010.
do I=is-1,ie
if (G%mask2dCu(I,j)>0.) then
Sfn_unlim_u(I,:) = ( 1. + CS%FGNV_scale ) * Sfn_unlim_u(I,:)
do K=2,nz
Sfn_unlim_u(I,K) = (1. + CS%FGNV_scale) * Sfn_unlim_u(I,K)
Copy link
Collaborator

@sanAkel sanAkel Mar 6, 2021

Choose a reason for hiding this comment

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

This is awesome 👏 thank you @marshallward

Any reason why it can't be
vectorized? e.g.,
x(index1_range, index2_range) =0. (I understand the compiler may do it!)

  • Do you anticipate different behavior for different optimizations?
  • violates coding style?
  • something else?

Copy link
Collaborator Author

@marshallward marshallward Mar 6, 2021

Choose a reason for hiding this comment

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

Yes, I think Sfn_unlim_[uv](2:nz) = ... would have been OK here, other than that it's discouraged by the style guide (although your example might be permitted).

This next line is a very explicit break from the style guide:

call streamfn_solver(nz, c2_h_v(i,:), hN2_v(i,:), Sfn_unlim_v(i,:))

due to the sliced array inputs - and the implicit 1D arrays - but they are only 1D arrays so I figured let's leave it for another day.

I wouldn't expect vectorization to be affected in this case, but compilers always have a surprise or two.

Copy link
Collaborator

@sanAkel sanAkel left a comment

Choose a reason for hiding this comment

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

@marshallward thanks for the fix.
[Our debug build now works with this fix and optimized (i.e., repro) has no change in answer.]

Copy link
Collaborator

@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 a good idea and could avoid some difficulties with aggressive compilers.

@adcroft adcroft self-assigned this Mar 12, 2021
@adcroft
Copy link
Collaborator

adcroft commented Mar 12, 2021

@adcroft adcroft merged commit 8dd9072 into mom-ocean:dev/gfdl Mar 13, 2021
@marshallward marshallward deleted the fgnv_bound_fix branch May 7, 2021 02:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants