Opened 11 years ago

Closed 10 years ago

#583 closed Bug (fixed)

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

Reported by: rdussin Owned by: smasson
Priority: low Milestone:
Component: OCE Version: release-3.1
Severity: Keywords: IOF


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) :


Commit History (1)


NEMO trunk: fldread.F90 change extent of data read in from weights file to jpi,jpj so output array has valid value everywhere see ticket #583

Attachments (3)

fldread.F90 (49.2 KB) - added by rdussin 11 years ago.
sbcblk_core.F90 (47.4 KB) - added by rdussin 11 years ago.
fldread.patch (2.3 KB) - added by sga 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 11 years ago by rdussin

Changed 11 years ago by rdussin

comment:1 Changed 10 years ago by smasson

  • Owner changed from NEMO team to smasson

comment:2 Changed 10 years ago by smasson

  • Status changed from new to assigned

Changed 10 years ago by sga

comment:3 Changed 10 years ago by 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.


comment:4 Changed 10 years ago by 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?


comment:5 Changed 10 years ago by sga

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.