Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by katebradbrook

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


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


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


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

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

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

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

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

  9. We have an ISIS-TUFLOW model for online storage options. TUFLOW is happy, but ISIS not (runs with prolonged poor convergence). Problems seem to occur due to oscillations of flow back and forth across HX lines once waterlevels are similar in the channel and on the floodplain over a fair distance upstream of control structure (flat water surface). Splitting HX lines up using interpolated sections doesn't seem to help much. We have super-rough strip along HX lines too. Any other ideas? Would it be better to use SX lines instead, with lateral spills in ISIS for which there are computational controls for this situation....?

  10. I have just built my first ISIS-TUFLOW model (but concerns would apply for ESTRY too) and am concerned how the actual flow entering the 2D domain is very dependent on grid size - there are 2 factors here - one is that the ZC levels along the HX cells in my smaller grid (30m) pick up some low points missed by the larger grid (50m) - this results in greater flow to 2D domain from 30m grid along these spills. In another location where spill is over just 2 cells in both grids, this represents a flow width of 100m in larger grid and 60m in smaller grid and consequently more flow goes in here for larger grid. These factors overwhelm any attempt at traditional 2d grid dependence assessments. If I went to 10m cells, flow entering would be different again....maybe there needs to be some sort of porosity applied along HX lines that can take account of 3D zln points at a closer spacing than the grid size? Anyway, I'm now thinking of putting the spills back into ISIS and having SX links to 2d domain - not what is normally recommended, but I feel it would allow a better representation of spills (I could have elevations at a much closer spacing than my 2d grid). Any comments?

  • Create New...