[MITgcm-devel] Re: [MITgcm-cvs] MITgcm/pkg/seaice CVS Commit

[Dimitris Menemenlis]

Martin, what I was trying to achieve is to make sure that there is no ice velocity connection between the edges of the domain.  I chose to set to zero the southwest boundary conditions because the sea ice model uses a southwest grid.  If the domain has open boundaries along all four edges, as we do in the Weddell Sea domain, then this condition imposes no flow along all of the outside edges because of wrap around. I think that this strategy will also work for more general open boundary cases but have not tested it.

In the current scheme ice is actually transported out and also into the domain because the velocities on the inside edges of the open-boundary grid boxes are non-zero.  In the tests that Michael and I have run on the Weddell Sea domain, the ice velocity and thickness a few grid boxes away from the edges is very similar to that in the global configuration. So even though these boundary conditions are not exact, they solve our immediate problem of ice piling up in northwest edge of Weddell Sea domain.

I don't know how to impose exact dynamic ice obcs.  I don't think that simply resetting velocity on inside edges of the open boundary grid boxes prior to calling advection diffusion will work.

Dimitris Menemenlis
cell: 818-625-6498

-----Original Message-----

From:  Martin Losch <Martin.Losch at awi.de>
Subj:  Re: [MITgcm-devel] Re: [MITgcm-cvs] MITgcm/pkg/seaice CVS Commit
Date:  Wed Oct 24, 2007 1:00 am
Size:  3K
To:  MITgcm-devel at mitgcm.org

Hi Dimitris (and Michael),

why only south and western open boundaries? Is this specific to  
Michael's Weddell Sea domain? Or do you actually impose uice=0 on all  
boundaries by that (via wrap around)? I don't quite get it. I think  
there should either be velocities imposed or some minimal trick used  
that makes ice velocities such that ice is moved out of the domain  
(and never into the domain).

Martin

BTW. I heard through the grapevine that you at JPL are used ice  
shelves. Is that true? How is that working?

On 23 Oct 2007, at 15:46, Dimitris Menemenlis wrote:

> Martin, I do nothing about ice velocities (ash on my head!) except  
> for imposing a closed boundary condition at the southern and  
> western open boundaries of the domain.  That is, ice velocities are  
> set to zero at the south-western open boundaries.  This is not  
> ideal, of course, but in tests that Michael and I have run, if you  
> are some two to three grid points away from the edge, then the  
> results are pretty similar to the global solution (except for  
> salinity and snow, which is what Michael added yesterday - he did  
> pretty good considering this is his first forray into the MITgcm  
> innards).  Michael is running a Weddell Sea configuration.  In the  
> closed boundary set up, ice accumulated in the Northeastern edges  
> of the domain and remained there year round, becoming thicker and  
> thicker every year.  With the current limited scheme, ice is  
> transported out of the domain of integration and the ice condition  
> looks very reasonable.  D.
>
> Dimitris Menemenlis
> cell: 818-625-6498
>
> -----Original Message-----
>
> From:  Martin Losch <Martin.Losch at awi.de>
> Subj:  [MITgcm-devel] Re: [MITgcm-cvs] MITgcm/pkg/seaice CVS Commit
> Date:  Tue Oct 23, 2007 1:51 am
> Size:  982 bytes
> To:  MITgcm-devel at mitgcm.org
>
> Hi Dimitris,
>
> I am thrilled. What do you do about the ice velocities? Do you
> prescribe them, do you set them to zero, do you extrapolate them?
> I am wondering what's most sensible guess:
> if you have outflow, you'd like to have the ice move out, so duice/dx
> = 0. If you have inflow, you'd probably don't want ice to enter, so
> uice=0. right?
> Martin
>
> On 23 Oct 2007, at 10:25, Dimitris Menemenlis wrote:
>
>> Update of /u/gcmpack/MITgcm/pkg/seaice
>> In directory forge:/tmp/cvs-serv12792/pkg/seaice
>>
>> Modified Files:
>> 	seaice_advdiff.F seaice_advection.F
>> Log Message:
>> added open boundary conditions capability for seaice HSNOW and HSALT
>> (code contributed by Michael Schodlok)
>>
>> _______________________________________________
>> MITgcm-cvs mailing list
>> MITgcm-cvs at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>
> _______________________________________________
> 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

--- message truncated ---