Modifying Periodic Boundary Conditions

Facts, news, and guidance about ROMS software

Moderators: arango, robertson

Post Reply
Message
Author
rwdell
Posts: 4
Joined: Tue Mar 24, 2009 3:25 pm
Location: MIT/WHOI Joint Program

Modifying Periodic Boundary Conditions

#1 Unread post by rwdell »

Hi ROMS Friends,

I am studying an idealized bottom boundary layer problem over a sloping bottom, so I am trying to set up a domain that, as closely as possible, mimics an infinite slope. I would like to be able to use periodic boundary conditions, but conventional periodic boundary conditions do not permit a net change in topography across the domain. My big question is: Do you think it is possible to adapt periodic boundary conditions for a sloping bottom? What follows is a description my idea of how I might do this, with a bunch of more specific questions embedded in it. If people wanted to help with all those more specific questions, that would be great, but even if you don't have time for that I would really appreciate feedback on the big picture question.

My idea is this: first, instead of having a net bottom slope, rotate my domain so that the (x,y) coordinates are along- and across-slope, and the z coordinate is slope-normal instead of vertical. This would require reducing the strength of g, the acceleration due to gravity, by a factor of cos(a), where (a) is the bottom slope. I would do this by adjusting the value of g in:

ROMS/Modules/mod_scalars.F

(Is this the only place g is defined, or do I have to alter other code, too? Could I make g a function of a user-defined parameter from ocean.in?) Then I would have to add a body force of g*sin(a) in the x-direction by defining the BODYFORCE option in include ocean.h file, specifying in the input file ocean.in that the bodyforce should be applied for the entire water column, then defining the body force in:

ROMS/Nonlinear/rhs3d.F

(Do I also have to specify the surface or bottom stress that corresponds to this body force, or can I just define a constant body force to apply everywhere?) The result of these changes would be that isopycnals in my domain would have a resting slope of (-a) instead of zero. Then, I would apply periodic boundary conditions. However, in the up-slope direction, I could not use conventional periodic boundary conditions because the density profile at one side of the domain will not match that at the other side (due to the slope in isopycnals). So I would like to implement boundary conditions that are periodic for velocity but not for tracers (salt and temperature). Unfortunately, I can't find where the periodic boundary conditions are defined in ROMS. I thought all the relevant boundary condition code was in

ROMS/Nonlinear/u3dbc_im.F or u2dbc_im.F,

but I couldn't find anywhere that it said anything like:

Code: Select all

DO k=1,N(ng)
   DO i=IstrU,Iend
      u(i,Jend+1,k,nout) = u(i, Jstr-1, k, nout)
   END DO
END DO
Where are the periodic boundary conditions for both velocity and tracers actually implemented in ROMS?

For the tracer boundary condition, there are two possibilities that I think might work in my application. The easier possibility would be to use TCLAMPED at one side of the domain and a TRADIATION condition at the other, and allowing the isopycnals to adjust between. The more difficult possibility would be to have a periodic boundary condition with the tracer field, but somehow subtract a fixed temperature or salinity from the profile between when a fluid parcel exits on the upslope side and when it reenters on the downslope side. That fixed T or S would correspond to the change in T or S from the background stratification over the change in height from the bottom to the top of the slope.

As I said, any feedback on this plan would be greatly appreciated. I know that this post has a lot of questions in it. If you know any of the answers but can't be bothered to write them all down, send me an email (rwdell@mit.edu), and maybe we can find a time to talk over the phone. Thanks so much in advance.

Cheers,
Rebecca
rwdell@mit.edu

User avatar
arango
Site Admin
Posts: 1367
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Modifying Periodic Boundary Conditions

#2 Unread post by arango »

Well, it seems that you are planing a lot of radical changes. This requires a careful knowledge of ROMS structure. You basically need to look for two variables dealing with gravity: g and gorho0. These are scalars. If you want an array instead, you need to do a lot of changes in the pressure gradient routines and algorithms that use gorho=g/rho0. I don't know what do you mean defining gravity as a function of other parameters. If the resulting expression is still a scalar, you just need to do that in mod_scalars.F and inp_par.F where gorho0 is assigned. We need to read rho0 from ocean.in before gorho0 can be computed. If you intent and array, you can create an analytical expression to include in analytical.F.

Now, the periodic boundary conditions are more complicated and I don't know if it is possible. I have to think more about it. The periodic boundary conditions are applied inside ROMS kernel by calling several routines in exchange_2d.F and exchange_3d.F. If you browse the code for these, they are applied after a call to the regular boundary conditions routines and before the MPI communication exchanges. By the way, I don't know if this will work with MPI because of the special manipulations with the i,j indices that you plan to change. This is extremely complicated. The periodic boundary conditions are only applied to the state variables. All the private variables used for the horizontal differentiation operators do not need periodic boundary conditions, because the i,j indices are treated specially to avoid calling periodic boundary conditions routines. You are planning to change all that logic. Hmm, I don't know if it will work. I will have to check the code very carefully.

The other problem is that the parallel tiling in ROMS is in the horizontal direction and not the vertical. This requires radical changes. I wonder if there are better ways to formulate your problem without a need to such radical changes.

Post Reply