Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About tcressy

  • Rank
  1. tcressy

    1D Pump Sumps

    Thanks Kate - will look into M-channels, though the requirement of 0 flow if the downstream depth matches or is greater than the upstream depth will seriously hinder implementation as a pump I think? Thanks
  2. tcressy

    1D Pump Sumps

    I am trying to model a stormwater drainage network that drains down to a small pump sump. The pump is used to pump over sand dunes into a higher drainage system. I think I understand how to pump from a 2D domain into 1D (HS boundary & SC transfer into the 1D), but am at a loss how to create a pump entirely within the 1D domain (i.e. 1D to 1D). This model is running entirely within Tuflow (i.e. no ISIS, etc) Any assistance will be appreciated, Regards, Tim
  3. tcressy

    TSL Check file

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

    TSL Check file

    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.
  5. 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!
  6. Thanks, Yes we took our pit relationships from some calibrated relationships we had in Drains - though it would be very nice if TUFLOW could automatically work out if the pit was on grade or sag and apply the appropriate relationship (I appreciate this would be difficult). I have been using Z_lines to create little banks around the low sides of pits that weren't capturing flow (to 0.1m above the pit ZC level). The only thing is that out of the ~3100 pits in my model, there's over 100 that I have to manually do this for . . . a nice new feature would be a flag on the pit channel to do this automatically. Regards,
  7. Details of my model: - 4m grid size - Q type pit channels to take flow from the street network into the 1d drainage network - H-Q database of accurate H-Q relationships, for side entry pits, grates, etc - pit channels have an SXL flag & US_Invert level used to lower the cells ~0.1 below the surrounding terrain. - SA points to input the flow hydrograph from each sub-catchment - these are applied to the same cell as each pit channel. I'm finding that when the 2d slope is steep (i.e. allotments fall steeply away from road, sometimes with surrounding ZC points up to 3m lower!) flow tends to spill into downstream cells rather than through the pit channel into the 1d network. This is probably due to the flow spilling rather than building up a ponding depth on the cell for the H-Q curve to apply. I'm trying to lower the pit channel cells below the surrounding cells to create some ponding depth. However lowing them by too much messes up the H-Q relationship, puts cells below the 1d_network, etc, etc. My question is do I need to lower the ZC points below the ZC levels of surrounding cells or just the ZU & ZV side points of the pit channel cell? Some help would be appreciated - thanks!
  8. .mat files in Windows7 ------------------------- We have found that trying to open a TUFLOW results folder that contains the .mat file crashes explorer under Windows7. There was no way to work around this, as the folder couldn't be opened to edit/remove the file & the File Association program in the Control Panel also crashes. A quick bit of internet research and apparently this is a common problem: .mat files crash windows explorer. This may be related to Microsoft Access installing a faulty dll handler for this file type. If you can change the file association you can fix this problem! This problem will no doubt be addressed in a windows update at some stage. However for the present, . . . A strange workaround: -------------------------- I found that while others in the office were having this problem, my computer was fine. The answer was that I had installed Winamp (www.winamp.com), as the default media player, and it was associated with .mat media files. While maybe not the best way to solve this problem, installing Winamp will fix this problem and stop explorer from crashing.
  9. The 3Gb switch is often used to fix memory problems in 32bit windows environments (increases the program memory allocation). Enable the 3GB switch on Windows Vista and Windows 7 (32-bit) • Right-click Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator. • At the command prompt, enter "bcdedit /set IncreaseUserVa 3072" • Restart the computer. Disable the 3GB switch on Windows Vista and Windows 7 (32-bit) • Right-click on Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator. • At the command prompt, enter "bcdedit /deletevalue IncreaseUserVa" • Restart the computer.
  10. I have a model with a 1D pipe network and 2D surface. I have placed 2D PO Lines across the roads to determine how much water is spilling from the underground drainage system. These PO lines do NOT cross any 1D network. I have found that is some locations the PO hydrographs have a peak flow that is obviously incorrect (say about 20m3/s) even though it looks stable. To try to work out why the value was so high I placed more PO lines directly upstream and downstream of the subject PO line. I found that these hydrographs had a reasonable peak flow of about 1-2m3/s, which is what I was expecting. The only difference that I can see is the PO Line causing high peak flows was much longer than the other PO lines. It may be picking up sheet flow on the side of the road however I didn't think that this would cause any problems. Could anyone suggest why this might be occuring. Cheers
  • Create New...