[MITgcm-devel] seaice dynamics questions

[Jean-Michel Campin]

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