Abort in icepack_itd.F90 due to negative dvice.

[dabail10]

This code is slightly different from CICE5. I think this should be dvice < -puny and not -puny x vicen(nd). The NOAA folks have found a case where puny x vicen(nd) is 1.0e-61. So, it aborts with negative dvice. The CICE5 code checks for aicen < puny. Thoughts?

           if (dvice(n) < c0) then
              if (dvice(n) > -puny*vicen(nd)) then
                 daice(n) = c0 ! shift no ice
                 dvice(n) = c0
              else
                 dvice_negative = .true.
              endif
           endif

[eclare108213]

I'm confused. @dabail10 can you paste in the equivalent code block from CICE5, and for both of them, include conditional wrappers that might be further away in the code structure (like aicen > puny)?

[dabail10]

Apparently I was confused as well. This is the same code in CICE5 in shift_ice!

           if (dvice(ij,n) < c0) then
              if (dvice(ij,n) > -puny*vicen(i,j,nd)) then
                 daice(ij,n) = c0 ! shift no ice
                 dvice(ij,n) = c0
              else
                 dvice_negative = .true.
              endif
           endif

So, again I think this is an initialization problem. The donor value is > 0 and dvice is slightly negative here. However, it was aborting in CICE6, but not in CICE5 for the NOAA folks. Here is the message:

(shift_ice)shift_ice: negative dvice
(shift_ice)boundary, donor cat: 1 2
(shift_ice)daice = 0.000000000000000E+000
(shift_ice)dvice = -1.646291257815409E-061
(icepack_warnings_setabort) T :file icepack_itd.F90 :line 546
(shift_ice) shift_ice: negative dvice
(icepack_warnings_aborted) ... (shift_ice)
(icepack_warnings_aborted) ... (linear_itd)
(icepack_warnings_aborted) ... (icepack_step_therm2)

Dave

[eclare108213]

Okay, it might be an initialization problem and roundoff differences, but it's also possible that the run is reaching this part of the code in v6 but was prevented from doing so in v5, so there might still be a difference in conditionals somewhere.

[dabail10]

I believe this is related to #333

[eclare108213]

I'll close this issue, assuming that #333 takes care of it. If it pops up again we can reopen.

[NickSzapiro-NOAA]

It seems like this is popping up again. In UFS in GEFS and SFS development for quite a few cases (like ufs-community/ufs-weather-model#2562).

Towards making these changes, maybe I can check in about a few points here, @eclare108213 @dabail10 @apcraig or others?

Maybe we are in the oddities of "residual ice" but aicen and vicen can apparently be quite small ~O(1E-65). Then, for example, the daice_negative check that

if (daice(n) < c0) then
  if (daice(n) > -puny*aicen(nd))

may lead to an unnecessary abort in the sense that ice with -puny < {a,v}icen < -puny*{a,v}icen "roundoff error" is still within bounds of cleanup_itd and zap_small_areas.

Changing these puny*{a,v}icen --> puny for these 4 QC checks was confirmed to be a "quick fix" for at least one case in the UFS issue above. fyi, these terms are in a few places (like columnphysics/icepack_therm_itd.F90 too).

With the changes, if we march along in the code after shift_ice I worry whether these diffs that can now be O(puny) can lead to failures in column_conservation_check with max_err=puny if there are multiple categories with almost -puny ice. I don't know if this is a conservation edge case vs. a situation that should fail...