[MITgcm-devel] impldiff/solve_tridiagnonal

[Martin Losch]

Hi Jean-Michel,

interesting that you remember that. Yes, we have a new computer (o: So optimization starts again from scratch …

no, I am not using CD_CODE. I could use mom/salt/tempImplVertAdv = .TRUE., right?

Martin

> On 28 Sep 2016, at 19:16, Jean-Michel Campin <jmc at mit.edu> wrote:
> 
> Hi Martin,
> 
> I found an email on the list iwith an interesting Post-Scriptum that was arguing 
> in the other direction, i.e., to allow NOT to use SOLVE_DIAGONAL_KINNER code:
> http://mitgcm.org/pipermail/mitgcm-devel/2011-October/004995.html
> 
> But appart from that (and I agree that this performance issue is platform/compiler 
> dependent), I thought we could try not to use impldiff.F anymore (most of the code 
> is there except for CD_CODE) and leave impldiff.F to the retirement track.
> Are you using the CD_CODE ?
> 
> Cheers,
> Jean-Michel
> 
> On Wed, Sep 28, 2016 at 06:41:07PM +0200, Martin Losch wrote:
>> Hi there,
>> 
>> impldiff.F turns out to be one of the expensive routines on some platforms. One of the reasons is apparently poor cache efficiency. In solve_tridiagonal this is ???solved??? by moving the k-loop inside the i,j loops. There???s a CPP flag SOLVE_DIAGONAL_KINNER to turn that on in solve_tridiagonal.
>> 
>> Would anyone object to me implementing something like this in impldiff.F? I would use SOLVE_DIAGONAL_KINNER (off by default) to turn this feature on.
>> 
>> Martin
>> 
>> PS. would be much better if impldiff would actually call solve_tridiagonal, right?
>> 
>> 
>> _______________________________________________
>> 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