New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
ticket/1851/General (diff) – NEMO

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

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



  • 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.  
     96Contacted JP to see if we can remove these things from namelists.  
     99'''CICE OOB error''' 
     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: 
     103     j_global(j,n) = -j_global(j,n) 
     106That seems crazy.... how can giving it a negative index which is clearly OOB help? 
     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.  
     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....!