Jump to content
TUFLOW Forum
tcressy

TSL Check file

Recommended Posts

I've been running TUFLOW version 2010-10-AC-w32 (iSP), and using the Engelhund Manhole Loss Approach.

The TSL check file looks something like the following (one line for each minute of model time):

:

D 0.27/0.03/0.19

D 0.28/0.03/0.20

F 0.31/0.04/0.21

F 0.35/0.04/0.33

:

From the manual, I've basically worked out that in each row, the 1st number is the culvert entrance (contraction) loss, the 2nd number is a sum of the losses due to changes in invert & bends, and the 3rd number is the exit (expansion) loss.

However, I have no idea what the initial letters mean & sometimes when the letters change, there's no numbers following them - why?

If someone could help me with this it'd be greatly appreciated. I'd also be interested in anyone's experience regarding the accuracy of using this approach.

Thanks!

Share this post


Link to post
Share on other sites

Hi TC,

Without knowing for sure which check file you are referring to, I would suggest looking at page 4-110 of the manual (outlet control flow regimes) this uses letters to indicate the water surface profile through a 1D structure. This is based on the assumption that the "TSL check file" is the estry output file (<<<file_name>>>.eof), my appologies if you are referring to the <<<fil_name>>>.log, but I doubt it.

happy modeling,

Justin

Share this post


Link to post
Share on other sites

Sorry, my bad for calling it a check file - I was actually referring to the <model/event name>_TSL.MID/MIF file created in the results folder.

Thanks, the charts on pages 4-109 & 4-110 were a great help. Understanding & following the regime changes is a bit interesting! The letters show culverts transitioning through regimes at the start of a storm event as follows:

G: empty

A: Unsubmerged supercritical

B: submerged supercritical

L: submerged entrance & exit

F: full pipe flow.

However, a few manual checks of the K losses being applied at junction boxes, found them to be higher than what we would have anticipated. For example a large main drain (1.8 x 1.8m box culvert) with a small lateral joining the main drain and a K loss of ~0.45 being applied to the main drain at the junction, when in practice the loss through this type of box would be quite small (0.1-0.2). We're a bit hesitant of using the automatic losses for now.

Share this post


Link to post
Share on other sites

Hello (TC??),

I assume the small lateral pipe is discharging into the large box culvert. Are we talking about an 'inlet expansion loss’ here? That is, the loss which occurs as flow expands from the smaller waterway or conduit into the larger one? If yes, then ~0.45 sounds ok, whereas 0.1-0.2 could be very low.

Loss factors do vary depending on the 'method' of calculating the loss. For example, I know of three methods for calculating expansion losses, two of which rely on the velocity before and after the expansion, and one which relies only on the pre-expansion velocity. Some methods apply the loss as an energy loss to the total energy line, whereas others (eg, sometimes QUDM) apply the loss as a pressure change to the HGL.

Would be interested to know what approach (reference) you are using?

Cheers

Paul.

Share this post


Link to post
Share on other sites

From my experience of using the automatic manhole losses, they generally seem to do a good job, with numerous manual checks providing similar losses to those being calculated by TUFLOW.

However, they should be used with caution as the 1d_nwk must be an accurate representation of the actual pipe network.

One thing to be careful of is if you have multiple pipes being represented by indvidual polylines, rather than by increasing the 'number of culverts' field. In these cases the angle at which the pipe is digitised entering and exiting your pits is not representative of the true angle and can increase your calculated losses. You should use connection (X) channels to fix this.

In other instances the pipe network data I have worked with had a large trunk drain running along the centre of the road, with small 300mm pipes feeding in from kerb inlet pits. There was a drop of a few metres between the inverts of the main culvert and the incoming ones. This resulted in very high losses being calculated, reaching the maximum loss cap of 4.0. In effect this was halving the capacity of the main trunk train, which didn't seem likely.

A site inspection suggested that there was probably an additional drop pit located on the small incoming pipes, where the losses would be occurring, rather than impacting the losses of the main trunk drain. However, this local detail was not represented within the drainage database that I was working with.

I would suggest that it is worthwhile checking for and overcoming inherent problems with the pipe network representation when applying the automatic manhole losses. The impacts of this are likely to be far more substantial than any small differences in calculated loss values.

Cheers,

Dan.

Share this post


Link to post
Share on other sites

Thanks Dan & Paul,

It was the losses along the main drain that we were interested in, not the laterals. Getting the main drain capacity right is critical & it's interesting to see others having a similar problem with losses applied to the main drain.

Yes, I was also looking at flows & HGL levels for a main drain along the centre of a main road with small laterals coming in at much higher inverts. While we know that these would be directly connected to the main drain with no junction box and only a small impact on the HGL levels in the main drain, Tuflow was applying losses that raised the HGL level by ~0.3 to 0.4m where each lateral joined in - significantly reducing the capacity of the main drain.

