[MITgcm-devel] seaice revisited

[Jean-Michel Campin]

Hi Martin,

I am more concern about not being able to check and reproduce 
the ECCO-2 (cs510) runs (and, if I am right, since global_ocean.cs32x15 
uses similar ice-dynamics parameters, can be used as a proxy).
Dimitris, do you agree ?
I think both uses SEAICE_no_slip=F (default), so if there is a bug
there, should not have any impact.

Later on, we could remove all the old version code, but I think
it would be good to have both versions until we feel 100% confortable
with the new one.

Jean-Michel

PS: I switch back to mitgcm-devel, (my mistake, sorry).

On Tue, Mar 17, 2009 at 09:27:46AM +0100, Martin Losch wrote:
> Hi Jean-Michel,
>
> there are currently no metric terms in global_ocean.cs32x15, but that's 
> not ideal.
>
> Further, the finite volume discretization changes affect the non-metric 
> terms, too:
> in finite differences I did this: d^2u/dx^2 -> [(u(i+1)-u(i))/dxF(i) -  
> (u(i)-u(i-1))/dxF(i-1)]/dxC(i)
> in FV this becomes [ dyC(i)*(u(i+1)-u(i))/dxF(i) - dyC(i-1)*(u(i)- 
> u(i-1))/dxF(i-1) ]/rAw.
>
> I also had to change other things, eg. the discretization the strain  
> rates. There was also a bug in the boundary conditions of the off- 
> diagonal strain rate (no slip was not quite rigth), . I can change them 
> back, but I'd rather not.
>
> For now I can try to create something, that reproduces the old results, 
> but it will be wrong. Do we want that?
>
> Martin
>
> On Mar 16, 2009, at 5:51 PM, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> I will be back next Monday, will have a look at those
>> changes then.
>> If it cannot wait: I would prefer to have a way to reproduce
>> the old results (with some ifdef) and to turn those ifdef on
>> for global_ocean.cs32x15 (since until now, there is no metric
>> terms in this one, right ?)
>> Thanks,
>> Jean-Michel
>>
>> On Sun, Mar 15, 2009 at 01:36:19AM +0100, Martin Losch wrote:
>>> Hi there,
>>> (mainly for Dimitris and Jean-Michel, but I don't know how much this
>>> will affect the ECCO runs)
>>>
>>> after all my problems with the seaice package, I have recoded the lsr
>>> solver. I finally realized how much easier it is to discretize
>>> everything in finite volumes (after being involve with the MITgcm for
>>> how many years?). I attached the discretization FYI (and maybe for
>>> checking). I also found that I made a mistake with the metric terms  
>>> in
>>> the EVP solver.
>>>
>>> Unfortunately my new code breaks all verification experiments with
>>> seaice:  lab_sea and the like because, I changed (fixed) the  
>>> treatment
>>> of the metric terms, fixed the EVP code, etc. global_ocean.cs32x15
>>> because I switched from some finite differences somehow copied and
>>> adapted from the B-grid code to finite volumes. Even without metric
>>> terms the code is different.
>>>
>>> But now the best: I have finally added the full metric terms (also  
>>> for
>>> curvilinear grids) because it is so easy to do with finite volumes  
>>> (see
>>> the attached PDF). I hope I understood how metric terms are computed 
>>> on a
>>> curvilinear grid. So Dimitris can rerun all his cubed sphere  
>>> experiments
>>> with metric terms (not that it will matter too much in the end at  
>>> high
>>> resolution), and I am anxious to see if it works.
>>>
>>> How should I check in the fixes? The old seaice_lsr is not quite  
>>> correct
>>> (bugs in the metric terms) and the evp code needs to be fixed, it is
>>> clearly wrong in the metric terms, too. We can have new routine
>>> seaice_lsr_fv.F or so, or we can replace the old seaice_lsr.F with a 
>>> new
>>> finite volume version, thereby loosing all backward compatibility.
>>> Because the old seaice_lsr.F is not very nice and contains erros,  
>>> which I
>>> would need to fix anyway (but only concerning the metric terms), old
>>> results will be lost for spherical grids anyway (but maybe not for  
>>> cubed
>>> sphere). I will include a new flag that allows you to switch of the
>>> metric terms (mainly for testing).
>>>
>>> If I make all these changes, I would also in a second step change a  
>>> few
>>> defaults that are senseless (e.g. that now is not advected by  
>>> default is
>>> really annoying, also the flooding algorithm, no_slip is not turned  
>>> on,
>>> cliped ice velocities is turned on, etc. etc.)
>>>
>>> What do you think?
>>> Martin
>>>
>>> PS. We shouldn't worry about the ceaice-manuscripts, because there  
>>> we do
>>> not use metric terms, the conclusions will not be affected.
>>>
>>
>>
>>>
>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>