[MITgcm-devel] (not so) funny things happen in seaice_lsr and pickups

[Martin Losch]

Hi Jinlun,

don't worry about comments about bugs. I am known to produce many,  
which I then gloriously find half a year later. In this case I  
actually did find another small bug today (an index of tan(phi)), so I  
need to start a new run. Since the impact of the metric terms is  
mostly very small, it takes very long and somewhat extreme conditions,  
until the model blows up. So it's tedious ...

After thinking about it, I perfectly agree with you that the Laplacian  
operation is always symmetric, and should lead to a diagonally  
dominant matrix. If the matrix is not diagonally dominant, then there  
has been a coding error that breaks the symmetry of the laplacian  
operator (if the coding error is small, the asymmetry is small and you  
will not notice this until something extreme happens). It's perfectly  
plausible. What's not plausible, is that I have ignored testing the  
metric terms for almost years now.

The Coriolis force on the C-grid is always tricky as u and v are not  
on the same point. Not sure how to solve your equation (6) in Zhang 
+Hibler (1997) on a C-grid ... but it may not be necessary. I'll think  
about it.

Martin

On Mar 5, 2009, at 5:57 PM, Jinlun Zhang wrote:

> Hi Martin,
>
> ZMIN should be zero. Sorry for the comment about a bug (o:. I was  
> guessing around. Maybe it is not due to a bug,  but to coriolis  
> force. Did you try the third level solution that tries to make  
> coriolis implicit?
>
> Jinlun
>
>
>
> Martin Losch wrote:
>> Dimitris,
>>
>> I like option 2 best. Especially, since my fixes to the metric  
>> terms will affect some of the experiments anyway (e.g. lab_sea).
>>
>> Another thing is this parameter SEAICE_zetaMin, which defaults to  
>> zero right now. Originally there was a miniumum zeta (ZMIN=4e8),  
>> which I removed following Jinlun's advice (Jinlun: please correct  
>> me if I am wrong). I "feel" that this parameter may have an impact  
>> on my problems, too. As far as I remember, it should not be  
>> necessary for stability reasons, but the these large gradients of P/ 
>> eta/zeta, it would actually help. I guess Jinlun will maintain,  
>> that I should keep looking for a bug in the code, right? (o:
>>
>> Martin
>> On Mar 4, 2009, at 9:38 PM, Dimitris Menemenlis wrote:
>>
>>> Martin and Jean-Michel, shall we:
>>>
>>> 1) make SEAICE_clipVelocities=.false. the default and change  
>>> verification output accordingly,
>>>
>>> 2) make SEAICE_clipVelocities=.false. the default but set  
>>> to .true. in the verification experiments for backward  
>>> compatibility ... with a warning that clipping should not be used,  
>>> or
>>>
>>> 3) leave things as is?
>>>
>>> There are two verification experiments that are affected by  
>>> SEAICE_clipVelocities:
>>>
>>> SEAICE_clipVelocities=.true.
>>> Y Y Y Y>16<16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 pass   
>>> global_ocean.cs32x15.icedyn
>>> Y Y Y Y> 6<12 12  9 10 16 14 10  9 10 10  7  6  8 10  7  6 FAIL   
>>> lab_sea.salt_plume
>>>
>>> SEAICE_clipVelocities=.false.
>>> Y Y Y Y> 8<14 16 13 14 16 16 14 13 13 16 12 13 13 13 11 13 FAIL   
>>> global_ocean.cs32x15.icedyn
>>> Y Y Y Y> 5<11 11  8  8 12 13 10  8  8  7  6  6  5  6  6  6 FAIL   
>>> lab_sea.salt_plume
>>>
>>> D.
>>>
>>> On Mar 4, 2009, at 11:55 AM, Martin Losch wrote:
>>>
>>>> we don't need to take it out, we just need to specify a flag  
>>>> (SEAICE_clipVelocities=.false.),
>>>
>>> _______________________________________________
>>> 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
>
>
> -- 
>
> Jinlun Zhang
> Polar Science Center, Applied Physics Laboratory
> University of Washington, 1013 NE 40th St, Seattle, WA 98105-6698
>
> Phone: (206)-543-5569;  Fax: (206)-616-3142
> zhang at apl.washington.edu
> http://psc.apl.washington.edu/pscweb2002/Staff/zhang/zhang.html
>
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel