[MITgcm-devel] impldiff/solve_tridiagnonal

Martin Losch martin.losch at awi.de
Thu Oct 6 04:54:39 EDT 2016 

Sound good to me.
M.

> On 06 Oct 2016, at 07:02, Jean-Michel Campin <jmc at mit.edu> wrote:
> 
> Hi Martin,
> 
> I've checked that, after adding parenthesis (which indeed involves updating > 30 
> output*.txt), the switch of solution (2) does not change the results anymore.
> 
> So, will probably make the parenthesis modif tomorrow and wait for an other
> day to finish solution (2).
> 
> Cheers,
> Jean-Michel
> 
> On Tue, Oct 04, 2016 at 03:19:00PM +0200, Martin Losch wrote:
>> Hi Jean-Michel,
>> 
>> naively I would have just tried (1), but I agree with you that (2) sounds far more attractive in reducing duplicates. 
>> In terms of readability ???impldiff??? makes a little more sense to me (maybe just because I am used to it?), but I would think that your move towards removing redundant code is the best (so: 2).
>> 
>> Martin
>> 
>>> On 03 Oct 2016, at 23:30, Jean-Michel Campin <jmc at mit.edu> wrote:
>>> 
>>> Hi Martin,
>>> 
>>> I tried few things:
>>> 
>>> 1) I can call SOLVE_TRIDIAGONAL from S/R IMPLDIFF and this does not 
>>> seem to change the results (need still to check ADM and verification_other exp)
>>> but this is not what I was going for initially.
>>> 
>>> 2) assuming that INCLUDE_IMPLVERTADV_CODE is defined, I try to replace the 
>>> call to IMPLDIFF by calling GAD_IMPLICIT_R and MOM_U,V_IMPLICIT_R (even when 
>>> temp,saltImplVertAdv=F and momImplVertAdv=F); since this switch could be disable
>>> at compile time (#undef INCLUDE_IMPLVERTADV_CODE) I thought it would be better
>>> than (1) in moving towards removing duplicated code. 
>>> But doing this changes the results: less than 13 digits left for most (24) of 
>>> the FWD exp that use implicitDiffusion or implicitViscosity, with some changing
>>> much more:
>>>  lab_sea.hb87    2.digits left
>>>  deep_anelastic  6
>>>  front_relax.bvp 9
>>> and many with only 10.digits left
>>> 
>>> It seems that the largest output differences are caused by one coding diff:
>>> in implidiff.F, line 187:
>>>         b(i,j,k) = 1. _d 0 - c(i,j,k) - a(i,j,k)
>>> whereas in gad_implicit_r.F and mom_u,v_implicit_r.F the equivalent code
>>>  (using the same variable names as in implidiff.F) would be:
>>>         b(i,j,k) = 1. _d 0 - a(i,j,k) - c(i,j,k)
>>> 
>>> Regarding Adjoint results, less changes there, partly because not many
>>> experiments have #define INCLUDE_IMPLVERTADV_CODE and, for the rest,
>>> forward gradient are affected more than AD gradient.
>>> 
>>> I am considering changing the code on both side, by adding parenthesis,
>>> which should make it independent of which routine is used. It's likely
>>> to involve many update of results/output*.txt but they will (hopefully)
>>> have to be changed only once (will check this before changing anything).
>>> 
>>> Should I try this solution or just go for the simplest solution (1) ?
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> On Thu, Sep 29, 2016 at 08:41:21AM -0400, Jean-Michel Campin wrote:
>>>> Hi Martin,
>>>> 
>>>> I am going to try few things there, and will let you know 
>>>> (probably earlier next week) how things go.
>>>> 
>>>> Cheers,
>>>> Jean-Michel
>>>> 
>>>> On Thu, Sep 29, 2016 at 07:35:15AM +0200, Martin Losch wrote:
>>>>> Hi Jean-Michel,
>>>>> 
>>>>> I am all for it. Do you know what to do exactly or should I try to figure it out?
>>>>> 
>>>>> Martin
>>>>>> On 29 Sep 2016, at 01:58, Jean-Michel Campin <jmc at mit.edu> wrote:
>>>>>> 
>>>>>> Hi Martin,
>>>>>> 
>>>>>>> I could use mom/salt/tempImplVertAdv = .TRUE., right?
>>>>>> It's not really available, would need to change the code (change 2 or 3 "IF ()")
>>>>>> so that the routines that deal with implicit vertical advection
>>>>>> (i.e., mom_u_implicit_r.F, mom_v_implicit_r.F & gad_implicit_r.F ) 
>>>>>> are also called when just implicit diffusion/viscosity is turned on (even without 
>>>>>> implicit advection) since these routines are also doing the vertical diffusion.
>>>>>> 
>>>>>> Cheers,
>>>>>> Jean-Michel
>>>>>> 
>>>>>> On Wed, Sep 28, 2016 at 09:04:00PM +0200, Martin Losch wrote:
>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list