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


Ignore:
Timestamp:
2017-02-22T15:04:17+01:00 (4 years ago)
Author:
frrh
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • ticket/1851/General

    v6 v7  
    9494The 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.  
    9595 
    96  
    97   
     96Contacted JP to see if we can remove these things from namelists.  
    9897 
    9998 
     99'''CICE OOB error''' 
     100 
     101The 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: 
     102{{{ 
     103     j_global(j,n) = -j_global(j,n) 
     104}}} 
     105 
     106That seems crazy.... how can giving it a negative index which is clearly OOB help? 
     107 
     108The 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) 
     109or 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.  
     110 
     111So the fact that our original code runs at all is pure blind luck! 
     112This all looks very unsafe but I can't find a way to keep it in bounds w/o altering results....! 
     113