[MITgcm-devel] changes in OBCs pkg

[Martin Losch]

OK, I didn't think of the exchanges.
In obcs_init_variables.F Patrick and I put a block with exchanges at 
the end for exactly the same reason. It's not there for passive tracers 
now (my job), but in fact it should be at the end of the 
obcs_prescribe_read routine, except that there isn't a 2D-exchange for 
vertical slabs, is there? I don't have a good suggestion for this 
except that there should be exchanges for these fields.
Martin

On Dec 7, 2005, at 4:05 PM, Jean-Michel Campin wrote:

> Hi Martin,
>
> Sorry, I did not take the time to write all the things down:
>
> 1) Yes, when you switched from exp4/code/obcs_calc.F to
> useOBCSprescribe=.TRUE., the results did not change in
> the interior.
> However, if I compare MOM dynstat_wvel_max in output.txt,
> now I have (e.g., iter=10):
> (PID.TID 0000.0001) %MON dynstat_wvel_max             =   
> 2.2495491745397E-01
> and before (same iteration):
> (PID.TID 0000.0001) %MON dynstat_wvel_max             =   
> 2.1847855594095E-02
>
> 2) It took me some time to figure out why we get those
> large vertical velocity just in 2 grid points (in fact
> 2 columns of grid points), in (40,1) & (40,42):
> It's because of OBCS_APPLY_UV call after CORRECTION_STEP
> (all of this in momentum_correction_step.F) that set u
> at N & S OBs, from 1-Olx:sNx+Olx:
> with old obcs_calc.F, OBSu is set to .25 over the full
> range but with useOBCSprescribe, only from 1:sNx.
> The consequence is that uVel(41,1) (tile.1) is reset to
> zero whereas uVel(40,1) (tile.1) is 0.25, resulting in
> a large divergence; and since wVel is computed just
> after (in INTEGR_CONTINUITY) (and also etaN if using exactConserv),
> we get large wVel (and large etaN) at those 2 points.
>
> Note that, strictly speaking, it's not related to an initialisation
> Pb, because uVel(40,1) & uVel(41,1) are reset to OBSu several
> times per iteration.
>
> 3) what I proposes:
>
>> I do acknowledge that there are always problems with
>> vertical velocities near the boundaires. What do you think?
>
> Well, this is the reason why I would like to reset etaN & wVel
> to zero in the OB regions, so that
> a) when you plot wVel, you don't see those very weird values
>  in the OB regions
> b) same thing, but worst with etaN & exactConserv, because it
>  accumulates (increase by 150.m /iteration).
> c) since it is quiet easy to get something wrong with OBCs, it's
>  better not to leave weird wVel & etaN values in the OB regions,
>  that would let someone think that something is wrong.
>
> The point is that this problem exists (and was there with
> exp4/code/obcs_calc.F) but it just get worst with
> useOBCSprescribe, as I explain above.
>
> Hope it's more clear now.
>
> Cheers,
>
> Jean-Michel
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel