#1214 closed Bug (fixed)
Division by zero in lim_itd_me_ridgeprep (LIM3)
Reported by: | ufla | Owned by: | vancop |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | LIM3 | Version: | v3.6 |
Severity: | Keywords: | LIM* v3.6 | |
Cc: |
Description
When running r4346 of dev_MERGE_2013 I get division by zero in line 682 of LIM_SRC_3/limitd_me.F90 when astar is used:
astari = 1.0/astar
This variable should be initialised from namelist namiceitdme in subroutine lim_itd_me_init, however, the above line is reached via the call tree:
sbc --> sbc_ice_lim --> lim_dyn --> lim_rhg --> lim_itd_me_icestrength --> lim_itd_me_ridgeprep
So, in that case, lim_itd_me_init is not called before before the use of astar (and other variables?).
Commit History (1)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
4831 | flavoni | 2014-11-06T15:12:46+01:00 | moved the call to lim_itd_me_init to initialize variables at right moment, see ticket #1214 and #1308 |
Attachments (1)
Change History (12)
comment:1 Changed 10 years ago by ufla
comment:2 Changed 10 years ago by clem
I do not see your point here. Maybe I'm wrong but to me, astar is initialized at the very beginning of the module limitd_me.F90 (via the call to lim_itd_me_init). Therefore astari, which is used later on in the same module (in lim_itd_me_ridgeprep) should also be defined right?
comment:3 Changed 10 years ago by ufla
Correct, astar is initialised in lim_itd_me_init, which is called from lim_itd_me. However, the code in sbcice_lim.F90 (lines 337..341) looks like this:
337 CALL lim_dyn( kt ) [...] 341 CALL lim_itd_me
So before lim_itd_me is called (and initialises astar via lim_itd_me_init), there is a call to lim_dyn. This leads to a call to lim_itd_me_ridgeprep, which uses astar. This means that the call to lim_dyn bypasses lim_itd_me and, hence, lim_itd_me_init.
Put in another way: There are two places that call lim_itd_me_ridgeprep, one is lim_itd_me (which makes sure all is initialised) and the other is lim_itd_me_icestrength (which bypasses initialisation).
I run into the problem when I tested the code with floating point exceptions enabled. It says division by zero and using a debugger I found the astar being zero when used in lim_itd_me_ridgeprep.
comment:4 Changed 10 years ago by ufla
Just as a test, i moved the line that initialises the limitd_me module:
IF( numit == nstart ) CALL lim_itd_me_init ! Initialization (first time-step only)
from the lim_itd_me subroutine to lim_itd_me_icestrength and that makes to code work. Of course, I have no idea about side-effects, so I'm not assuming that this is a good fix. See attached patch.
Changed 10 years ago by ufla
Patch that moves the initialisation of the limitd_me. (Not suggested as permanent fix)
comment:5 Changed 10 years ago by clevy
- Owner changed from NEMO team to vancop
comment:6 Changed 10 years ago by flavoni
fix in revision 4831 of trunk:
moved call to initialization of lim_itd_me_init in iceini.F90
(this solution works also for ticket #1308)
Simona
comment:7 Changed 10 years ago by flavoni
- Resolution set to fixed
- Status changed from new to closed
comment:8 Changed 7 years ago by nemo
- Keywords LIM* added
comment:9 Changed 7 years ago by nemo
- Keywords release-3.6* added
comment:10 Changed 7 years ago by nemo
- Keywords release-3.6* removed
comment:11 Changed 2 years ago by nemo
- Keywords v3.6 added
I can add that in sbc_ice_lim, lines 337--342, lim_dyn is called first (and triggers the error), whereas lim_itd_me (which in turn calls lim_itd_me_init) is called afterwards, which is too late.