[MITgcm-devel] seaice dynamics questions

[Martin Losch]

Hi Jean-Michel,

currently I use this
#define OBCS_SEAICE_COMPUTE_UVICE
and hack the corresponging code, so any change is "welcome" (I'll brace for it).

M.


On Sep 23, 2011, at 1:17 AM, Jean-Michel Campin wrote:

> Hi Michael & Dimitris,
> 
> Thanks for the information. This helps.
> Don't know yet how/when I will try something,
> but I will keep these options unchanged.
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Sep 22, 2011 at 03:48:03PM -0700, Michael Schodlok wrote:
>> 
>> those are my OBCS seaice options
>> 
>> I apparently did not turn the avoid convergence on for the 1 km grid
>> but it still works and I did not have any issues with it.
>> As discussed a while ago for this resolution something like
>> avoid_divergence,
>> or rbcs would be good.
>> 
>> #undef OBCS_SEAICE_AVOID_CONVERGENCE
>> #undef OBCS_SEAICE_SMOOTH_UVICE_PERP
>> #undef OBCS_SEAICE_SMOOTH_UVICE_PAR
>> #undef OBCS_SEAICE_SMOOTH_EDGE
>> #define OBCS_SEAICE_COMPUTE_UVICE
>> 
>> Michael
>> 
>> 
>>> 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
>>> 
>>> 
>> 
>> 
>> -- 
>> --
>> --
>> 
>> *************************************************
>> 
>> Michael Schodlok <schodlok at jpl.nasa.gov>
>> Jet Propulsion Lab/
>> California Institute of Technology
>> MS 300-323
>> 4800 Oak Grove Dr
>> Pasadena CA 91109-8099 USA
>> Tel: +1-818-354-4015  Fax: +1-818-393-6720
>> 
>> *************************************************
>> 
>> 
>> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel