[MITgcm-devel] pkg/seaice pseudo time stepping for LSOR
Martin Losch
Martin.Losch at awi.de
Wed May 27 07:18:49 EDT 2009
Hi Patrick,
I have not changed anything that changes the results.
If you want to test if my fix for the free-slip case works for you too
(please do check that if you have the time), then you can add this in
seaice_lsr:
IF (.NOT.SEAICE_no_slip) THEN
C in the free-slip case, impose no lateral stress by setting
C eta to zero on the boundary
DO J=1,sNy+1
DO I=1,sNx+1
etaMeanZ (I,J,bi,bj) = etaMeanZ(I,J,bi,bj)
& *maskC(I,J, k,bi,bj)*maskC(I-1,J, k,bi,bj)
& *maskC(I,J-1,k,bi,bj)*maskC(I-1,J-1,k,bi,bj)
ENDDO
ENDDO
ENDIF
right after the computation of etaMeanZ, see also on the authors
network: ~mlosch/scratch/MITgcm/pkg/seaice/seaice_lsr.F
This changes the results (indicating that something is wrong with the
free slip boundary conditions), but I don't want to check in another
bug, before we have some confidence that it works for everybody (it
works for Dimitris et al., both their Arctic and CS510 experiments).
Martin
On May 27, 2009, at 10:28 AM, Patrick Heimbach wrote:
>
> 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
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list