[MITgcm-devel] seaice dynamics questions

[Menemenlis, Dimitris (3248)]

Michael, what SEAICE_OBCS options
do you use for your 1-km integrations?

Jean-Michel, at a minimum I think that
OBCS_SEAICE_AVOID_CONVERGENCE
needs to be supported.

Thanks

Dimitris Menemenlis

On Sep 22, 2011, at 4:07 PM, Jean-Michel Campin wrote:

> Hi, 
> 
> I made some changes in seaice_lsr.F that should fix the point 2 below. 
> I've checked that it does not break completly the adjoint
> (I got roughtly the same number of recomputation warnings, and
> it's not slower to run) but it might be worth to check.
> 
> Regrding point 3 (obcs + seaice velocity): I would like to know 
> which CPP options in obcs_apply_uvice.F are currently used
> (in order to know which one to keep unchanged if I made some
> modifications):
> OBCS_SEAICE_COMPUTE_UVICE
> OBCS_SEAICE_SMOOTH_UVICE_PAR
> OBCS_SEAICE_SMOOTH_UVICE_PERP
> OBCS_SEAICE_AVOID_CONVERGENCE
> The idea is that I could try to implement some masking in
> seaice_lsr.F, and calling obcs_apply_uvice before seaice_lsr
> (or at the top of it); but I need to know what to do with what is
> currently in obcs_apply_uvice.F
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Sep 01, 2011 at 02:18:59PM -0400, Jean-Michel Campin wrote:
>> Hi,
>> 
>> I have a couple of questions and remarks regarding pkg/seaice:
>> 
>> 1) I found annoying not to be able to know where some CPP options
>> should be defined/undef, since they don't appears in any
>> *OPTIONS.h files, neither set at the top of the *.F file
>> in which they are used (might want to use this to keep some 
>> inactive pieces of code):
>> DISABLE_SEAICE_OBCS <- I guess in SEAICE_OPTIONS.h ?
>> and many more in other seaice S/R.
>> 
>> 2) LSR solver: we always do uIce first and then vIce, right ?
>> and I guess the vIce solution depend on the new uIce.
>> Now when the seaice extends over 2 faces of the CS-grid,
>> might have an issue with U/V not being continuous at the
>> face boundary. As I understand, it's not so much an issue on
>> regular CS grid (e.g., CS-510) for present day conditions 
>> but this is likely to happen on lat-lon cap grid. 
>> I guess the solution would be to have a 3 pass algorithm, 
>> like in multi-dim advection with CS topology.
>> 
>> 3) I did not find many OBCS specific code in seaice_lsr.F
>> Would it make sense to prevent the LSR solver from updating
>> the ice velocity at the OB (like we do in CG2D) ?
>> Would it be useful ? Might not be too difficult with some masking.
>> 
>> 4) I am going to add an EXCH call at the end of obcs_apply_uvice.F,
>> since it seems we need one. I am also tempted to remove
>> all the "if ( OB?u/vicefile .NE. ' ' ) then" : I think it's
>> not right and not safe to by-pass the setting of ice-velocity at
>> an open-boundary, and it's better to apply a default zero velocity
>> when no file is provided.
>> 
>> Cheers,
>> Jean-Michel