Alongshore currents with periodic alongshore boundaries

[aryansafaie]

Dear ROMS community,

I've been searching for good way to do this for a while now, and the answer has thus far evaded me.
I'm trying to implement an alongshore current, with periodic alongshore boundaries. The goal is to
have the flow fully developed over the alongshore direction (my domain can be as wide as needed).
The strategy I've been using thus far is to apply a surface momentum flux (via. ana_smflux.h) as a
bodyforce (#define BODYFORCE) to all vertical levels (LEVSFRC = 1). However, in this strategy results
in seemingly erroneously faster velocities in the shallower nearshore part of the domain. So I'm
wondering if there is a better way of going about this, while still maintaining periodic alongshore boundaries?

Any guidance would be greatly appreciated.

Thanks,
-aryan

[kate]

To answer here or there? You don't need to ask things twice on the ROMS forum.

With a rigid-lid model, you can impose the longshore transport via the streamfunction boundary conditions. We no longer have a rigid-lid model, though. If you have too much flow over your shallow areas, perhaps you can make your surface stress be a function of depth. Fuss with it until you are happy with it. I don't know what else to suggest, if you insist that it be periodic.

[aryansafaie]

Hi Kate,

Thanks for the quick reply.
Indeed, my next tactic is to make the surface stress a function of depth.
I'll report back on an successes/insight.

Cheers,

[shchepet]

....The goal is to have the flow fully developed over the alongshore direction....

You want periodicity and simultaneously want to maintain your alongshore velocity be close to a desired value. This is over-specification. You do need periodic boundaries to do that. Instead you need to specify you desired velocity and density fields at the inflow side -- your flow along the coast is going one way or the the other. So one side is always going to be inflow.

You need so-called Flather conditions for the barotropic mode, and in addition to that, you need to specify external values for free surface and barotropic velocity which are geostrophically balanced. In the case of 3D proplem you need to specify density field, free-surface field, and 3D velocity component perpendicular to the boundary which are in geostrophic balance with each other. Then barotropic velocity component perpendicular top the boundary is computed as vertical integral of 3D velocity.

[aryansafaie]

Thank you for the reply, Alexander.

That makes sense, except where within ROMS am I supposed to supply my inflow density field?

Cheers,
-aryan

[shchepet]

Is this an idealized problem?

If yes, you have to make a your own routine which creates these field analytically.

As an example (actually a fairly old one) you may use

http://people.atmos.ucla.edu/alex/ROMS/ ... eNotes.pdf

The technique is essentially the same as using side boundary forcing in realistic
configurations, except that now external data comes from an analytical routine
rather than supplied from files created by interpolating from an external model.

Periodic conditions (periodic channel configuration like in the case of UPWELLING
example) are suitable when everything what is going on in your solution is generated
locally by wind. In the case of UPWELLING it is basically quasi-2D setup in y-z plane
(everything is uniform in x-direction which is also the direction of periodicity).
A bit more nontrivial case is JET channel configuration. It is used for studying
instability of zonal jet. Again, everything in generated by internally in the model.

In contrast, if you want to simulate a chunk of coast where there is a coastal jet
generated in a model solution over a much larger domain, you cannot simply cut out
a small piece of it, close it periodically, blow wind, and expect appearance of a
realistic solution, say you cannot take a piece along Forida - Georgia coast,
1000 km long, 200 km wide, close in north-south periodically, blow realistic wind,
and expect something which looks like a part of Gulf Stream.

[wilkin]

I described a way to do this in an old forum post viewtopic.php?f=1&t=2412

If you #define ATM_PRESS and introduce a linearly varying along-channel air pressure gradient (using ana_pair.h for example), then the pressure gradient calculation will convert this grad(p) into an along-channel uniform barotropic force on the RHS of the along-channel momentum equation.

It won't prescribe the magnitude of the current, because that will depend on the balance of forces that evolve as the current accelerates and eventually reaches steady state once friction balances the force.

The only trick to doing this is you have to ensure the periodicity constraint is not applied to Pair. Disable the code at the end of ana_pair.h that reads:

Code: Select all

      IF (EWperiodic(ng).or.NSperiodic(ng)) THEN
       CALL exchange_r2d_tile (ng, tile,                               &
     &                          LBi, UBi, LBj, UBj,                    &
     &                          Pair)
      END IF

[jpringle]

Aryan --

I just want to amplify a point that Sasha made above, for it is important to understanding the dynamics of your case. An alongshore current in a periodic domain must be maintained by forcing; anything else is inconsistent.

Why? what is an alongshore periodic domain? one in which there are no net alongshore gradients from minus to plus infinity in the alongshore direction. So imagine such an ocean, starting with an alongshore flow. If there is any dissipation (bottom friction, form drag, etc), the flow will decelerate. Since even vaguely realistic coastal flows have some dissipation of momentum, if you don't force it the entire solution will come to a halt in time. Any net alongshore flow must be the result of a balance between alongshore momentum forcing and alongshore dissipation (the rotation term drops out if you average over depth along an isobath, and note that there can be no net cross-shelf transport across an isobath over the entire periodic domain in steady-ish state). The forcing of the flow MUST exist -- not as a numerical hack but as a fundamental part of the flow.

If, instead, you have a non-periodic model forced by an inflow/outflow at the upwave boundary (upwave with respect to long coastal trapped waves), you are assuming the forcing for the flow exists outside the model domain -- there is a large literature on remotely forced coastal flows starting with Csanady's arrested topographic wave paper (actually, Pedlosky a few years before).

So don't think of getting the flow in your domain right as just some numerical hack. Ask yourself what physical problem you want your ocean model to represent? Remote forcing (e.g. boundary inflow/outflow), or alongshore uniform forcing (periodic domain)? Or something else (in which case you need to think about how to model that something else).

Don't be afraid of open boundaries; the other option is alongshore periodic, which is really an assumption of an ocean that repeats infinitely alongshore, which is rarely a good model of anything -- for an analysis of this in a real ocean, see Pringle & Dever 200?.

Jamie

[rduran]

However, in this strategy results
in seemingly erroneously faster velocities in the shallower nearshore part of the domain.

Another problem to keep in mind when using periodic alongshore boundaries, is that next to the coast, whatever signal is generated will propagate right back to where it is being generated, creating a feedback.

Here is an example:
https://journals.ametsoc.org/doi/full/1 ... -12-0116.1

[aryansafaie]

Hi All,

Thank you very much for your insights.

In response to John, Sasha, and Jamie:
Essentially we are envisioning a 2D problem with negligible alongshore gradients, so we want any alongshore flows to be fully developed as they enter/exit the domain. We are also trying to keep our model as simple as possible. The purpose of including alongshore flow is ultimately to see how turbulence generated from bottom stress modulates our cross-shore exchange flow, and explore different regimes of the uf/u* (convection velocity/friction velocity) ratio.

Ultimately what I ended up doing is, in ana_smflux.h :

Code: Select all

sustr(i,j)=(-2.0e-5)*((abs(GRID(ng)%h(i,j))+GRID(ng)%z_w(i,j,N(ng)))/(abs(GRID(ng)%h(IendT,JendT))+GRID(ng)%z_w(IendT,JendT,N(ng))))

Where 2e-5 m2/s2 is some field-motivated background u*^2 value, and the messy factor after that is the ratio of [h(i,j) + zeta(i,j)]/H_total. We then are using the BODYFORCE cpp w/ LEVSFRC = 1.

While this may not seem realistic at all with periodic alongshore boundary conditions, I'm hoping this achieves the desired effect of introducing different uf/u* regimes as we change the magnitude of sustr.

Thanks again everyone!