[MITgcm-support] periodic but "closed" channel flow
Patrick Rosendahl
Patrick.Rosendahl at zmaw.de
Mon Mar 10 08:44:07 EDT 2008
Martin,
I forgot to mention that I closed the N+S boundary. Yes, I am expecting
a static stationary solution.
The E+W boundaries are open, and windstresss will generate some profile
into the wind direction, causing a netflow in that direction.
This patch will act as if there was a constant pressure pushing as much
water back until the netflow over the boundary is zero (in this case 5
pixels left of the E boundary), e.g. the channel is "closed".
I dont expect this to work with time-varying solutions. In this case you
should average over 1 waveperiod, if that length can be determined at all.
Thank you for the answer, and yes, it helps. So I will apply the
correction in the momentum-correction-step routine only (also the
obcs_apply_uv is called from there in line 104).
Patrick
Martin Losch wrote:
> Patrick,
> what are you trying to do? a zonally periodic channel that still has
> open boundaries in the zonal direction? Why?
> On average, a zonal channel, unless you have a localized unbalanced
> mass sources somewhere (e.g. freshwater flux at the surface), should
> have no zonal netflow anywhere. However, if you have a time varying
> solution, there will be fluctuations in the mass flux (with zero mean).
> Removing these mass fluxes as you seem to have done will introduce
> shocks to the system at every timestep. Also I don't know if obcs is
> the best place to do that. If you have to change the entire flow field,
> I would really try to do it in the correction step
> (momentum_correction_step.F), all you need to do is include GRID.h into
> that file and then you can do what you want to do.
>
> Does that help?
>
> Martin
>
> On 5 Mar 2008, at 14:53, Patrick Rosendahl wrote:
>
>> Hello all,
>>
>> this is code I use for simulating a infinite channel (periodic domain
>> in EW-direction) with return flow (netflow in any section is 0).
>>
>> It is currently hooked up in obcs_apply_uv.F via
>>
>> CALL OBCS_MODIFY( bi, bj, uFld, vFld, myThid )
>>
>> and implemented like this in obcs_calc.F inside the IF-
>> useOBCSbalance-THEN switch
>>
>> C
>> C calculate the mass transfer across some section
>> C
>> Tr_T = 0. _d 0
>> Ar_T = 0. _d 0
>> DO K=1,Nr
>> DO J=1-Oly,sNy+Oly
>> I_obc = sNx-5
>> IF (I_obc.ne.0) THEN
>> Ar = drF(k)*hFacC(I_obc,j,k,bi,bj)*dyG(I_obc,j,bi,bj) *
>> _maskW(I_obc,J,K,bi,bj)
>> Ar_T = Ar_T + Ar
>> Tr_T = Tr_T + Ar * uVel(I_obc,J,K,bi,bj)
>> ENDIF
>> ENDDO
>> ENDDO
>> _GLOBAL_SUM_R8( Ar_T , myThid )
>> _GLOBAL_SUM_R8( Tr_T , myThid )
>> Tr_T = (0. - Tr_T)/Ar_T
>> C
>> C correct the entire u-field
>> C
>> DO K=1,Nr
>> DO J=1-Oly,sNy+Oly
>> DO I=1-Olx,sNx+Olx
>> uVel(I,J,K,bi,bj) = uVel(I,J,K,bi,bj) + Tr_T * _maskW
>> (I_obc,J,K,bi,bj)
>> ENDDO
>> ENDDO
>> ENDDO
>>
>>
>>
>>
>> I first tried the Orlanski-type BC, but it does not work very well.
>> Probably there is a proper way to hook the code.
>>
>> Patrick
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
More information about the MITgcm-support
mailing list