[MITgcm-devel] solve_tri/pentadiagonal and adjoint

[Jean-Michel Campin]

Hi Martin,

to recap:
a) original version
b) k-loop inside
c) your new version with (5 more 3-D local arrays)

so (c) will replace (a) ?
and if (in forward) I would like to reduce memory usage but keep 
vectorisation ?

Cheers,
Jean-Michel

On Thu, Oct 13, 2011 at 10:38:27AM +0200, Martin Losch wrote:
> Hi there,
> 
> I am going to check-in modified solve_tri/pentadiagonal where I remove the hard-wiring of the CPP flag ALLOW_SOLVER_KLOOPINSIDE to #ifdef ALLOW_AUTODIFF
> Instead I found a way to make the adjoint work with the original code (it does require more memory, 5 additional local 3d fields, than Gael's solution), that leads to vectorizable adjoint code.
> 
> I find the flag ALLOW_SOLVER_KLOOPINSIDE very useful, probably we need to think about a flag like this to move more k-loops "inside" everywhere in the code in order to do more computations out of the local cache with these multi-processor (band-limited) chips. But I also think that this flag should be set outside individual routines and not hardwired to other flags.
> 
> Any objections?
> 
> Martin
> PS. there are no tests in verification that test this code, unfortunately.
> 
> On Oct 10, 2011, at 3:09 PM, Martin Losch wrote:
> 
> > Hi Gael (and others),
> > 
> > I know I am a little exotic in that I always want to have vectorizable (adjoint) code. Here's another sequel of this story:
> > 
> > in solve_tridiagonal and solve_pentadiagonal, you introduced code that moves the k-loop inside of the i/j-loops in the case of ALLOW_TAMC_AUTODIFF. Your check-in comment (Aug,2010) was:
> > Adjoint related modifications -- allowing the use of implicit vertical advection in adjoint model.
> > Can you remember, why this is necessary? The recomputations seem to be OK, but my experiment blows up. Where does it go wrong and maybe there is an alternative way to fix it?
> > 
> > Martin
> > 
> > PS. You can image that moving the k-loop inside the i/j-loops is terrible for performance on a vector computer, but it also makes even worse (from a vectorization point of view) adjoint code, so that effectively I cannot use the implVertAdv in adjoint mode if it only works like this.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel