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

[Martin Losch]

Hi Dimitris,
I am not quite sure what exactly "causes havoc", but this is the way  
obcs is implemented:
1. compute/read values for open boundaries (obcs_calc, called near  
the end of do_oceanic_physics, that is, after seaice_model/thsice_main)
2. compute T/S/U/V/(W/Eta) for the entire domain
3. replace the boundary values according to the masks.

For seaice/thsice, I guess, one could do the same, that is, call  
something like seaice_obcs_apply_scalar at the end of seaice_model or  
thsice_main, which resets the boundary values of HEFF/AREA/HSNOW/TICE  
(what else do you need? or the corresponding values for thsice) to  
precomputed values.

For the dynamic part this is a bit more tricky and I guess one has to  
reset uice/vice in each iteration of the lsr solver or sub-timestep  
of the evp solver.

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

Martin

On 8 Jul 2007, at 18:14, Dimitris Menemenlis wrote:

> The difference between masks that are used for T/S variables in  
> obcs_apply_ts.F and those used by pkg/seaice can cause havoc,  
> especially if
> SEAICE_VARIABLE_FREEZING_POINT is defined.
>
> What is the MITgcm-politically correct way of letting pkg/seaice  
> know about (or have sufficient information to recreate) obc_mask?
>
> There are alternative quick and dirty fixes but eventually, if we  
> are to have proper pkg/seaice open boundaries, information about  
> the location of the open boundaries will be required.
>
> Dimitris
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel