Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Rob

  • Rank
  1. We undertook some detailed analysis of these issues for some urban catchments we did in Melbourne, assessing both loss rates and runoff coefficients against more traditional hydrological modelling approaches linked to flood models. We used a pre-priming method described by Paul in one of these cases by applying 10mm to the catchment a number of hours before the design storm to remove depressions that were not directly connected to the drainage system. Th 10mm was based on an analysis of the volume remaining across the catchment after the storm had finished (i,e, the bits that would never drain). Interestingly the results showed virtually no difference to the case when this was not done (less than 1cm of difference in levels along the main flow lines at 2 SD). The flows and flood depths generated by direct rainfall approach were broadly consistent with those derived from distributing a equivalent volume from a hydrological model flow across all pits in each small subcatchments. Overall catchment size was about 6 square km and subcatchments were about 2-4 ha. We tested with a very large storm event and good pluviograph and level data. The most salient point was that if we had been only doing a major drainage study, the runoff coefficients needed to be greater (or loss rates smaller) in the direct rainfall approach and the distributed hydrological modelling approach to achieve the same flood levels as the broadscale catchment approach (flow input along the main drainage lines only). I think this is likely due to the influence of minor surface features causing retardation, the efficiency of the pipe network and the flow path length in the distributed models. I think that the method you chose really depends on your catchment and the level of detail required - our results showed that for these urban areas, the difference in pre-filling these storages was negligible. Your results may vary!
  2. Hi Bill, Thanks for the response. We were seeing very large mass balance errors (in the order of 30% over a single .5 second timestep) as a result of this smoothing over the model which was causing the run to crash. This appears to be because of an issue at grid points at the edge of the defined area being interpolated to elevations that were far too low (interpolating between 90m and 0m, on a 2m definition). We have adjusted these to ensure the Zpts are all defined and this has solved the problem. I presume because the interval of the smoothed change is so small that this is why there is usually no mass balance error, event though the smoothing (from the table above) appears to add 1000 times more rainfall over the period than in the definition file. We are using the latest version as we did have some trouble with the earlier builds. Cheers Rob
  3. I have an issue where a large mass balance is being generated every time there is a change in our boundary condition time series. The model use 2d RF boundaries with f2 factors not at unity (varying from about 0.3 to 0.9) and I am applying a step function for the rainfall time series to ensure that the expected volumes are delivered to the 2d grid. There are 24 RF conditions in the model. The tlf file shows the following information for the RF boundary Rainfall histogram conversion from mm to mm/h (Col 2), m/s (Col 3) and m3/s (Col 4) after losses and area factor is: 1 0.000 0.0000 0.000000000 0.00000 2 0.000 0.0000 0.000000000 0.00000 3 0.082 0.0000 0.000000000 0.00000 4 0.082 9170.0000 0.002547222 0.01019 5 0.083 111.8293 0.000031064 0.00012 6 0.165 111.8293 0.000031064 0.00012 7 0.165 13050.0000 0.003625000 0.01450 8 0.166 157.2289 0.000043675 0.00017 9 0.249 157.2289 0.000043675 0.00017 10 0.249 5550.0000 0.001541667 0.00617 11 0.250 67.6829 0.000018801 0.00008 12 0.332 67.6829 0.000018801 0.00008 13 0.332 0.0000 0.000000000 0.00000 What is concerning in the above is that lines 4, 7 and 10 are not in our bc timeseries and appear to have been added by Tuflow. These times are where the very large mass balance errors occur (over 30% on a single step). Can anyone provide some advice as to if these mass balance errors are real and if they are, how we get rid of them? Cheers Rob
  • Create New...