[MITgcm-devel] seaice dynamics questions

Martin Losch Martin.Losch at awi.de
Mon Oct 10 03:56:59 EDT 2011 

Hi Jean-Michel,

I agree with your guess. that's what I have suggested some time ago, it would save a few STOREs, I suppose, but it does not seem to be super important.

Martin

On Oct 7, 2011, at 10:29 PM, Jean-Michel Campin wrote:

> Hi Martin,
> 
> I will probably remove the 2 B-grid features I listed, 
> and probably not move seaice+obcs into pkg/seaice.
> 
> And to clarify the mask issue: I would like to try to use seaice dynamics
> in the atmosphere with slab ocean (or couple), and for this purpose,
> I need to replace all maskC,maskW,maskS and later also uVel,vVel.
> We already have a perfect candidate for maskC, i.e., HEFFM,
> and would like to use seaiceMaskU & seaiceMaskV in place of
> maskW,maskS (assuming I ignore OBCS for now). 
> I am also guessing that if seaiceMaskU & seaiceMaskV
> were set in seaice_init_fixed.F, and if the part of the code
> you don't like: "IF SEAICE_maskRHS THEN" was put within 
> #ifndef ALLOW_AUTODIFF_TAMC, those seaiceMaskU & seaiceMaskV
> should not make too much trouble for the adjoint.
> It's just a guess.
> 
> Cheers,
> Jean-Michel
> 
> On Fri, Oct 07, 2011 at 06:35:03PM +0200, Martin Losch wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> 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