[MITgcm-devel] Fwd: [MITgcm-cvs] MITgcm/doc CVS Commit

Martin Losch Martin.Losch at awi.de
Mon Jun 30 10:50:17 EDT 2014 

Hi Jean-Michel,

You are right, I didn’t pay attention to the convergence criteria, because LSR never converges anyway … 

There are so many funny things in the seaice_lsr solver that affect the adjoint code when it shouldn’t … all of this printResidual stuff, that I find very helpful seems to confuse TAF so that there are many (small, but unnecessary) recomputations. I am thinking of excluding these parts of the code (#ifndef ALLOW_AUTODIFF_TAMC).

Then the seaicemasku/v are copied around in autodiff_store/restore, which causes again recomputation, that are totally unnecessary (in my mind), because seaicemasku/v are passive variables (the “active” part in seaice_dynsolver is excluded). I’ll have to talk to Patrick about all of these things, once he has time for this.

Martin

On Jun 30, 2014, at 2:10 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Martin,
> 
> Our old 32-bit cluster has only few nodes left, and it take long
> time to run all the different tests which can't all run at the same
> time. And in particular, last Friday, the last 2 started only after 
> you checked-in the changes. So when these 2 were done, I found that 
> there was a problem with seaice-dynamics experiments.
> 
> Just had a quick look at the Friday version of seaice_lsr.F (1.93):
> might be that uTmp,vTmp are not needed within SEAICE_LSR_TRIDIAGU/V
> but we do need the part "save uIce prior to iteration" (that is gone
> in v 1.93) since it's used to test for convergence.
> 
> And good that you manged to improve the adjoint !
> 
> Cheers,
> Jean-Michel
> 
> On Mon, Jun 30, 2014 at 10:10:24AM +0200, Martin Losch wrote:
>> Hi  Jean-Michel,
>> 
>> don’t get me wrong, I probably made a mistake with testreport, i.e. running it in the wrong directory or whatever …
>> 
>> Now I did get these same FAILS and I checked in a version, that includes u/vTmp. I still don’t see, where they become necessary, but maybe it’s better this way (didn’t check the effect of removing them on the vectorization of seaice_lsr_tridiagu/v, etc.)
>> 
>> I guess on Friday I was to excited to be able to get rid off the extensive recomputation warnings in seaice_lsr, that got carried away and removed too much stuff without proper checking. The fact that the adjoint results are not affected is obvious: They don’t seem to use seaice_lsr in reverse mode, except for lab_sea: there the adjoint is different indeed, and since it is different already I modified and updated this experiment to actually take advantage of my new STORE directives and to increase the differences.
>> 
>> Martin
>> 
>> On Jun 29, 2014, at 5:09 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>> 
>>> Hi Martin,
>>> 
>>> here attached is the testreport output the I obtained last Friday 
>>> after your changes.
>>> I am currently re-running testreport to check that I did not make a 
>>> big mistake last Friday (putting back your modified seaice_lsr.F & 
>>> seaice_preconditioner.F), but it looks similar to the one
>>> I got Friday (expected, since it's the same code).
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> On Sun, Jun 29, 2014 at 12:37:51PM +0200, Martin Losch wrote:
>>>> Hi Jean-Michel,
>>>> 
>>>> That's very interesting, because I did run testreport on my local linux box that usually gives the same results as baudelaire with gfortran both for forward and adoint tests. The only changing experiment I found was labsea, which always gives slightly different results, no matter what you do. And I even ran adjoint offline exf seaice on baudelaire. Not sure where I went wrong. The most important changes were about the adjoint. On Monday, I will retry with keeping the uvtmp fields although I do not see why they should be important at all.
>>>> 
>>>> Martin
>>>> 
>>>>> On 27.06.2014, at 22:25, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>>>>> 
>>>>> Hi Martin,
>>>>> 
>>>>> Did you run testreport after your changes ?
>>>>> When I try (with MPI on old 32-bit cluster with g77 and without
>>>>> MPI on baudelaire with gfortran) I am getting a FAIL for
>>>>> most (if not all) of the exp that uses seaice-dynamics with LSR 
>>>>> 
>>>>> Also, this uTmp,vTmp was added in seaice_lsr.F revision 62
>>>>> by me (harder to go back in time before that since it was re-written
>>>>> substancially), and I don't think it was useless.
>>>>> 
>>>>> I am thinking of changing back seaice_lsr.F & seaice_preconditioner.F
>>>>> until you figure out if/how uTmp/vTmp can be removed without changing
>>>>> the results.
>>>>> 
>>>>> Cheers,
>>>>> Jean-Michel
>>>>> 
>>>>>> On Fri, Jun 27, 2014 at 04:38:01PM +0200, Martin Losch wrote:
>>>>>> let’s see, how much of the model I messed up this time … (o:
>>>>>> 
>>>>>> Have a good weekend,
>>>>>> Martin
>>>>>> 
>>>>>> Begin forwarded message:
>>>>>> 
>>>>>>> From: Martin Losch <mlosch at forge.csail.mit.edu>
>>>>>>> Subject: [MITgcm-cvs] MITgcm/doc CVS Commit
>>>>>>> Date: June 27, 2014 at 4:37:03 PM GMT+2
>>>>>>> To: <mitgcm-cvs at mitgcm.org>
>>>>>>> Reply-To: <MITgcm-cvs at mitgcm.org>
>>>>>>> 
>>>>>>> Update of /u/gcmpack/MITgcm/doc
>>>>>>> In directory forge:/tmp/cvs-serv5798/doc
>>>>>>> 
>>>>>>> Modified Files:
>>>>>>>  tag-index 
>>>>>>> Log Message:
>>>>>>> add this to the tag-index:
>>>>>>> - remove unnecessary u/vTmp from subroutine call of
>>>>>>> seaice_lsr_tridiagu/v
>>>>>>> - remove some store directives and add new ones in an effort to get
>>>>>>> finally rid off the recomputation warnings. This is successful
>>>>>>> for SEAICE_VECTORIZE_LSR defined (i.e. no extensive recomputation
>>>>>>> warnings left), but there are still too many recomputations on the
>>>>>>> solver iteration level
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> MITgcm-cvs mailing list
>>>>>>> MITgcm-cvs at mitgcm.org
>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> <tr_out.txt>_______________________________________________
>>> 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