For example, a constant 1.8x1.8m box culvert main drain with a small 0.3m dia lateral joining in. The losses according to the TSL file were:

Upstream Main Drain: F 0.34/0.02/0.44

Downstream Main Drain: F 0.33/0.01/0.47

I wouldn't have expected much losses at all along the main drain in this case, however the velocity is high (~4.1m3/s) which may explain this? Having many laterals along a drain reach compounded the HGL losses and significantly reduced the main drain capacity. It seems an inherent problem with this approach that every intersection is assumed to be a junction box with expansion/contraction losses, while in practice many laterals would be directly connected.

I think you were saying the fix was to lower the inverts of the laterals to match the main drain invert? Our model has 5882 pipes, so inspecting each intersection isn't practical, but I could lower the laterals globally if this works.

Thanks for the comment re X connection channels - I'll be putting some of those in.

Regards,

Tim

Share this post


Link to post
Share on other sites

Hi All

Thanks for the excellent posts that really highlight the need in any modelling to query, check and understand the model outputs (especially when using automated methods). I'll give some thought (and let me know yours) for options to exclude laterals that have significant drops into a manhole. We can probably add a command something like "Manhole Lateral Cutoff Height ==" or improve upon the Engelhund formulation for losses due to change in inverts (which I suspect is causing the larger than desired losses). Another option would be to have a flag that allows you to exclude a (lateral) pipe from the manhole loss calcs.

Regarding the case of no loss values being shown in the _TSL layer, this occurs when the flow in the pipe is inlet controlled (Regimes A, B, K and L - Figure 4-6 in 2010-10 manual) or no flow (Regime G), and the entrance/exit losses are not used.

Cheers

Bill

Share this post


Link to post
Share on other sites

Thanks Tim,

I agree that manually inspecting all of the pipes and making corrections would be too big a task, and also with your comments regarding the assumption of each junction being a pit with expansion and contraction occurring. It is similar to some of the problems which I highlighted, in that it is the way the pipe/pit databases and corresponding 1d_nwk files are set up not being appropriate for the automatic manhole loss applications, in some instances.

The way in which I decided to overcome these issues, whilst still utilising the manhole losses and without being too onerous a task was to do the following:

1) Improve multiple pipe digitisations with inclusion of X connector channels (as mentioned previously); and

2) Create a manhole layer to suppress the creation of automatic manhole losses at pits with no 'SX' connections to the 2D domain (as this was where the majority of issues were arising).

You could then manually specify the losses at some of the suppressed pits if required.

Cheers,

Dan.

Share this post


Link to post
Share on other sites

Hello Tim,

With our urban flood modelling, we turn off TF’s automatic creation of manholes. The default (to insert manholes) for us tries to put manholes in where we simply don’t want them. Saying this, we are fortunate in that our core GIS pipe network database has a fairly accurate coverage of manholes, and we set these up in TF as a separate 1D layer.

I have to say that your loss factors still look good to me. I have not read the manual on this yet, but my understanding is that the TSL file was to record loss ‘factors’ (calculated k values) and not the actual energy losses (in m). At any rate, the middle figure which shows the sum of deflection/bend and elevation/drop loss factors in your case is still very low (<0.05), so the elevation of the lateral pipes above the main line may not be the problem.

Velocities of >4 m/s are incredible high and a worry. If you are seeing such jumps of ~0.4m in HGL across junctions then I would expect this is because of the velocity head which is a squared relationship (k*v^2/2g). Are your problems occurring generally throughout your entire model, or just in some specific cases such as a hillside? Definitely these velocities are unusually high.

In your original database of pipe network, do you have a proper manhole layer? TF obviously needs a node at any junction, but if that node is treated as a manhole when it is not then you will have problems. If you had a proper manhole laver, are you able to use this to select TF nodes, invert this selection to identify non-manholes, and then set the loss factors for those nodes with zero for the k values? Is there any way you can bulk select all these non-manhole junctions? Possibly you could assume every pipe less than diameter X(m) will connect directly to a pipe rather than a manhole, buffer these, select connected nodes, then set the loss factors to zero...

My experience with the Engelund Method is that it is pretty good. Out of the different methods I’ve reviewed it seems to be the most comprehensive and versatile. The bend losses are lower than those predicted in QUDM, but then again QUDM junction losses are often based on lab tests carried out in the 1950’s. Bill has also modified the Engelund method to give a much superior inlet expansion loss calculation. Packages like MOUSE or Mike Urban use an inlet expansion loss factor of either zero (no loss) or 1 – you simply have no other choice or flexibility. There are also some really nice in-built geometric rules where manhole dimensions are estimated by practical ‘design’ guidance if there is no other data. You won’t find a better solution out there!!

Regards,

Paul.

Share this post


Link to post
Share on other sites

Hi All, 

 

Please find attached a simple hypothetical pipe network that may help explain some of the output TSL values. 

 

TSL.pdf

Edited by Mitch3007
Last image was corrupted by forum software upgrade.

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