Open boundary questions #293
Comments
|
I think the OB points can legitimately live on the edge of the [physical] We've had a long standing question about why symmetric is required for OBCs Flather is meant to refer to the barotropic radiation condition, yes? I -A. Dr Alistair Adcroft (Alistair.Adcroft@noaa.gov) On Wed, May 11, 2016 at 6:50 PM, Kate Hedstrom notifications@github.com
|
|
OK, I've got something that runs (briefly) with "Flather" in CCS1. I had to I have no problem with staying in symmetric land. Whatever. Yes, Flather wrote a paper about barotropic OBCs. In MOM6, the term is used Kate On Thu, May 12, 2016 at 4:35 PM, Alistair Adcroft notifications@github.com
|
|
The blow-up is happening in the barotropic mode, in the SE corner next to the land. Things go from ugly to unstable quite suddenly. Might be time for a simpler problem than CCS1. |
|
With the inside OBCs, circle_obcs blows up after ten hours in the two southern corners. This can be fixed by using OBC_SIMPLE (u, v = 0) for the eastern and western v boundaries, also northern and southern u boundaries. |
|
Hi, Yes, Flather is a specific condition of Orlanski type radiation condition for specifically baratropic case since in the baratropic model the wave speed is sqrt(gh). I think the update was the issue in non-symmetric mode for open BC. That’s why it did;t work with that. Best,
|
|
To summarize from the latest hangout and other thoughts on open boundaries:
For the naming, I'm sure we'll have to go beyond simple Orlanski. The ROMS Kate On Wed, May 25, 2016 at 4:22 AM, Alistair Adcroft notifications@github.com
|
|
Hi Kate, Sorry , but I'm catching up here In symmetric mode, q points On Wed, May 25, 2016 at 3:30 PM, Kate Hedstrom notifications@github.com
|
|
Oops, sorry. Still getting used to my Chromebook. I was going to discuss the question of whether the OBC locations need to be Upon further thought ... I will try to get some clarification from Bob or Regarding the naming convention, I think we should stick with generic names Matt On Wed, May 25, 2016 at 11:36 PM, Matthew Harrison - NOAA Federal <
|
|
Hi I agree with the names; they should be generic. I also think they should Steve On Thu, May 26, 2016 at 1:43 PM, Matthew Harrison notifications@github.com
Dr. Stephen M. Griffies |
|
I finally had time to look through the OBC code myself. I've not discussed this response with @Hallberg-NOAA yet, who we know has the better understanding of the OBCs as they exist, but here are my comments anyway - they might need to be corrected by Bob. @kshedstrom wrote:
To be precise, the model boundary must be through q-points in the global computational domain of q, which does include the edges of the physical domain. Here's the rationale (I know you know this but this is for the wider audience): Speaking in global terms only (no decomposition) we consider the physical domain to be defined by the volume of all the h cells and the edges of those h-volumes are part of the physical domain in that they are boundaries. This then includes (as part of the physical domain) the q-points which are on the boundary of the physical domain. In global indices, h would be declared
Yes, they might be part of the boundary conditions but those points are outside of the physical domain (because they are beyond the boundary). The model expects the boundary condition code to either override the fluxes that would propagate those exterior values in, or to set those exterior values so that their inward propagation is sensible. So if the boundary condition is on the edge of the computational domain (not mandatory) we would be using a halo location for this data. In short, the data immediately outside of the boundary is expected to be set by the boundary condition.
To have patches of open-boundary we need to set the elements of the arrays The initial h values immediately outside the open boundaries are set to be equal to the first interior value at the bottom of that same subroutine. i.e. The initial normal gradient of h is set to zero by setting the value immediately outside the physical domain. The bathymetry and masks are similarly set up to be consistent with flather. Halos of For circle_obcs, a square box, the above works and yields a T-mask shown below. Note that the highlighted values in the halo region (halo width=4) have been "opened up" so the model does not treat the boundary as solid. To generalize the above bits of code I've mentioned, we need to generalize the way
These points are time-stepped but the results are ignored or overridden by the OBC calls. For example, where the zonal mass flux has just been calculated, ignoring the presence of OBC, lines 442-444 of MOM_continuity_PPM.F90 then replace the value of the mass flux with the prescribed value.
Yes. We need to design a good way to describe to the model where open boundaries will be located, possibly by just some input parameters rather than binary files. Here's a suggestion we've recently thought about: The above sketched open boundary locations can be described as a set of numbered segments which can be described to the model by a few short lists of indices. With these indices the model could figure out the maps of |
|
Can we please please please bring these comments into a form that is more On Sat, Jun 4, 2016 at 4:46 PM, Alistair Adcroft notifications@github.com
Dr. Stephen M. Griffies |
|
Thanks @adcroft, My two cents: In addition to the end points, we need to specify the orientation of the The discarded part of the domain should be flooded via ICE9, setting the h There are two options for filling in the OBC data: (A) supply gridded data Matt On Sat, Jun 4, 2016 at 4:46 PM, Alistair Adcroft notifications@github.com
|
|
Here's an example of something we've run. There are open boundaries to the [image: Inline image 1] For @adcroft, your band of highlighted T points is part of the ROMS Our final solution is going to require things that are currently part of Kate On Sun, Jun 5, 2016 at 8:28 AM, Matthew Harrison notifications@github.com
|
|
@StephenGriffies |
|
Great! An image with halo issues examined will be useful too. But great to have a Thanks, On Mon, Jun 6, 2016 at 8:27 PM, Kate Hedstrom notifications@github.com
Dr. Stephen M. Griffies |
|
Kate |
* Add GL90 parameterization in stacked shallow water This adds a new vertical viscosity parameterization as in Greatbatch and Lamb (1990), Ferreira & Marshall (2006) and Zhao & Vallis (2008), hereafter referred to as the GL90 vertical viscosity parameterization. This vertical viscosity scheme redistributes momentum in the vertical, and is the equivalent of the Gent & McWilliams (1990) parameterization, but in a TWA (thickness-weighted averaged) set of equations. The vertical viscosity coefficient nu is computed from kappa_GM via thermal wind balance, and the following relation: nu = kappa_GM * f^2 / N^2. The vertical viscosity del_z ( nu del_z u) is applied to the momentum equation with stress-free boundary conditions at the top and bottom. In the current implementation, kappa_GM is assumed either (a) constant or as (b) having an EBT structure. A third possible formulation of nu is depth-independent: nu = f^2 * alpha The latter formulation would be equivalent to a kappa_GM that varies as N^2 with depth. Currently, the GL90 parameterization is only implemented in stacked shallow water (SSW) mode, in which case we have 1/N^2 = h/g'. More specifically, this commit adds a new subroutine that computes the couping coefficient associated with GL90 via a_cpl_gl90 = nu / h = kappa_GM * f^2 / g' or a_cpl_gl90 = nu / h = f^2 * alpha / h. Further, a_cpl_gl90 is multiplied by a function (botfn), which is 0 within the GL90 bottom boundary layer, whose depth is set by Hbbl_gl90, and 1 otherwise. This modification is necessary to avlid fluxing momentum into vanished layers that ride over steep topography. Finally, a_cpl_gl90 is added to a_cpl, where the latter is the coupling coefficient associated with the remaining vertical stresses, used in the vertical viscosity solver. More information can be found in Loose et al. (https://www.essoar.org/doi/abs/10.1002/essoar.10512867.1), Appendix B. New diagnostics: * au_gl90_visc: zonal viscous coupling coefficient associated with GL90, is contained in au_visc * av_gl90_visc: meridional viscous coupling coefficient associated with GL90, is contained in av_visc * Kv_gl90_u: GL90 vertical viscosity at u-points, is contained in Kv_u * Kv_gl90_v: GL90 vertical viscosity at v-points, is contained in Kv_v * du_dt_visc_gl90: zonal acceleration due to GL90 vertical viscosity, included in du_dt_visc * dv_dt_visc_gl90: meridional acceleration due to GL90 vertical viscosity, included in dv_dt_visc * GLwork: Kinetic Energy Source from GL90 Vertical Viscosity The energetics of the GL90 parameterization (named "GLwork") are intentionally computed in MOM_vert_friction, rather than in MOM_diagnostics, where the reamining kinetic energy budget terms are computed. We have to do the computation in MOM_vert_friction to ensure sign- definiteness when GLwork is summed in the vertical. Indeed, MOM_diagnostics does not have access to the velocities and thicknesses used in the vertical solver, but rather uses a time-mean barotropic transport [uv]h to compute the energy budget diagnostics. A detailed discussion and exploration of this issue can be found in ocean-eddy-cpt#25. As a result of not computing the energetics in MOM_diagnostics, GLwork is not exactly contained in KE_visc. KE_visc represents the energetics of all vertical viscosity contributions, including the GL90 vertical viscosity. We could implement a term "KE_visc_gl90" that can be 1-to-1 compared to KE_visc; that is, KE_visc - KE_visc_gl90 would represent exactly the energetics of all viscosity contributions EXCEPT the GL90 viscosity. If we implemented KE_visc_gl90, this term would in practice be very similar as GLwork, but sign-definiteness is not ensured, see above.
We are agreed that the open boundary points lie within the computational domain, aren't we? There is evidence that this was not the plan for the "Flather" points in the past, but I can clean it out as I find it.
If the open boundaries are inside the domain, I don't know why symmetric mode would be needed.
Are we changing the Flather name?
The text was updated successfully, but these errors were encountered: