[MITgcm-support] Drift in free surface

Jody Klymak jklymak at uvic.ca
Tue Jan 19 13:08:30 EST 2021

Hi Pascal,

Its a little hard to say what the issue could be. 

First, I’m a little confused by your use of “upstream” and “downstream”.  Where is your river, east or west?  Where your river is would normally be called “upstream”, and where it goes is “downstream”.  

For your flow, I would definitely not use raw obcs or Orlanski.  I would use a sponge layer, either in obcs or rbcs.  Orlanski is really not as magical as people think, and will definitely not absorb your net inflow and turn it into a net outflow.  It only works on baroclinic motions.  Thus its not surprising that eta rises with time.  

But exactly how you set it up depends on the physics you are trying to look at.  If you want to specify the upstream (*river* side), you could try to not at all specify the downstream, but make a really large downstream basin to absorb whatever you throw at it.  If the “river” flow is small enough \eta will indeed increase, but it probably wont’ matter.   

I hope that helps. 

Cheers,   Jody

> On 19 Jan 2021, at 09:42, Pascal Bourgault <pascal.bourgault at gmail.com> wrote:
> Hi MITgcmers,
> My question is vague and might not even be related to the MITgcm itself, but I am kinda lost right now, not knowing where to look.
> My setup is the following : 
> 2D (X-Z) plane, so only one Y coordinate, with a "thinWall" on all YG=-dY points.
> ~9k points in X (with differing Δx on the sides, 15 m on most of the domain)
> 70 x 1m in Z. The bathymetry is one of an estuary so ~15 m deep in the west to 70 m in the east, with some bumps, but smoothed so dH/dx is always very small.
> I used the "old" formulation for the curvilinear grid as so to pass a Δy that varies along x, in order to represent varying estuary/river channel width, but staying in 2D. For this I was helped by this very forum a few weeks ago (thanks Martin!).
> Non-hydrostatic, Δt = 1 s,   f=β=0
> Implicit free surface
> OBCS used for prescribing T and S on both sides, U in the east (downstream), and Orlanski used for U and W upstream (west). This means I haven't specify anything for W in the east, AFAIU it is set to 0 by OBCS at the boundary.
> The downstream forcing of U includes:
>  a tide (large amplitude, period of 12.4h, quasi-constant above and going to zero at the bottom)
>  PLUS a constant flow (small amplitude, concentrated in the first 15 m)
> The forcing is meant to represent both tides and river outflow, all forced on the same boundary, letting Orlanski deal with the residuals upstream (my domain is too small to encompass all the estuary, so there should be some (smaller) tides upstream).
> Problem: The tide-averaged flow is not conserved. Pseudo code:
> taF = (UVEL.weighted(hFacW) * dyG).sum('Z').mean(time over each tide period)  # is the tidally-averaged flow (m³/s) for each column
> I would then expect d taF / dx to be zero, but it isn't.  After many tidal periods, I still have a larger "tidally-averaged inflow" upstream than downstream.  And when looking a the free surface I see that ETAN is drifting, again averaged over the tidal period.  dη / dt = C > 0, where C looks constant after the first few tidal periods.
> So after this long context (thanks for reading all!), my questions:
> Has anyone here ever used the MITgcm in this 2D X-Z kind of configuration, am I missing some crucial parts that could explain the drift?
> Is this a problem that could originate from the use of a linearized free surface? I am not able to activate the non-linear version of the algorithm because of my need to use Orlanski's conditions. But I could into this deeper, if it was clear that non-linear surface could solve the problem.
> Thanks a lot!
> --
> Pascal Bourgault
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

Jody Klymak    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210119/8cc7a3dc/attachment.html>

More information about the MITgcm-support mailing list