[MITgcm-devel] pkg/seaice pseudo time stepping for LSOR

Wed May 27 04:28:33 EDT 2009

OK.
I just changed code so that the M-limited only appears in adjoint.

Is it worth testing latest version again with ECCO-GODAE setup
(see if it still blows?).

-p.

On May 27, 2009, at 4:23 AM, Martin Losch wrote:

> M=2 is fine, as I said, it's not clear to me how important this is  
> to the general public, I am currently debating with Bruno  
> (Tremblay) about this. It seems that LSR's convergence itself is so  
> poor that additional pseudo-time steps do not make too much of a  
> difference. (Alternatively I may have implemented it incorrectly).
>
> Putting this pseudo loop into seaice_lsr make the code even less  
> intelligible (yet another long loop spaning basically the entire  
> subroutine), but if you see benefits from doing that, go ahead. I  
> would be more in favor of having another subroutine level.
>
> Martin
>
> On May 27, 2009, at 10:16 AM, Patrick Heimbach wrote:
>
>>
>> Hi Martin,
>>
>> I could increase to M=100, but would be huge.
>> I'll change so as to put M(.NE.N) only for adjoint.
>> Two things:
>> * could we try to put pseudo loop inside seaice_lsr?
>>  It may (but not sure yet) give more options to trick adjoint.
>> * I just forgot 2nd point. Maybe it will come back...
>>
>> -p.
>>
>> On May 27, 2009, at 4:04 AM, Martin Losch wrote:
>>
>>> Hi Patrick,
>>>
>>> I didn't see, that you already fixed it with M=2. That's  
>>> perfectly OK for me. Thanks,
>>>
>>> Martin
>>>
>>> On May 27, 2009, at 9:10 AM, Martin Losch wrote:
>>>
>>>> Hi Patrick,
>>>>
>>>> I was afraid of that. Unfortunately it's hard to say what  
>>>> iteration count is to be expected, basically I want to play  
>>>> around with this. In the recent paper by Lemieux and Tremblay  
>>>> (http://www.agu.org/pubs/crossref/2009/2008JC005017.shtml), they  
>>>> find that their model reaches convergence only after 10,500  
>>>> iterations. I think that that number is far too much for the  
>>>> generally small time steps that we are usually using nowadays,  
>>>> but I cannot claim that 100 or 1000 are better guesses.
>>>>
>>>> Can you set a hard limit at say 100, that is only active for  
>>>> adjoint computations? The (absolutely feasible) alternative is  
>>>> that I just keep my local copy of this parameter. Go for 100.
>>>>
>>>> Martin
>>>>
>>>> On May 27, 2009, at 12:02 AM, Patrick Heimbach wrote:
>>>>
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> what are max. expected number of pseudo-timesteps.
>>>>> As you probably guess, your changes are producing some
>>>>> relatively ugly recomp. of seaice_lsr within adseaice_dynsolver.
>>>>> For the storing we'll need a hard limit (to be used as
>>>>> common block size).
>>>>> What's a good number?
>>>>>
>>>>> Cheers
>>>>> -p.
>>>>>
>>>>> On May 25, 2009, at 5:50 AM, Martin Losch wrote:
>>>>>
>>>>>> Hi Patrick,
>>>>>> I have checked in code to do pseudo time stepping for LSOR.  
>>>>>> Basically, the two calls to seaice_lsr in seaice_dynsolver  
>>>>>> have been replaced by a loop with a default of 2 iterations,  
>>>>>> and the copy/interpolation between time levels has been moved  
>>>>>> to seaice_lsr.
>>>>>>
>>>>>> A potential problem for the adjoint are the store directives  
>>>>>> for uicec and vicec in the 'predictor time step'. I have moved  
>>>>>> them to seaice_lsr along with the rest of the code and I have  
>>>>>> deliberately left out the "(icall-1)*ncklev_1 part of the key  
>>>>>> that is used for uice/vice, because the storing is only  
>>>>>> applied for icall==1. I am not sure if this will work properly  
>>>>>> and apologize beforehand for all problems that this may cause.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> _______________________________________________
>>>>>> MITgcm-devel mailing list
>>>>>> MITgcm-devel at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>
>>>>> ---
>>>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>>>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> ---
>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>
>>
>> _______________________________________________
>> 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

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach