[MITgcm-devel] seaice dynamics questions

Martin Losch Martin.Losch at awi.de
Fri Oct 7 12:35:03 EDT 2011 

Hi Jean-Michel,
just some comments below.
M.
On Oct 7, 2011, at 6:16 PM, Jean-Michel Campin wrote:

> Hi,
> 
> two things:
> 
> The first thing was to start to remove some B-grid pieces of code,
> in 2 cases: a) B-grid with useCubedSphereExchange ;
>        and b) B-grid with OBCS ;
> (I would add a stop if falling into these cases).
Good.
> and may be to move those 2 masks (seaiceMaskU & seaiceMaskV)
> out of the #ifdef SEAICE_CGRID (so that they are always available,
> even if not used).
I am no longer happy about seaiceMaskU/V, they are only there fore testing. In real runs, they should always be one. Currently all they do is make the adjoint more complicated. 
> 
> The other thing is as I was looking at this seaice+obcs code, I had the
> impression that it would make things easier if it was in pkg/seaice
> rather than in pkg/obcs, with a couple of changes:
> a) seaice+obcs options in SEAICE_OPTIONS.h ;
> b) move & rename pkg/obcs/OBCS_SEAICE.h to pkg/seaice/SEAICE_OBCS.h ;
> c) move & rename the 2 seaice S/R in pkg/obcs to pkg/seaice ;
> d) could also think of moving OB?[ice-var]File spec from OBCS_PARM01
> in data.obcs to a new namelist in data.seaice, but could also
> wait until obcs_exf_load.F is splitted (which I would not do right now).
> My main concern is that if for some reasons (sequence of calls/
> algorithm/time-stepping, or the need to make pkg/seaice more flexible, 
> e.g., to be used in atmospheric + slab-ocean set-up) we need to have a
> specific seaice_obcs_calc.F, it would be nicer to get this done
> within seaice pkg.
> I am not sure that every one want to go for this move,
> it's why I am asking.
I am not sure if this is really a priority. I do not see the advantage of moving the obcs-stuff into seaice, because then you have to deal with two packages when you want to include seaice ice (or change something in the obcs code. 

Martin

> 
> Cheers,
> Jean-Michel
> 
> On Mon, Sep 26, 2011 at 10:39:30AM +0200, Martin Losch wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> 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

More information about the MITgcm-devel mailing list