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

[Dimitris Menemenlis]

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.

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.

> 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?

D.