Floating divide-by-zero MOM_continuity_PPM.90:830

[nichannah]

This can be traced back to MOM_continuity_PPM.F90:644 where d(uh) / du is set to 0 through visc_rem = 0.0. From the comments it seems there's nothing stopping visc_rem from being zero, i.e.

real, dimension(SZIB_(G)), intent(in) :: visc_rem
"...Non-dimensional between 0 (at the bottom) and 1 (far above the bottom)"

Error message with stack tracer here:

https://climate-cms.nci.org.au/jenkins/job/mom-ocean.org/job/MOM6_run/build=DEBUG,compiler=intel,experiment=ocean_only-circle_obcs,memory_type=dynamic_symmetric/36/console

[Hallberg-NOAA]

What test case is this occurring in, please?
The particular bit of code you are tracing this back to should never be exercised when visc_rem is uniformly 0. Visc_rem is only 0 for the entire water column if there is no mass anywhere in the water columns on either side of a velocity point or if it is masked out, but in this case, the integrated transport that we are trying to match (uhbt) and the first guess (uh_tot_0) should both be exactly 0 , and hence uh_err should be 0 and do_i should be .false. As a result of this logic, this (or similar) code has been working in various test cases for about the past decade in both MOM6 and GOLD before it since about 2008. If this is arising in some new test case, we will need to figure out how or why this new test case is breaking the logic as set out above.

[nichannah]

Hi @Hallberg-NOAA this is the circle_obcs test case. Thanks for the explanation, it seems I was jumping to conclusions about visc_rem.

Another possibility is that Newton's method is hitting a stationary point... Strangely I notice that this only happens in debug mode.

Anyway I'll take a closer look in light of your explanation.

[adcroft]

circle_obcs. I presume it's something to do with the recently fixing the
radiative open boundary conditions...

Dr Alistair Adcroft (Alistair.Adcroft@noaa.gov)
Princeton University Tel: (609) 987-5073
NOAA/GFDL, 201 Forrestal Road, Princeton, NJ 08540

On Mon, Oct 24, 2016 at 9:01 AM, Robert Hallberg notifications@github.com
wrote:

What test case is this occurring in, please?
The particular bit of code you are tracing this back to should never be
exercised when visc_rem is uniformly 0. Visc_rem is only 0 for the entire
water column if there is no mass anywhere in the water columns on either
side of a velocity point or if it is masked out, but in this case, the
integrated transport that we are trying to match (uhbt) and the first guess
(uh_tot_0) should both be exactly 0 , and hence uh_err should be 0 and do_i
should be .false. As a result of this logic, this (or similar) code has
been working in various test cases for about the past decade in both MOM6
and GOLD before it since about 2008. If this is arising in some new test
case, we will need to figure out how or why this new test case is breaking
the logic as set out above.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
NOAA-GFDL#372 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFlo81S52ZZZGlfbppIry6PeIQjc5JYeks5q3KwzgaJpZM4KeZxZ
.

[adcroft]

Hey! Why did my email arrive 24 hours after I sent it. No fair!

I've found the problem: the logic for Flather OBCs outside of the domain is broken in zonal_mass_flux(). The correct logic is in meridional_mass_flux() so this is an example where a symmetry test would have caught this. Committing fix shortly...

[nichannah]

Well done. I spent some time with totalview yesterday but no success - happy to see this message!

[adcroft]

Part experience but mostly luck! Did you note my comment that the symmetry tests would catch this. @Hallberg-NOAA and I have have a bet that the symmetry tests will reveal a dozen and six (respectively) similar bugs.

[nichannah]

Yes, I saw that. My bet would be in the same ball-park, but to make it interesting I'll go high - 15+ for symmetry and units tests.

I'm winding up to full-time on MOM6 so hopefully we can resolve this bet soon.