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

Martin Losch Martin.Losch at awi.de
Wed May 27 04:04:27 EDT 2009


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




More information about the MITgcm-devel mailing list