[MITgcm-devel] seaice revisited

[Martin Losch]

Hi Jean-Michel,

I agree with you about the CS510. This is what I propose to do now:
1. create a tag checkpoint61k
2. check-in all the changes prior to my FV-discretization: these will  
affect all seaice experiments for different reasons, except for the  
global_ocean.cs32x15/icedyn (because that does not use metric terms,  
nor does it use no_slip, however, the CS510 standard runs of Dimitris  
do use no_slip, I believe). update the relevant verification experiments
3. create a second tag checkpoint61l
4. include the FV discretization, and update the verification  
experiments, so that global_ocean.cs32x15 will still use the old  
discretization (which was correct for the non-metric terms and free  
slip).
3. create a third tag checkpoint61m?

OK?

Martin

On Mar 17, 2009, at 12:31 PM, Jean-Michel Campin wrote:

> 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
>>>
>>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel