Jump to content
TUFLOW Forum

katebradbrook

Members
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About katebradbrook

  • Rank
    Member

Profile Information

  • Gender
    Female

Recent Profile Visitors

1406 profile views
  1. Hello, is there a map output option to visualise where 2d weir flow is being calculated?
  2. David, The key question is "How wide is your creek?". In order for 2d flows to be properly represented, I would say you would need at least 5 cells across your creek - in other words, if you creek is not at least 10m wide then I would not consider this option (think also of your possible % error in representation of width with 2m cells). A wide, shallow creek would lend itself more to 2d than a deep, narrow creek. 2d modelling of channels is great if you are interested in the flow patterns within the channels and/or where such flow patterns do impact on conveyance/water levels/1d assumptions (of uniform water surface across section and average velocity for section being meaningful). For example if you have large stagnation zones, islands, tight bends (although note for bends, 2d is better than 1d, but still doesn't capture the full 3d effects that lead to superelevation on the outside of the bend). However, if your channel is relatively simple and/or with many structures (which are easier to represent in 1d) and it is exceedence of the overall conveyance capacity that is important, then you will probably be better leaving the creek in 1d. 1d models are good for calculation of overall conveyance (provided they are properly set-up of course, with sufficient cross-sections!). Hope this helps, Kate
  3. Hi Paul, There are British Standards BS3680 Part 4 and BS ISO 4377 which deal with different types of weirs. For crump weirs (often used in UK as gauging stations) see: White W.R., The performance of two-dimensional and flat-V triangular profile weirs. Proc.I.C.E.,Suppl.(ii) 1971, paper 7350S pp21-48) All the best, Kate
  4. Daniel, Yes, I had noticed this problem and did a considerable amount of benchmarking of weirs modelling between ESTRY, ISIS, HEC-RAS and hand-calculations and contacted Bill Syme. He investigated and recommended using Weir Flow == Method A in these situations where weirs are drowned and we are not expecting much headloss....see if this helps your weir.... all the best, Kate
  5. Some more thoughts on this, rather than a clear answer: the true basal shear stress is actually related to near-bed velocities, but TUFLOW gives a depth-averaged velocity. The assumption must be made that the spatial variation in near bed velocities and shear stress would mirror the TUFLOW velocity distribution and that the equation used (see Bill's post) provides an adequate relationship between them. However, as you have noted, the inverse dependence on roughness, n, may be an issue. On the one hand higher shear stresses are generated in rougher areas due to greater turbulence. But on the other hand, a high value of n may be specified on vegetated bars, or those with large boulders, to represent the impediments to flow presented by these obstacles. If this high n were used in the sediment calculations in these areas (which are also often of low depth), then high rates of sediment transport are predicted. This appears counter-intuitive as it is more likely that sediment in transport (which is expected to be of smaller dimensions) becomes trapped in these zones by large boulders, vegetation, debris dams and slack zones behind roughness elements. In other words, the roughness chosen for hydraulic calculations may not always be appropriate for shear stress calculations. One option in such areas could be to keep n for skin friction and use additional form losses for, well, form losses (and vegetation)..... Disaggregation of roughness to remove any vegetation effects is recommended in Mosselman, 2005 (Mosselman, E. “Basic equations for sediment transport in CFD for fluvial morphodynamics”, in Computational Fluid Dynamics: Applications in Environmental Hydrauilcs, Edited by PD Bates, SN Lane and RI Ferguson, 2005, Wiley p71-89).
  6. Hi Laura, I would add to Adam's post that if the sinuousity of your river was high, you may expect greater shear and turbulence at the river/overbank interface and this would be another reason to increase the losses here... Kate
  7. You could try an 'M'-channel. This requires a user-defined matrix of flow for various upstream head & downstream head combinations and so should allow you to represent your pump.
  8. If there are no network licences available when TUFLOW starts, it says it keeps trying but it doesn't manage to pick one up even when it becomes free. We have this problem on at least 2 machines, and with running latest version and when gone back to earlier version, and whatever the time delay for the search attempts is set to. Has anyone else had this problem, and if so do you know the solution?
  9. It would be really great if we could test inflow data (using -t flag) without needing a licence, so that when one becomes available (we have network licences) it is ready to go!
  10. Thanks for clarifying this. Unfortunately having to run all areas at the smaller timestep does remove some of the advantages of multiple domains. However, the difference in total volume was only 0.15% so whilst there are obviously small errors with how much is actually put in, I think there is still a reporting issue leading to the large mass-balance. It was only the large flows in my 1000-year that alerted me to the issue - all my smaller return periods seemed quite healthy! So maybe it wouldn't be too hard to sort out so it can cope? In the meantime, I am re-running all of this model at the same timestep (increasing run times from 15h to 60h) and in future may still make the 'mistake' of using different timesteps for model development but use a uniform one for final runs.......
  11. I have a multi-domain ISIS-TUFLOW model with 2 smaller cell-size domains for which I set a timestep of 1s and 2 larger cell-size domains for which I initially set a timestep of 5s (ISIS Timestep = 5s). Model runs fine, results look ok, but large apparent MB errors (>7%). MB error for each 2D domain on its own is ok (from MB2D.csv), but if I compare the volume coming in from ISIS (linked by SX boundaries), it is reported in MB.csv files as much less than it should be (according to ISIS) for the 2 smaller cell size domains. However, the total volume of water in all domains combined seems about right. Additionally if I run all domains at 1s then the errors dissapear, reported total volume in from ISIS is correct in these domains, and total amount of water remains similar to run with MB errors. In conclusion, therefore, I don't think there really are MB errors in the mixed timestep version (correct amount of water is actually going in and being stored), TUFLOW just thinks there is because it is not reporting the inflow volumes correctly for the smaller timestep domains. I assume this is a result of the Screen/Log Display Interval == 100 being in units of timesteps rather than seconds and therefore 100 timesteps in smaller cell domains does not represent same amount of time as in larger cell domains? Does my interpretation sound correct and if so, is it only related to using ISIS and could the MB reporting for mixed timestep multi-domain models be corrected in future versions?
  12. Would you be able to make use of the user-defined M channel where you can define a flow matrix for various possible upstream & downstream head combinations....
  13. Volume accounting is fine with ST boundaries so they've switched to those now....
  14. What was the conclusion on this? I have spotted the same issue in a model I am looking at....
  15. I have been looking at a model which has negative flows in a QT boundary after the main inflow has passed. These show as 'Q vol Out' in the _mb.csv file, but not as 'HX V out' in the _2dmb.csv file and as a result a mass balance error is generated in the 1d (and overall) components reported on the console/tlf file. (Some -dvol is generated but not enough to match the -ve Q). So, my question is firstly, should -ve flows in QT boundaries work, or would there be a better way of them doing it (if actually needed)? If they should work, why is there an anomaly in the mb files?
×
×
  • Create New...