[MITgcm-devel] changes in seaice with OBCS

Martin Losch Martin.Losch at awi.de
Fri Nov 12 03:45:51 EST 2010 

Hi there,

about obcs_apply_uvice.F
the ice model computes velocities uice/vice everywhere in the domain for both LSR and EVP code, so any change in the boundary conditons will affect the solutions (a little bit).

I agree with Jean-Michel, that u/vice = 0 on the boundary by default is a sensible default (same as for u/vVel). although this default will result in piling up of ice that reaches the boundary.

I am not so much of a fan of having 24 individual flags. I think that all boundaries should be treated the same by default, and that maybe individual studies require individual treatment of the boundaries, but I haven't thought this through.

Not much help, eh?

Martin

On Nov 12, 2010, at 4:09 AM, Jean-Michel Campin wrote:

> Hi Dimitris and Martin,
> 
> Thanks for the answer.
> 
> I think I am going to remove all the:
>> IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
> in obcs_apply_seaice.F, so that it will do what the other obcs_apply
> do, i.e., set the value at the OB.
> 
> I am not sure it's going to slow down or speed up:
> If the computation follows exactly the fortran code, 
> it will save many tests on file name 
> ( (sNx x Oly +sNy x Olx ) x 2 x Number_of_iceFlds ) 
> (which are slower that test on real or integer),
> so it could speed-up this routine.
> If the compiler re-arrange the loop, then I don't know,
> and it could become slower (need to access variable in common 
> blocks to do the copy, whereas could by-pass this in the 
> present version).
> But in any case, there is not much computation in thoses obcs_apply S/R,
> just copy from array to array.
> 
> Regarding obcs_apply_uvice.F, I am not going to change things now,
> but I think it would be safer also to remove those tests on non empty 
> OB-file name:
> In the case where OB far from the seaice pack (e.g., at the equator)
> influence the ice dynamics in the arctic, then it's probably better
> to set the ice-velocity to zero at the equator (the default if no 
> file is provided). And if the influence is significant and cannot 
> be ignored, it means it's necessary to provide non-zero OB value 
> (read in from a file) for ice velocity. 
> 
> Martin, do you have an opinion on this ? (I read the exchange of emails
> from Feb. 2009, but I don't see how the domain could have an OB
> for the ocean but not for seaice, unless it's only at depth ?)
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Nov 11, 2010 at 10:52:57AM -0800, Menemenlis, Dimitris (3248) wrote:
>> JM, sorry for delay in getting back.
>> I was on way back from a meeting in Seattle yesterday.
>> 
>> The reason for existence of
>>> IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
>> etc., in obcs_apply_seaice.F and
>>>  if ( OBEuicefile .NE. ' ' ) then
>> etc., in obcs_apply_uvice.F is the following.
>> There are model configurations when the open boundary
>> is in a location that never sees sea ice
>> and yet the model uses pkg/seaice
>> because ice can form away from the boundaries.
>> Examples of such configurations are the
>> pan-Arctic set-ups that, e.g., Patrick, An, Manfredi, Gunnar,
>> and Pierre are using.  In the pan-Arctic case all the boundaries
>> are permanently in ice-free water but there can be
>> configurations where only some of the open boundaries
>> would be in open water.
>> 
>> Regarding obcs_apply_seaice.F
>> we can get rid of conditions:
>>> IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
>> etc., and it should not affect numerical results.
>> This is because all the ice tracer quantities are
>> initialized to zero in any case.  It would only mean
>> a few extra computations and subroutine calls,
>> which do nothing, but I don't think the code slow
>> down would be noticeable.
>> 
>> Regarding obcs_apply_uvice.F
>> I also think we can also get rid of
>>>  if ( OBEuicefile .NE. ' ' ) then
>> etc., but I am not 100% sure if it will have
>> numerical consequences.  This is
>> because in LSR case, ice velocity is non-zero
>> even when there is no sea ice.
>> 
>> Dimitris
>> 
>> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
>> Jet Propulsion Laboratory, California Institute of Technology
>> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099, USA
>> tel: 818-354-1656;  cell: 818-625-6498;  fax: 818-393-6720
>> 
>> On Nov 11, 2010, at 12:17 AM, Martin Losch wrote:
>> 
>>> Hi Jean-Michel,
>>> 
>>> yes, that was the point: with OBCS_SEAICE_COMPUTE_UVICE defined there should not be any files for open boundaries for ice velocities. I had suggested something about these tests some time ago <http://mitgcm.org/pipermail/mitgcm-devel/2009-February/003602.html>, but I didn't follow up on that.
>>> 
>>> Martin
>>> 
>>> On Nov 10, 2010, at 8:07 PM, Jean-Michel Campin wrote:
>>> 
>>>> Hi Martin,
>>>> 
>>>> I did not think of changing obcs_apply_uvice.F now (just obcs_apply_seaice.F).
>>>> But, naively, looks like removing the test for non empty OBN,Svicefile and
>>>> OBE,Wuicefile in obcs_apply_uvice.F would make your data.obcs more 
>>>> staighforward (no need to specify OBW,Eu,viceFile when OBCS_SEAICE_COMPUTE_UVICE
>>>> is defined).
>>>> Or am I missing something ?
>>>> 
>>>> Cheers,
>>>> Jean-Michel
>>>> 
>>>> On Wed, Nov 10, 2010 at 03:38:47PM +0100, Martin Losch wrote:
>>>>> Hi Jean-Michel,
>>>>> 
>>>>> I actually use some of this in an awkward way. What I want is that all ice that reaches the boundary, disappears. Not sure if it really works, but the ice does not pile up against the boundary, so I am happy. Here an excerpt from my data.obcs. aaomip_heff.obce contains only zeros.
>>>>>> # all zeros
>>>>>> OBEhFile='../input/aaomip_heff.obce'
>>>>>> OBWhFile='../input/aaomip_heff.obce'
>>>>>> OBEaFile='../input/aaomip_heff.obce'
>>>>>> OBWaFile='../input/aaomip_heff.obce'
>>>>>> OBEsnFile='../input/aaomip_heff.obce'
>>>>>> OBWsnFile='../input/aaomip_heff.obce'
>>>>>> # this is very counterintuitive: we need to specify
>>>>>> # an input field for the code to do anything, even
>>>>>> # though with the current CPP Flag settings
>>>>>> # (OBCS_SEAICE_COMPUTE_UVICE defined), these values
>>>>>> # have no effect whatsoever
>>>>>> OBWuiceFile='../input/aaomip_heff.obce'
>>>>>> OBWviceFile='../input/aaomip_heff.obce'
>>>>>> OBEuiceFile='../input/aaomip_heff.obce'
>>>>>> OBEviceFile='../input/aaomip_heff.obce'
>>>>> 
>>>>> I agree with you that this is not very practice, and something more straightforward would be nice (like defining or computing the values in obcs_calc.F).
>>>>> 
>>>>> Martin
>>>>> 
>>>>> On Nov 10, 2010, at 3:30 PM, Jean-Michel Campin wrote:
>>>>> 
>>>>>> Hi Dimitris,
>>>>>> 
>>>>>> Thanks for doing this. I made the checkpoint62n tag yesterday.
>>>>>> 
>>>>>> I have an other question related to obcs_apply_seaice.F:
>>>>>> I would like to remove all the conditions on non-empty 
>>>>>> file-name when applying OBC to seaice fieds:
>>>>>>>       IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
>>>>>>> &          HEFF(I,J,bi,bj)  = OBNh (I,bi,bj)
>>>>>>>       IF ( SEAICEadvArea .AND. OBNafile .NE. ' ' )
>>>>>>> &          AREA(I,J,bi,bj)  = OBNa (I,bi,bj)
>>>>>> In fact, I don't know how the seaice model will deal with OB 
>>>>>> when only part of the fields are specified in OB regions.
>>>>>> I expect some funny things when the ice-field is advected.
>>>>>> And in the case where the ice field is not advected, I really
>>>>>> don't know. I would be tempted to remove also the test
>>>>>> "IF ( SEAICEadvHeff )", and to always apply what has been 
>>>>>> set in obcs_calc, to make seaice-obcs like ptracer,T,S,
>>>>>> and momentum (all the other obcs_apply S/R).
>>>>>> 
>>>>>> But may be a more basic question, is this feature (not to 
>>>>>> apply OBC to some seaice-fields when it's done for other
>>>>>> fields) used and for what purpose ?
>>>>>> If this is really a feature we want to maintain, I am afraid
>>>>>> this might be broken after my recent changes.
>>>>>> 
>>>>>> Cheers,
>>>>>> Jean-Michel
>>>>>> 
>>>>>> On Mon, Nov 08, 2010 at 01:37:52PM -0800, Menemenlis, Dimitris (3248) wrote:
>>>>>>> JM, I will revert back to 1.50 plus your 1.52 changes.
>>>>>>> will check it in in a few minutes, after I test make sure I didn't
>>>>>>> break seaice_obcs
>>>>>>> 
>>>>>>> D.
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 8, 2010, at 1:07 PM, Jean-Michel Campin wrote:
>>>>>>> 
>>>>>>>> Hi Dimitris,
>>>>>>>> 
>>>>>>>> I made some changes in OBCS for T & S, also ptracers,
>>>>>>>> and did similar changes in pkg/seaice.
>>>>>>>> If you see something strange, let me know.
>>>>>>>> 
>>>>>>>> I was going to make a checkpoint sometime this week
>>>>>>>> (may be tomorrow), and was wondering about your changes in
>>>>>>>> seaice mask with OBCS (in seaice_init_varia): Do prefer to change 
>>>>>>>> it back ? Anyway, it would be better to fix it
>>>>>>>> before the checkpoint (62n).
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Jean-Michel
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> 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