[MITgcm-devel] Re: [MITgcm-support] bug in exch2?

[Jean-Michel Campin]

Hi Martin,

On Thu, Jul 12, 2007 at 03:54:02PM +0200, Martin Losch wrote:
> Hi again,
> this was meant to go the the devel list in the first place, oh well.
> 
> I have tried to find where the nans in the overlaps come from, and  
> they appear when u and v are read from the pickup file with  
> read_rec_3d_rl.
> read_rec_3d_rl calls mdsreadfield, which in turn calls mds_read_fields
> In the latter two routines, the array (uVel or vVel) to be read is  
> declared as arr(*), but then mds_read_fields calls, eg. mds_seg4torl,  
> where the array is declared as
>       _RL arr(1-oLx:sNx+oLx,1-oLy:sNy+oLy,nNz,nSx,nSy)
> Could that be the source of the problem. I don't know. Should we do  
> anything about this?

I don't think this declaration is a problem.

> As a quick fix I can just use the compiler flag, that initilialises  
> everything to zero, but that would mask any other problems assciated  
> with wrong initializations.
> 
> What's your opinion?

This quick fix is worth to try.
I have ready to check in an other exch2_uv_cgrid which only 
calls exch2_rl_cube (and not exch2_rl2_cube), and I have the
impression that it could work, with the chance of getting 
an adjoint version more easily. I have also started an
exch2_uv_bgrid, but looks more compicated than what I though.

Jean-Michel

> 
> Martin
> On 11 Jul 2007, at 15:32, Martin Losch wrote:
> 
> >Hi there,
> >
> >there seems to be an initialisation issue in one/some of the exch2  
> >routines. On our beloved (God, I hate this machine) SX8, the high- 
> >res-cube stops with errors like this:
> >>   * 253 Invalid operation PROG=exch2_send_rl2 ELN=1627(40049c9d8)
> >>                 Called from read_pickup ELN=2022(40083c6a8)
> >>                 Called from ini_fields ELN=1703(4007d9d18)
> >>                 Called from initialise_varia ELN=2018(4008154cc)
> >>****  99 Execution suspended PROG=exch2_send_rl2 ELN=1627(40049c9d8)
> >>                 Called from exch2_rl2_cube ELN=1966(40048c594)
> >>                 Called from exch2_uv_3d_rl ELN=1603(4004a4a74)
> >>                 Called from exch_uv_3d_rl ELN=1826(4006f8478)
> >>                 Called from read_pickup ELN=2022(40083c6a8)
> >so at the first uv exchange. A closer look confirms that array1 and  
> >array2 in exch2_send_rl2 have nans on them in the overlap. This  
> >problem goes away, when I make the compile initialise everything to  
> >zero by default. (I also learned that apparently not the entire  
> >overlap is exchanged in exch2_rl2_cube, but only olx-1,oly-1  
> >points, at least for cubed exchanges; that would explain, why two  
> >exchanges are necessary, wouldn't it?)
> >
> >Martin
> >
> >
> >_______________________________________________
> >MITgcm-support mailing list
> >MITgcm-support at mitgcm.org
> >http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel