[solved] problem with IOF in 1/12° configs

[rdussin]

When using NATL12 in nemo3.1 with IOF and ln_2m = true, I had the error :

Floating-point zero divide PROG=sbcblk_core.turb_core_2z

To solve this :

in fldread.F90, I've changed the end loop indices to nlcj and nlci instead of jpi and jpj

in sbcblk_core.F90, I added the following line in the main loop of the TURB_CORE_2Z routine ( after ! Updating virtual potential temperature at zu) :

T_vpot_u=max(T_vpot_u,1e-15)

[sga]

Hello Sebastien.

My belief is that this problem is really to do with how IOF handles extra rows between nlcj and jpj when using mpp and nlcj<jpj.
The current version of fldread leaves the weights and the input data indices as zeroes in this strip, and the resulting interpolated arrays produced by fld_interp have also rows of zeroes. I've tested this with a run of ORCA1, but I cannot reproduce Raphael's problem of zero divides.

My solution (see attached file) is just to use jpdom_autoglo in the iom_get's used for the weights file. This means that any extra rows outside nlcj are given valid values, and the resulting interpolated arrays have identical rows nlcj and jpj when nlcj<jpj.
Any routine which performs calculations upto jpj should therefore have valid values.

Steven

[smasson]

This looks ok to me, except 2 minors points

• I think you should use jpdom_data instead of jpdom_autoglo
  
• We usually simply use ":" instead of "1:jpi" -> ref_wgts(nxt_wgt)%data_jpi(:,:,:)
  

Could you commit your changes and close the ticket?

seb

[sga]

Above changes (including Sebastien's suggestions) committed to trunk, revision 1955