[MITgcm-devel] changes in seaice with OBCS

Menemenlis, Dimitris (3248) Dimitris.Menemenlis at jpl.nasa.gov
Thu Nov 11 13:52:57 EST 2010 

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

More information about the MITgcm-devel mailing list