Jump to content

Peak water level mapped within 100% blocked layer of 2d_lfcsh polygon

Recommended Posts

I am using a 2d_lfcsh polygon to model a building constructed on piers.  I have used a L1_pBlockage of 5, assuming the piers take up 5% of the available space beneath floor level.  I have set L2_pBlockage to be 100, assuming no water can enter the building in the event of floodwaters exceeding floor level.  My building is approximately 50 m long (in the direction of flow) and 20 m wide, and I am using a 3 m cell size.  During the flood event, the building is not flooded above ceiling level, but is flooded above floor level - the peak flood level is about 2/3 of the way between floor and ceiling level.

When I examine the lfcsh_uvpt check layer, the layer obverts and blockage factors of Layers 1 and 2 are as I expect them to be (i.e. reflecting the floor level and ceiling level of the building, showing 5% blockage under floor level and 100% blockage of the building above floor level).  However, the peak water level under the centre of my building is reported as being above floor level and is similar to the level outside the building. 

Shouldn't my peak water level under the building be limited to the floor level of the building since the building is 100% blocked above floor level?  Is anyone able to please shed some light on why I seem to have water entering the solid building?  Is there a better way to model this building in 2D?

Share this post

Link to post
Share on other sites

While it would be nice to say that this is like water levels being displayed as higher than soffit level in surcharged pipe networks (in which case the displayed water level is essentially the pressure at that location, the static head; though the volume of water present in the pipe is limited to only the space available) I'm pretty confident this is not the case. My understanding is that lfcsh only applies to the cell sides, and hence only impacts on the movement of water. But the cell itself, as a storage bucket, remains unchanged and retains it's uniform plan area all the way from ground level to the sky, right through your building in-between. As long as the additional storage in your model isn't an issue, then this can still be interpreted as the pressure under the building (make sure you building isn't going to float away!) and all will be well. If the storage is an issue then I'm not sure what to recommend, but you'll need to represent things slightly differently.

I hope that makes sense, but feel free to come back with further questions!

Share this post

Link to post
Share on other sites

Thanks for your explanation. 

Representing the floor of the building in a manner similar to a honeycomb is potentially an issue in terms of the impact that allowing the inside of the building to fill with water has on the modelled velocities under the structure and afflux caused by the structure.  The potential impact caused by loss of storage from the building has been raised as an issue by the assessing authority.

Is there currently any way of truly modelling a lid over the cell, i.e. the whole cell not just the sides, in TUFLOW?  Or is it possible to change the storage of a cell above an elevation threshold?  I need to account for the storage under the building, but am expected to show no storage inside the building (even though the building is not going to be fully water-tight).  There are a couple of other projects waiting in the wings where I am expected to model flow under (and then ultimately around when water level exceeds floor level) large suspended buildings, so it would be helpful to know if this is something that the software presently supports or if the "blocked" part of the building will always actually be modelled as porous.

Share this post

Link to post
Share on other sites

Sounds to me like there'd be benefit in the developers introducing a "2d_lsrfsh" (a "layered storage reduction factor shape") to build upon the functionality of a 2d_srf, in a similar way to how a 2d_lfcsh builds upon the 2d_fc! (please devs! ^_^)

In the mean time, I shall say that I'm not aware of a mechanism to do what you desire in 2D. If the detail of the flow route under the building isn't of too great an importance (simply that flow is permitted to pass through there and be stored there), then you could adopt a 1D-2D approach. You could adjust the 2D so that elevations are up at roof level for the building footprint and then create a 1D node with the appropriate stage/area relationship for under the building (check out 5.11, 5.11.1 and 5.11.4 in the 2017 manual; note that you can't set the area to be zero, so it's not a perfect lid, but you can make it something suitably small so that volume in your building is negligible) and link the node to the 2D around the building perimeter. There doesn't seem to be any documentation in the manual about the construction of the NA table beyond it being comma or space separated (please devs! ^_^) but I'd guess it's stage in col 1 and area in col 2 (and if that doesn't work, try the other way round).

The smaller you make that area above floor height, the more twitchy the model will get as flow enters or leaves the node, so be prepared to reduce your 1D timestep accordingly so the volume change over a single timestep won't be too large and trigger a overly large change in level...

It's not a pretty solution, but I think it would do the job! If you do also need the actual flow paths, velocities under the building then it's not going to work for you though.

Option 1 (press for the very rapid development of layered storage reduction and apply that in combination with the 2d_lfcsh you already have) would definitely be better (please devs! ^_^).

I'd be really interested to hear if folk have other ideas for how to approach this situation.

- - -

While I'm here though, I'll add that the setup you currently have should be getting both the velocities and afflux of the structure pretty much right; that's kind of what the 2d_lfcsh is designed for and the presence of the honeycomb simply enables the pressure to be correct across the system. It's only really the storage that's going to be thrown by this.

Which brings an ugly hack to mind. Suppose your void under the building was 2m deep, and you expected you peak water level around the building to reach about 0.5m above the floor level (as determined by your current model), you could apply a 20% storage reduction factor to the cells under the building (that is, the water is trying to be 2.5m deep, but you only want storage for the 2m void, so remove the other 0.5m worth). This would mean that when peak flood levels we reached you would be representing the appropriate storage within the building! Your 2d_lfcsh would still be appropriate as you have it.

The drawbacks are that:

  • you would need a different SRF for each event you're considering,
  • if the storage does have an impact on the modelled water level this could be iterative, (though if you were prepared to be conservative you could just apply a slightly larger than necessary SRF)
  • this would have some impact on the results when the water hadn't yet reached the underside of the property - helpfully you already have some results without this influence under the building, so you could compare and see if this was having undesirable impact.

And with that, I'll say good luck!

Share this post

Link to post
Share on other sites

Thank you Peter for your input.

All the suggestions are worth considering for the modelling exercise presented by the initiator of this post. All of them have some caveats that have also been mentioned.

Just to elaborate on the unexpected results from the initial query: The layered flow constriction layer modifies the cell width factor and form loss coefficient with height to match the flow area required based on the blockages and form loss coefficients specified in the 2d_lfcsh layer. The solution is still fundamentally a 2D solution (a single velocity is calculated for the cells) and not a 3D solution.

Currently it is not possible to 100% block cells in mid air in TUFLOW to simulate a building on piers.

We have already had a couple of suggestions to create the layered storage reduction factor and put it on our development list for future releases. However, the storage reduction factor would also be averaged in height similar to the 2d_lfcsh layer. Until this new feature becomes available, as suggested from Peter, you can use different 2d_srf layers for different events to accommodate for the loss of storage.

If you decide to try the 1D-2D approach from Peter’s last post with the NA table, the elevation/stage would be in a first column and surface area in the second column. The Manual has been updated to reflect this for the next release. However, based on your 2D cell size and the scale of the building, replacing the building with a 1D node may significantly change the flow around it.

If none of the suggestions seems acceptable for your project, maybe you can share with us a bit more about the purpose of your model on support@tuflow.com and we can provide you with a bit more guidance.


Kind Regards,


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.

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...