Changes between Version 6 and Version 7 of ticket/1851/General

Timestamp:

2017-02-22T15:04:17+01:00 (7 years ago)

Author:

frrh

Comment:

--

ticket/1851/General

@@ -94 +94 @@
 The same goes for all the other F3 and F2 arrays listed above. SO I don't understand why they're listed in namelists if they don't get their values from there. 
 
-
- 
+Contacted JP to see if we can remove these things from namelists. 
 
 
+'''CICE OOB error'''
+
+The CICE OOB error arises from trying to access a negative J index in the global array in ice_gather_scatter. That negative index (-331) arises from ice_blocks where for tripole and tripoleT  it looks to see if j_global(j,n) > ny_global and if it is it does:
+{{{
+     j_global(j,n) = -j_global(j,n)
+}}}
+
+That seems crazy.... how can giving it a negative index which is clearly OOB help?
+
+The fact that it doesn't crash seems like pot luck. However trying to point at alternative locations within bounds fails because it either causes the model to diverge (why... this is supposed to be a halo row)
+or crashes if I get the index wrong and send it OOB with a POSITIVE value. i.e. there are two completely different behaviours when OOB is encountered - a negative index generates a warning and the code carries on but a positive index causes a crash. JCR says it's the luck of the draw depending on where the OOB pointer refers - if you stay within a page, you're OK but if not you crash. 
+
+So the fact that our original code runs at all is pure blind luck!
+This all looks very unsafe but I can't find a way to keep it in bounds w/o altering results....!
+