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

[Martin Losch]

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