[MITgcm-devel] masks in obcs_apply_ts.F and pkg/seaice

[Martin Losch]

Hi Dimitris,

On 9 Jul 2007, at 14:08, Dimitris Menemenlis wrote:

> Martin, thanks for getting back.
>
>> I am not quite sure what exactly "causes havoc", but this is the  
>> way obcs is implemented:
>
> What causes havoc is the following.  In obcs_apply_ts.F, the mask  
> used for T/S "obc_mask" is defined not as "maskC" as is assumed by  
> the rest of the code but it instead uses one of the C-grid velocity  
> points.  For example, for Western boundary it is "obc_mask=maskW 
> (I_obc+1,J,K,bi,bj)".  If there is an island just east of the  
> boundary, T and S at the boundary point are masked out, i.e., set  
> to zero.
>
> Because SEAICE_VARIABLE_FREEZING_POINT uses a linear approximation  
> for freezing point, which is linearized about freezing point for  
> salty water, as it should, it means that the freezing point for  
> S=0, is actually greater than 0 deg C.  So what happens for  
> boundary points, which are masked in pkg/obcs but not in pkg/seaice  
> is that ice keeps growing linearly to very large values, even if  
> this boundary happens to be in regions where ice is never supposed  
> to grow.
>
> Thanks to An Nguyen for isolating the cause of this weird obcs/ 
> seaice interaction.
>
> So a first question is whether having an obc_mask for T/S that is  
> different from the mask used by rest of code is really necessary?    
> From my reading of obcs code, using maskC in obcs_apply_ts.F would  
> work just as well, even though some of the T/S values would be  
> inactive.  This would be a first quick fix for the seaice/obcs  
> problem that An has isolated.
Using maskC is not as universal as we do care about the topographpy  
inside the domain and extrapolate it across the boundary. That cannot  
be changed.
>
> A second question is that "if" a different obc_mask for T/S is used  
> by pkg/obcs, shouldn't this information also be passed back to  
> maskC so that the rest of the code knows what is assumed wet and  
> what is dry-land by pkg/obcs?  This would also fix An's seaice/obcs  
> problem.
That's not really necessary if the boundary values are reset properly.
>
>> To do it cleanly, we need something like
>> seaice_obcs_calc
>> seaice_obcs_apply_uice
>> seaice_obcs_apply_vice
>> seaice_obcs_apply_scalar
>> and
>> thsice_obcs_calc
>> thsice_obcs_apply
>> plus routines that read the obcs (in anology to  
>> obcs_prescribe_read), or calculate them (like orlanksi?)
>
> OK.  What I could do as an initial placeholder is to put a landmask  
> for seaice everywhere where there is open boundary, then later  
> whoever needs proper seaice obcs can experiment with resetting the  
> HEFF/AREA/HSNOW/TICE/UICE/VICE values. Question is whether I need  
> to respecify the open boundary locations from scratch  in  
> data.seaice or whether it would be OK to simply obtain them from  
> pkg/obcs?
The open boundary information is all in pkg/obcs, so there where you  
should take it from. To fix your problem you just need to reset the  
thermodynamics along the open boundary ( HEFF=AREA=HSNOW=0).

M.