search

NOAA-GFDL / SIS2

NOAA-GFDL's Sea Ice Simulator version 2
Other
16 stars 42 forks source link

blowing up in advection in debug mode #122

Closed kshedstrom closed 4 years ago

kshedstrom commented 4 years ago

I'm getting an error from line 1240 of SIS_tracer_advect.F90, where hnew is 1.23e-311, hlst(i) is 4.4e-23 and vhh(i,J), vhh(i,J-1) are 1.4e-53, 2.4e-52. I'm not dividing by zero, but close enough.

The new Arctic ice initialization is closer to the amount of ice I want, but now it runs 21 hours before blowing up instead of two months. This is in the debugger using a 21-hour restart.

MJHarrison-GFDL commented 4 years ago

CFL_MASS_NEGLECT_BUG (true by default)?

kshedstrom commented 4 years ago

Mine is false. Should I change it?

MJHarrison-GFDL commented 4 years ago

No. Documentation says this is only there to support older configurations and should be False for new runs.

kshedstrom commented 4 years ago

It turns out not to be sensitive to that flag anyway.

Hallberg-NOAA commented 4 years ago

I don't see what the problem is with line 1240 of SIS_tracer_advect.F90 with the positive values you provide here. I_htot should be representable, and then in the next few lines it is used to divide partition h__add using 3 fractional contributions between 0 and 1 that should add up to 1. Is the code actually giving NaNs with these values, or are the indicative of even more extreme conditions when the failure might occur?

Hallberg-NOAA commented 4 years ago

I think that I might have a solution to this particular problem, but I would prefer not to add it as a PR to dev/gfdl unless it is going to work. @kshedstrom, please see if the update on https://github.com/Hallberg-NOAA/SIS2/tree/tracer_adv_refill_massless with TRACER_ADV_REFILL_MASSLESS=True addresses the problem you were encountering.

kshedstrom commented 4 years ago

The Arctic domain does run longer with this, but still not long, five days vs. 20 hours.

Hallberg-NOAA commented 4 years ago

Now that the Arctic run is out many months and is still going, I think that this issue can be safely closed. This issue has been addressed with several PRs, including #126 and #127, provided the new optional arguments introduced in these commits are set to sensible values.