[MITgcm-devel] obcs_seaice_sponge.F

Menemenlis, Dimitris (3248) Dimitris.Menemenlis at jpl.nasa.gov
Wed Sep 19 16:06:19 EDT 2012


Jean-Michel thanks.  I will take a look at your two check-ins.

I agree that what you propose below is safer and more elegant,
i.e., that the MITgcm (not the user) take care of converting obcs
inputs to rbcs targets. I don't have the time (or qualifications) to
take on this task right now, though, especially since I do not
understand all the problems that a generic obcs case can cause.
If someone takes a stab at writing a better obcs_sponge.F
routine, I can modify obcs_seaice_sponge.F accordingly.
Right now obcs_seaice_sponge.F only applies relaxation to tracer
fields, so it's a little less problematic than dealing with vectors.

A related question, is whether we need to keep
        DO I=1-Olx,sNx+Olx
        DO J=1-Oly,sNy+Oly
in obcs_apply_seaice.F, since "CALL OBCS_APPLY_SEAICE" in
seaice_model is immediately followed by seaice tracer field
exchanges. I have run verification/seaice_obcs with
        DO I=1,sNx
        DO J=1,sNy
and it gives bit-identical results. Can I go ahead and change
these loop limits, or is there some reason to keep as is?

Cheers

Dimitris Menemenlis

On Sep 19, 2012, at 11:07 AM, Jean-Michel Campin wrote:

> Dimitris,
> 
> I found the Pb with multi-threading, but will go with 2 check-in
> (in obcs_readparams.F), a quick one and one with more changes
> related to threads.
> 
> And otherwise, I understand your point regarding input files, 
> but in term of implementation, should be affordable, if using the
> sponge option, to have few more 2-D mask and several 3-D arrays for 
> the relaxation targets. It's just to fill theses with OBCS values
> (and then EXCH + similar relaxation as done in rbcs).
> 
> Cheers,
> Jean-Michel




More information about the MITgcm-devel mailing list