This bug have been fixed by the NOCS people (Beverly or Andrew) : It seems that lbc_lnk(emp, 'T',1) at the end of sbcmod (see attached file) fixes problems related to north fold boundary in ORCA configuration.

We discover that this fix is also required for open boundary configuration (eg PERIANT8) when running in MPP.

I think then that this statement should be restored in the standard version !

NEMO 3.1 on a NEC SX9 has half of the performance compared to NEMO 2.3. This can be attributed to the communication along the north-fold boundary condition. We have performed the following test:

1. ORCA05 on 4x1 PE under NEMO 2.3
2. ORCA05 on 4x1 PE under NEMO 3.1 (with IOF)
3. ORCA05 on 4x1 PE under NEMO 3.1 jperio=1 (with IOF)

We performed following experiments of NEMO 3.1 on NEC SX9:

-IOF 4x1 PE, 1215 timesteps (CPU TIME = 2667.269 sec.)

-IOF 1x4 PE, 1215 timesteps (CPU TIME = ) FAILED!!!

-OFFLINE 4x1 PE, 1215 timesteps (CPU TIME = 2661.805 sec )

-OFFLINE 1x4 PE, 1215 timesteps (CPU TIME = 1615.761 sec. )

The experiment with IOF and 1x4 failed with following error:

252 Floating-point zero divide PROG=sbcblk_core.psi_h ELN=29(4001fcd08)

Maybe their is a problem with IOF and extra halos and/or a SX9 specific problem. We can not profit from the performance of "latitude cutting" (1x4) and IOF, which would improve the performance (see ​http://forge.ipsl.jussieu.fr/nemo/ticket/445).