[MITgcm-devel] changes in seaice with OBCS

Menemenlis, Dimitris (3248) Dimitris.Menemenlis at jpl.nasa.gov
Fri Nov 12 04:03:05 EST 2010 

JM, I agree that we should remove all the "*file .NE. ' ' "
and Martin I agree that there should be no additional flags.

For obcs_apply_seaice.F it will make
no difference numerically and a marginal
difference (wether speed up or slow down)
computationally.

For obcs_apply_uvice.F, as Martin
confirms, there will be a slight effect on the
solutions, but it should be in the numerical
solver precision level.

Dimitris

On Nov 12, 2010, at 12:45 AM, Martin Losch wrote:

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

More information about the MITgcm-devel mailing list