[Mitgcm-support] Re: OBC ?

[mitgcm-support at dev.mitgcm.org]

Jean-Michel Campin wrote:
> I had a quick look to OBC changes between c33 and c35 :
> -> some "apply_OBC" have been deleted
>      in c33 : T,S + gTnm1,dSnm1
> but  in c35 : only gTnm1,dSnm1

Don't understand what you're saying. There was a CALL APPLY_OBCS1
after CORRECTION_STEP at k=1, another for k+1 if k<Nr at k=1
and a third at k+1 for k=2:Nr if k<Nr. All this counts as
one call to APPLY_OBCS1. There was one call to APPLY_OBCS3
in the k=Nr:1 loop acting on rVel and rTrans and one call
to APPLY_OBCS2 after TIMESTEP in the same loop.

Summary is:
APPLY_OBCS1 sets uVel,vVel,theta and salt
APPLY_OBCS3 sets W and only did anything in N-H mode
APPLY_OBCS2 sets gUnm1 and gVnm1

In the new dynamcics.F we now have OBCS_APPLY_W(wVel) immediately after
INTEGRATE_FOR_W if in N-H mode, OBCS_APPLY_TS(gTnm1,gSnm1) after TIMESTEP_TRACER
another after IMPLDIFF which I agree is wasteful
(see later) and OBCS_APPLY_UV(gUnm1,gVnm1) after TIMESTEP.
*Then* after CORRECTION_STEP we have a OBCS_APPLY_UV(uVel,vVel).

So forgetting implicit diffusion the summary is:
set  wVel       with OBCS_APPLY_W
set gTnm1,gSnm1 with OBCS_APPLY_TS (which become theta,salt next timestep)
set gUnm1,gVnm1 with OBCS_APPLY_UV (ready for div.Ghat)
set  uVel, vVel with OBCS_APPLY_UV (after CORRECTION_STEP)

Seems correct to me. It also produces the right numbers.
The difference is that previously we adjusted the state within dynamics
where as now we assume it is consistent on entry to dynamics.
The new dynamics only calculates the G's and doesn't alter the state variables
which I think is cleaner.

> -> 2 values were reset for u or v , e.g.: u(I) and u(I-1) at W_obc
> but only 1 in c35 obc_apply_UV.

This was something I tried when debugging the N-H OBCS in c27
but I "fairly" sure that what's in OBCS_APPLY_UV should be sufficient.

> on the other hand, 1 call to obc_apply_TS after "implidif"
> shoud be enough (instead of one before + one after).

We should put an IF (.NOT. IMPLDIFF) around the first one.
The reason we put the first one there was to put the call
inside the same K loop.

> Could we try to see if c35 with larger "obc_apply" can
> give better results with Samar experiment ?
> (I have the impression that exp4 is not strick enought to
> validate OBC in all cases ?)

You may try but I ran the the hydrostatic exp4 with Samars code
and it works fine. To my amazement it gave the right answer!
Is Samar having difficulty with Hydrostatic cases too or
is it the Non-hydrostatic case?

> I have also noticed that the computation domain of W
> was not strictly compatible with other part of dynamics.F
> => fixed with the recent changes.

?

> rVel (in calc_commomn_fact & dynamics) can be deleted,
> but this could be done after checkpoint_35

Do it now before we forget.

> the position of the "do_I/O" in forward_step.F is not very "logical",
> and can be changed in the future (this point can be added at the end
> of the list_of_change).

Indeed we should sort out the whole of forward_step.F
The final half step is no longer necessary since we've un-done the
time-step unrolling.

A.