[MITgcm-devel] spikes in heatflux/icegrowth/empmr

[Dimitris Menemenlis]

Martin, I have checked in the small fix for pkg/obcs/obcs_apply_uvice.F
that we discussed over the phone.  It is currently #ifdef'ed by 
OBCS_SEAICE_AVOID_CONVERGENCE but turned on by default, as the code is still 
experimental.  I think that this bit of code may correspond to very simple 
radiation open boundary conditions for sea-ice?

Michael's Weddell Sea domain eventually blows up whether he uses monthly or 
daily specification of uice and vice because these boundary conditions remain 
inconsistent with the six-hourly atmospheric forcing and with the monthly-mean 
specification of UVEL/VVEL.  The OBCS_SEAICE_AVOID_CONVERGENCE makes the code 
run stably but at expense of somewhat less accurate specification of uice/vice 
open boundary conditions, I think.

Given the above, I am holding off implementing more accurate (and more 
expensive) open boundary conditions as per 10/28 discussion, reproduced below, 
until we have gathered more practical experience with the existing implementation.

D.

-- 
Dimitris Menemenlis <menemenlis at sbcglobal.net>
5056 Oakwood Ave, La Canada, CA 91011-2450
tel/fax: 818-790-6735;   cell: 818-625-6498


> why not otherwise? and why not apply u/vice obcs before exchanges?
> M.
> On 28 Oct 2007, at 17:06, Dimitris Menemenlis wrote:
> 
>>> uice/vice: In fact obcs should really be applied within the iteration/sub-timestepping loops as you say. Your current implementation is a
>>>  hack (which might work), but esp for lsr, which is "global" solver, it
>>> should be a little problematic, right?
>>
>> For lsr, one thing that I could do is to apply obcs after every uice/vice
>> exchange within the lsr routine but this would only work if the obcs happen to
>> coincide with the edges of tiles.  Would that be OK?