peteraylett

Members
  • Content count

    166
  • Joined

  • Last visited

Community Reputation

0 Neutral

About peteraylett

  • Rank
    Advanced Member
  • Birthday September 1

Contact Methods

  • Website URL
    http://www.edenvaleyoung.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Bristol, UK

Recent Profile Visitors

960 profile views
  1. Hi Tom. I'm just noticing you say that this is concentrated along your QT boundary, not the HQ. Is that correct? On the basis it is... I assume that a QT has to establish its own stage discharge relationship, based on the underlying cells (in the same way as an HQ does) and if you are putting 'too much' flow into the model then that stage/discharge relationship could be exceeded and TUFLOW won't know what to do. I'd guess there's no equivalent 'd' value here, so your best bet would be to extend your QT boundary further. If "QT" in your post was just a slip of the finger, then hopefully the Riders of Rohan's suggestions will see you right. Please let us know how you get on, PHA.
  2. Hi, I'm just wondering if this might be one of the few times in life where an ST boundary might be helpful? It's applying a source of flow over time, but importantly the specified flow is added to every selected cell. So if you're scaling your basic inflow by roof area to get all these 900 SA inflows, you cold instead just scale once to get the flow per cell and specify the same boundary name for all your roofs. Should do the job? If that's not what you're doing, I'm curious to know more! Good luck, PHA.
  3. In large part that's going to depend upon your topography/water surface at the location you'd like to join these different resolutions... Here's why: The link happens by using hidden 1D nodes that are connected to each 2D domain using HX boundaries This means that the water surface can only 'bend' along the boundaries every time there is a hidden node It's worth noting at this point that the user has control over the spacing of the hidden nodes! As with other 1D elements connected to a 2D domain via HX then, it is important to have both Enough nodes to capture and curve in the water surface Not too many nodes so they're always at least 3 or four cells apart. So, if your water surface is well enough behaved, or your boundary can be carefully digitised along a water surface contour, then you should be ok with whatever cell sizes you fancy! You're limited by your larger cell size, as you don't want your 1D nodes less than three cells apart; in your main example, that's a spacing of 60m for the hidden nodes. You then need to consider whether that will be sufficient for the finer resolution you wish to use. If your water level is nice and flat, you'll be fine! Or if your land is sloping nice and uniformly parallel to the direction of flow, you'll probably also be all right. Either way, do check your results look sensible! If your water surface is NOT flat or constantly sloping, you might get away with it if your cell sizes are not too different, but by far my strongest recommendation would be to re-site your boundary somewhere where you do have a tame water surface. The ultimate preference would be not to have your different domains touch and link 2d-2d at all, by transitioning somewhere dry (two disconnected bits off flood plain with a river that flows from one to the other), or transitioning either side of a 1D channel (i.e. left bank high res, right bank low res), but that's often not possible. I think for my own purposes, I've not wished to reduce by more than a factor of 5 when refining, but the nature of the link means there's neither requirement nor benefit in having multiples or factors of 2 between your 2D cell sizes. With a good location for sitting your boundary, any of the combinations you suggest would be fine. I hope that makes sense and helps! Do feel free to ask further clarifying questions if needs be. PHA. PS. To the devs, any progress on the original question in this thread? The whole nested 2d with quad-tree (or nine ways) refinement of cells thing that was discussed so many moons ago?
  4. Hi Sam. Yes we have this problem! And yes, we consider it to be a real pain! My best tip is to convert all the MIF/MID files to shp before you start editing anything, so that everything you digitise is directly snapped to the already converted files; if you snap to the MIF and then convert it, or try and use it as a MIF, your chances of success are slim. With some models, we've been able to relax the snapping tollerances a bit and things have been ok, but that's not always a good option. Any other tips greatly appreciated. I assume there's a whole load of people out there who are similarly frustrated?!
  5. Hi Francis, Hi Francis, I wonder if your crashes are related to this: ? It all just goes away when the model gets finishes initialising and starts trying to run. However, to answer your question, if you run the simulation manually in a command window, it will stay there for you. To get a command window, hit the start menu, type "cmd" and press [enter] (or click with the mouse on the "command prompt" program). In here you'll need to construct the full command to run TUFLOW, something like: "c:\TUFLOW\bin\TUFLOW_iDP_w64.exe m:\your\folder\structure\yourControlFile.tcf" noting that you'll need to include the full, correct paths to both the TUFLOW executable (which could be installed just about anywhere) and your .TCF (which in the example above is on another drive) unless you change directory to the folder where your control file is. And you may also have fancy things for events or scenarios, but if you do, you probably don't need me to tell you about them. Hope that helps. Let me know if it doesn't make enough sense. PHA. As an aside, the manual refers to this in section 11.5.2, where it's bullet-point 4 in the set of options for running a simulation. It then refers the reader to the wiki saying that all the methods are described there; regrettably all the other methods are described there, but not this one, which is the only one which will preserve the window once the runs die! If a dev reads this, please take it as a request to update that page, thanks!
  6. Hi, Yes, we've been having the same difficulties! In some models they work, and in others they don't and it doesn't seem to be consistent; have had fails with ISIS-TUFLOW, ESTRY-TUFLOW and TUFLOW by itself, as well as successes with all three! But where it does fail, it fails for both POs and Reporting Locations. One time a model failed with just some lines present, but then worked when some points were also read in. But another time, none of just lines, just points or lines and points worked (in the light of the other model, we thought we'd try ). Most perplexing! I'd meant to post previously, but hadn't quite got round to it, so thanks for doing so. Fingers crossed a solution is already in the works from the devs? Just to add, where they do work, the new Reporting Locations are great, and in combination with TuPlot in QGIS are really useful! Would really appreciate it if they worked more of the time! PHA.
  7. Very nice. Thanks for letting us know!
  8. In 2016 there was a bit of a change in the structure for writing results. Those 1D results now appear in subfolders inside whatever folder you've specified for your 1d results to go to; in <1d_results>\plot\csv\ .
  9. Hi Rachael and Support, As a follow up question; what does TUFLOW do in the event that the depth of the boundary is exceeded? Does the outflow get limited to that at the limit of the discharge curve, and water back up behind the boundary, or does TUFLOW just set the level in the cells to be that at the limit of the discharge, and remove more water from the model? Or something else?! I would have thought one of those options, but from looking at some model results which report this warning, the limit of the data is 6.5mAOD, but the max water surface next to the boundary is only 6.45, which is not what I was expecting. Some clarification would be appreciated. Either way, I'm probably going to be recommending adding a 'd' value in the case of this project, but it would be nice to know. Thanks, PHA.
  10. Hi Lucy, You've done a good job of identifying possible causes of the problem! I can only add one further thought, which is timestep, but I'll work through your points as well with some considerations. Precision - Yes, using double precision can make this measure of difference to the solution! While 40m isn't excessively high, I'd definitely be recommending double precision and it sounds like you're going that way anyway, so that's fine. As an aside, there's no reason I'm aware of to ever not use double precision; modern processors are normally natively double, so if anything will only slow down if restricted to single precision (on most it will make no difference)! Oh, unless you're short on RAM perhaps... Boundary location - The 2d-2d link has long been a source of problems with continuity between the domains, but as I understand it, improvements were made in a recent release. I haven't actually used it since then, but regardless I would think it's still sensible to minimise boundary impacts by trying to place them where there is as little transfer as possible.d value - This I think is probably your problem! Unless you have a vast number of vertices. I would recommend setting this to between 2-10 times the cell size of your coarser domain (5 is a reasonable starting point). This is important, especially for rainfall models, because under the hood, a 2d-2d boundary is an HX line into both domains and a set of secret, hidden 1D nodes. This means it's forced to apply only a straight interpolated water level between nodes, which is fine for many flooding situations, where the water level is essentially flat, or reasonably smoothly sloping off somewhere. However, when you're working with very shallow flows (as in a rainfall model) and your ground is not wonderfully smooth (as in an urban environment) then you'll need a greater resolution in your boundary to accurately reflect the shape the water surface should be around your boundary. I hope that makes sense! If not, come back on this point and I'll try again. In any case, set a d value and make if fairly small; smaller will give better shape to the water surface, which is important, but also increases risks with stability as the storage available in each 1d node is correspondingly smaller.MB1 and MB2 outputs - there is no maximum stored in these outputs (although as a thought, outputting the sum of the absolute values from each timestep at 99999 would probably be quite a useful output!), so you won't be able to process out a max. If you need to convert a few to ascii, just pick a few interesting times, like a little while after first wetting, around max depth and somewhere into the recession. For preference though, being able to step through your saved outputs is really useful; you might wish to consider a trial of SMS, or a copy of QGIS with the Crayfish plugin (both of which are freely available, other options also out there!).Timestep - Final thing, is to check you're using a similar timestep/cell-size ratio as from your 4m run, for both your domains, or indeed a smaller timestep now the resolution is finer. You may also see benefit without too much slow down, of having a timestep in the 8m domain that's nearer to that in the 2m domain (i.e. 2 and 1 second respectively could be better that 4 and 1 second). This lets the 8m domain respond and change a bit more frequently, which can make a difference in a rapidly changing situation such as urban rainfall events. Often the computation cost of a few more calculation in the coarse domain is minimal compared to the cost of the fine domain. As a note, I'd assume your timesteps are already smaller than in my example above.As noted above, I'd expect your problem is most likely associated with your d value and the spacing of the water level control points (hidden 1D nodes), but the other points are well worth considering too. Good luck and please do let us know how you get on and any further thoughts, observations or questions you may have! PHA.
  11. 2d_bc

    Interestingly, I've always seen it as HXi = Isis links and HXe = Estry links! Which would be backwards from how you have it... Good job I don't differentiate such things in my own bc layer names. Anyway, exactly as already said, the differentiation stops with the file names, the HX lines do the same thing either way. They apply water levels from the linked 1D model nodes to some selected 2D cells so that water may flow into (or out of) the 2D domain. PHA
  12. Hi, A couple of specific points: 1) It looks like your initial conditions (ICs) in ISIS are not quite consistent with your boundaries (hence the wobble at the start of outflow hydrograph shown in your bitmap); you might do well to extract ICs from about 0.75 hours where it's all smooth but still at low flows, and apply that at time zero. ISIS may be able to handle the jump at simulation start, but when also interacting with TUFLOW that may just be a bit much. 2) Yes, you'd do well to have your ICs low enough that there should be no exchange of flow between ISIS and TUFLOW at the start of the simulation. If you've got save maximums on in the .TCF and it achieves even a couple of timesteps before dying, you'll be able to pinpoint where there is interaction between the 1D and 2D; that's the place to be focussing on! I would advise against applying a widespread dz change of your banklines, as that's going to unrealistically affect results elsewhere in the model. And more generally: 3) Do you have any boundaries attached to the 2D that are not linking with ISIS? i.e. an HT or HQ? If these are near to the HX boundaries linking to ISIS, then they'd need to be consistent with the 1D data (so if you've got a NCBDY with a gradient of 0.002 on it, then a nearby HQ in TUFLOW would benefit from also having an automatic 0.002 gradient applied; or an HTBDY in ISIS would need to be at similar (or the same) levels as a 2D HT in the vicinity. 4) All the usual guidance about stabilising 1D-2D models applies; not having a 1D channel that's "thin" compared to your 2D cells, using a 1D timestep that's half the size of your 2D timestep, and the 2D timestep (in seconds) no larger than half the cell size (in metres), etc. If you can give any further detail about where it's failing (from point 2 above) there may be further advice to be offered. Good luck!
  13. Hi David, If you've got: - the data to describe the channel well - sufficient resolution the represent the channel (4-6 cells minimum measured perpendicular to flow), exactly as Kate said already then I would say yes, go fully 2D! I'd say having the data for the channel is normally the tricky bit... If you're all in 2D, you avoid limitations involved with transfer of flows over boundaries and momentum issues, not to mention it does explicitly represent bends and the like which may be completely ignored in a 1D model (though again, see what Kate said on this). Plus your processing afterwards is probably easier, and most clients will find it more comfortable conceptually, if they wish to know about such things. It may even run faster as you'd have the option of using adaptive timestepping on a 2D only model. And the downsides? Well, maybe stability problems if your channel gets really interesting at some point (you may need to reduce your timesteps, or courant limit, a bit if you've any tight bends), but other than that, none that I can think of right now... I certainly wouldn't let the fact a past study used 1D elements put you off going fully 2d. ESTRY structures can be linked in as and where required without too many problems, so I wouldn't let those put you off either. I hope that helps your thinking, but as ever my views are my own, and I'd welcome hearing from others, especially if they can think of things I've missed! PHA.
  14. Hi folks, That is indeed a very interesting paper! When it comes to rainfall, things increase in complexity; what do you want to happen to the rain that lands on the buildings? Do you want it to run off rapidly, as if from a pitched roof? Or would gutters/drains be catching that water and rain onto the buildings should be removed? Or something else?! You probably don't want a light shower over a town to show all the buildings as flooded because water lands within the footprint, and depending upon your intensity and roughness within the building, depths may build up higher within the building than in the vicinity as water is unable to run-off the footprint. Rather than simply applying high roughness, I would strongly recommend using a 'stubby buildings' approach, where the footprint is raised up to threshold level, thus ensuring that when there is only shallow flow adjacent to the building it does not cause the building to be flooded. My house stays dry even when there's a puddle outside! A couple of possible approaches to throw into the mix then: a ) Represent your buildings how you wish (I guess high roughness remains the standard), but as you suggest cut out the building footprints from the 2d_sa. On the assumption the drains are overwhelmed (the normal working assumption; people rarely include the impact of drainage in their models) then you'll need to increase the flow being added to the SA. That is, work out the volume of water that would be dropped across the area including the buildings, and then drop that volume on the area without the buildings. b ) Estimate the capacity of the drainage system and and use a second 2d_SA with negative values to remove that flow from the building footprints. Thus for a light shower, or during the start of a more serious event the buildings would remain dry (unless water flowed in from the adjacent non-building areas), but if you have higher intensities such that drains are overwhelmed then you still see that in your model. I actually prefer option A above, in combination with stubby buildings. You get all the rain landing in the area, it's consistent with common practice regarding drains and the building doesn't get wet inside unless adjacent water levels rise far enough (the roof doesn't just magically fail ). I hope that makes enough sense. There's probably quite a big debate to be had here and in part it's going to depend upon what you're looking for from your model as to whether it makes any real difference anyway! I hope other people share their thoughts.
  15. Hi Roger, I don't think there's any hard and fast answer to this, but for my preference, the solid obstruction and reading the water level adjacent to the structure. This is simulating the effect of the building being fully flood proof up to (and beyond) the level of the water, which is presumably what you are aiming to achieve with your knowledge of the freeboard. It's also the conservative option, and I'm rarely averse to an increased safety margin. I have to say, I've never seen such an analysis undertaken on a building by building basis; only when designing a flood embankment or other defensive structure. However, I'd say the same principal holds true, unless you'd expect that the water will be able to enter a void underneath a raised floor? My final thought is that it probably makes very little difference to the final answer, unless your building footprint is a significant portion of the flooded area. I'd welcome other folks thoughts! Maybe there should be some hard and fast guidance? Hope that gives you something useful to think about.