Jump to content
TUFLOW Forum
tmashby

Ensuring water flows in the correct direction

Recommended Posts

I am using a QT boundary to model the volumes of water over the parapet of a sea wall due to wave overtopping.

For previous simulations it had not been necessary to allow water to flow back into the sea from this model and hence I had used a high z line to ensure that water flowed in the correct direction.

I now require the model to allow some water to flow back across the boundary, so will remove this z line, but I need to make sure that the initial inflow of water to the model will be in the landward direction.

From the manual it seems as if I should be able to do this using the QT boundary, either as it is in the latest build or using the A flag and specifying an angle, but I am unclear as to how to go about this.

Any help would be appreciated.

Share this post


Link to post
Share on other sites

Interesting one. To allow water to flow in either direction a HT boundary (representing the ocean tide levels) needs to be used (this would be the more conventional approach). Any inflows due to wave overtopping of the sea wall would be better modelled as a ST (Source of water over Time) boundary directly onto the 2D cells receiving the wave overtopping (presumably these cells would be just inside the sea wall Z Line). Note that ST inflows are m3/s per cell - see Table 4.21 in the manual. ST boundaries are usually digitised as points and/or polylines (view the 2d_bcc_check.mif layer to see the 2D cells selected).

2D QT boundaries should always be digitised so that they snap to and share a common section of the Code polygon perimeter. This ensures that to one side of the QT boundary there are active 2D cells, and to the other side inactive cells. The flow direction is dictated by the which side the active cells are on, ie. a positive inflow will flow into the model. Note, 2D QT boundaries are designed to be always a positive inflow into the model as in a river inflow hydrograph (a negative flow may work but I'm not aware of this being tried or tested!).

Share this post


Link to post
Share on other sites

Note, 2D QT boundaries are designed to be always a positive inflow into the model as in a river inflow hydrograph (a negative flow may work but I'm not aware of this being tried or tested!).

I have used a time-varying flow boundary in a 2D model that had both positive and negative components; it was an upstream river boundary that was tidally influenced and thus flowed in both directions. I used field data to drive the boundary. A negative flowrate does seem to work to designate water leaving the grid.

Share this post


Link to post
Share on other sites

Further to Bill's comment about QT boundaries snapping to the code polygon, is there a default direction if the QT boundary is digitised as a point? ie Will it always be applied as a flow across ZU no matter where in the cell the point is digitised? Do you need to invoke the A flag and digitise a line if you want it applied in any other direction?

Share this post


Link to post
Share on other sites

2D QT boundary cells will flow across any or all of its cell sides depending on which cell sides are active. A cell side is active if does not adjoin an inactive cell and it does not adjoin another 2D QT cell. The cell side also needs to be wet (ie. the water level on at least one side is above the ZU/ZV elevation). The same approach applies for HX, HS and HT cells.

I've never tried a 2D QT boundary as a point but it may work! Let us know how it goes! If you want the flow to be across a particular cell side, and the surrounding cells are active, you could try raising the elevations of the other three cell sides so that the flow can only be in one direction.

It's not recommended to use the A flag option for 2D QT boundaries as this has limitations relating to stability, wetting and drying and other issues.

Share this post


Link to post
Share on other sites

Bill,

Thanks for your reply.

I am in fact using 60 QT points in cells that are active and along the code boundary. Adjacent the first and last cells are land (or inactive) cells. So in theory, the flow will cross only the one boundary, that into the model. The reason for this is to replicate a MIKE 21 model which applies a varying QT boundary (which I suspect was created from the output of a much larger model). Certainly a PO line along the active side of these cells produces a cumulative flow hydrograph equivalent to that shown in the MIKE 21 report.

Greg suggested to me yesterday to switch to 60 ST point boundaries (as I am having trouble replicating MIKE21 levels in this region) but I have not had a chance to check this makes a difference.

Tina@dks

Share this post


Link to post
Share on other sites

Yes, the ST inputs would probably be better in this case, although the best thing to do is to digitise the QT boundary perpendicular to the flow as TUFLOW does not have to have the boundary specified parallel to the grid. You will probably get differences in the vicinity of the boundaries due to the different approaches used by TUFLOW and MIKE21. You could try the QTA boundary in TUFLOW (I imagine that this would be similar to that in MIKE21), but these boundaries are usually poor performers compared with the QT (no A) boundary hence why they're not used anymore. You'll also have to specify the direction of flow using the a attribute.

Let us know how it goes!

Share this post


Link to post
Share on other sites

Bill,

I attempted to use the QTA boundary on my 60 GIS points with the a flag set to 30.03 (approx. 30 degrees). The run stops at processing of the first boundary with the following error:

ERROR 2041 - Too many QTA tables.

I have tried only one of the points as a QTA with the rest reverted back to QT. Again same error.

I have tried reducing the number of points in the timeseries for the one QTA point. Again the same error.

To what is the error referring?

Thanks

Tina

Share this post


Link to post
Share on other sites

Hi Guys

Error 2041 shouldn't actually occur, so there must be a bug when allocating memory for QTA boundaries. As mentioned in my previous posts QTA boundaries are not recommended to be used. You would be much better off using ST, SA or possibly QT boundaries.

Cheers

Bill

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...