[MITgcm-devel] bug: divisioin by zero

Martin Losch Martin.Losch at awi.de
Fri May 25 03:16:06 EDT 2007


Hi,

this is probably a bug:

on our new sx8 I get a division by zeros in mom_calc_visc.F for  
curvilinear grids on the cubed sphere/llc and variable viscosity. The  
culprits are recip_dxV and recip_dyU, because they are the only ones  
that are not exchanged in ini_curvilinear_grid.F
Why are they not exchanged? I gather from the comments in  
ini_curvilinear_grid, that for cube sphere exchanges this has not  
been sorted out and some sort of hack has been applied which is now  
catching up with me. What can we do?
1. use the wrong exchanges so that dxV/dyU and their reciprocals have  
values other than zero in the overlaps and keep our fingers crossed  
that no-one will notice (I assume that the viscosity values in the  
overlaps are not that important (o:)
2. modify mom_calc_visc, so that it does not compute anything in the  
overlaps (will that work?)

solution 1 changes the results of testreport for  
global_ocean.cs32x15, if I uncomment these two lines in  
ini_curvilinear_grid.F:
c     CALL EXCH_Z_3D_RS( dxV, 1, myThid )
c     CALL EXCH_Z_3D_RS( dyU, 1, myThid )
I could do this:
#ifdef TARGET_SX_NEC
      CALL EXCH_Z_3D_RS( dxV, 1, myThid )
      CALL EXCH_Z_3D_RS( dyU, 1, myThid )
#endif
which will fix the problem for me but as soon as you run into a  
compiler that is as picky as the sxf90 you'll have the problem again.

(BTW. sxf90 has options to initial all stack/heap with nan. If I do  
that the model stops in mom_vi_hdissip.F, havent' figured out yet, why.)

What do you think?

Martin

PS. I hate going to new machines, all these problems that you  
discover ...




More information about the MITgcm-devel mailing list