Jump to content
TUFLOW Forum

peteraylett

Members
  • Content Count

    186
  • 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

2874 profile views
  1. Old thread alert! However, it seems a good place for the following... I wonder if we could have quite the opposite of what I first asked for way back when, and have an option to make the copied model much larger! This time, by looking in the place where model results would be being written, if the simulation was actually happening, and if there is anything there (with the right name) then copy that into the copy of the model. Just to make things easier to bundle up together for issue. It may be that this would fit much better with the -pm option, rather than -c, but I'm still a little wary of -pm as it's done the occasional funny thing when dealing with a model with lots of scenarios (while -c will always perform flawlessly). Alternatively, perhaps a completely separate utility that just goes and gets the results (I don't always want another copy of the model, I just want the results collated) ight be a good idea..? Thoughts very welcome! It may be that there's some neat and clever way of doing the above already? I normally just do it manually, but copying a few files from the main Results/ folder, then some from plot/, then csv/ and gis/, then the .flts from grids/ all gets a little tedious! So anything to speed up the process would be appreciated. Thanks! Peter.
  2. ...but your max and min will be at the start and end of your simulation, as the model only permits the groundwater to fill up at present.
  3. Hi Monika, TUFLOW doesn't do any datum transformations, so everything that you specify needs to be relative to a consistent datum of your choosing. So yes, your boundaries and bathy all need to be using the same datum, and the outputs will then also be relative to that same datum. I hope that helps, Peter.
  4. Dear all, What I'd like to be able to do is run my model with a single named scenario and have the file names come out with only that scenario, but have that scenario reference a bunch of other scenarios which want running in combination. Here's what I mean: I have a model which I've used scenarios to represent a whole pile of engineering options, scatter around the area; lets call these OptA, OptB, OptC, OptD, etc. Having tested them individually, some have been selected to try in combinations. combination 1 would be OptA, OptC and OptG, say, which combination 2 would be OptA, OptB and OptW. I'd like to be able to reference simply "tuflow.exe -s comb1 mySim_~s~.tcf", where the .tcf contains a command that says something like: If Scenario == comb1 Activate scenario == OptA ! Yes, I've made up this command for the purpose of the example Activate scenario == OptC Activate scenario == OptG End If If Scenario == OptA !Do some stuff ... End If etc such that it then processes the rest of the .tcf as if OptA, OptC and OptG have been called as scenarios, BUT the results are all going to be called only mySim_comb1.tlf, for example. Is this currently possible? My understanding is that scenarios can be set in the tcf but would be overwritten by the command flag -s (so couldn't be called by it!), and also would still turn up in the filenames. I don't think variables help..? I could just add "comb1" to any If Scenario == OptA statement, but it's messy and I might miss one somewhere; I'd rather just be able to tell it when I ask for comb1, also do OptA. If it's not currently possible, do you think it could be implemented please? It'd keep file names tidy for easier bulk processing of complex projects and help keep tcf If Scenario statements cleaner (which can get quite messy enough!). Thanks, Peter.
  5. Hi again, Ok, so you've fallen into one of TUFLOWs traps for the unwary/inexperienced. The specification required in the .csv is literally how far up the pipe you are against how wide it is; you don't tell TUFLOW where both sides are, just how wide it is for a bunch of heights. See the figure attached; there's a blue arrow (height) there for every red arrow (width) and that's all TUFLOW wants. Critically, this also needs to be in ascending order (which is what that error you referenced is checking for). I've taken your spreadsheet and done a quick conversion of it to the right format, albeit it's got a bit less detail than you started with where your elevations didn't pair up. Probably close enough for modelling! See other attachment. I hope that makes sense. Any questions, just come back again! All the best, Peter. PS. For reference, your data also ha the 'how far accross' data in the 'H' column, and the 'how far up' data in the 'W' column, which is backwards. Arch_culvert_2.xls
  6. Hi there! Do you still have your original .csv describing the shape with the curves at the base? I don't see why it wouldn't work, so I'd be curious to see what you were working with and whether I can figure it out. Peter.
  7. I'll say the boundary attributes look fine. I don't suppose your model is up in some hills/mountains somewhere? And have you perhaps trimmed your input DTM to just your modelled area? (This is relatively common practice, for all it has potential to cause problems for people!) If 'yes' for to both of those, it may simply be that the row of cells which your boundary is selecting was not covered by your DTM, and has been set to some arbitrary elevation. The slope boundary is causing the water level to be up somewhere "sensible" in relation to the water that's sitting on the DTM, and so you end up with your insensible depths. In which case the solution would be to either get your DTM data again so it covers that row of cells, or moved your boundary (and code polygon) in a row of cells to where you currently have good data. You could check and see if this was your problem by looking in your zpt_check file and examining the elevations in that area. ... Alternatively, given this post is a month old at this point, you may have already solved the problem! In which case I'd be interested to hear what it was, just so we can all learn. Good luck, Peter. PS. As a general comment (which may not even relate to this case if the problem was not as I described) I'd recommend either not trimming DTM data to a model domain, or if you really want to then trim it with a generous buffer. Otherwise, you end up with difficulties like this at boundaries on the perimeter of the model, or if you find yourself needing to tweak your model extent (perhaps some glasswalling turns up in your extreme flood events) then you'll have to re-generate your DTM. All of which could be avoided by just not going to the trouble of trimming the data in the first place.
  8. Sounds to me like there'd be benefit in the developers introducing a "2d_lsrfsh" (a "layered storage reduction factor shape") to build upon the functionality of a 2d_srf, in a similar way to how a 2d_lfcsh builds upon the 2d_fc! (please devs! ) In the mean time, I shall say that I'm not aware of a mechanism to do what you desire in 2D. If the detail of the flow route under the building isn't of too great an importance (simply that flow is permitted to pass through there and be stored there), then you could adopt a 1D-2D approach. You could adjust the 2D so that elevations are up at roof level for the building footprint and then create a 1D node with the appropriate stage/area relationship for under the building (check out 5.11, 5.11.1 and 5.11.4 in the 2017 manual; note that you can't set the area to be zero, so it's not a perfect lid, but you can make it something suitably small so that volume in your building is negligible) and link the node to the 2D around the building perimeter. There doesn't seem to be any documentation in the manual about the construction of the NA table beyond it being comma or space separated (please devs! ) but I'd guess it's stage in col 1 and area in col 2 (and if that doesn't work, try the other way round). The smaller you make that area above floor height, the more twitchy the model will get as flow enters or leaves the node, so be prepared to reduce your 1D timestep accordingly so the volume change over a single timestep won't be too large and trigger a overly large change in level... It's not a pretty solution, but I think it would do the job! If you do also need the actual flow paths, velocities under the building then it's not going to work for you though. Option 1 (press for the very rapid development of layered storage reduction and apply that in combination with the 2d_lfcsh you already have) would definitely be better (please devs! ). I'd be really interested to hear if folk have other ideas for how to approach this situation. - - - While I'm here though, I'll add that the setup you currently have should be getting both the velocities and afflux of the structure pretty much right; that's kind of what the 2d_lfcsh is designed for and the presence of the honeycomb simply enables the pressure to be correct across the system. It's only really the storage that's going to be thrown by this. Which brings an ugly hack to mind. Suppose your void under the building was 2m deep, and you expected you peak water level around the building to reach about 0.5m above the floor level (as determined by your current model), you could apply a 20% storage reduction factor to the cells under the building (that is, the water is trying to be 2.5m deep, but you only want storage for the 2m void, so remove the other 0.5m worth). This would mean that when peak flood levels we reached you would be representing the appropriate storage within the building! Your 2d_lfcsh would still be appropriate as you have it. The drawbacks are that: you would need a different SRF for each event you're considering, if the storage does have an impact on the modelled water level this could be iterative, (though if you were prepared to be conservative you could just apply a slightly larger than necessary SRF) this would have some impact on the results when the water hadn't yet reached the underside of the property - helpfully you already have some results without this influence under the building, so you could compare and see if this was having undesirable impact. And with that, I'll say good luck!
  9. While it would be nice to say that this is like water levels being displayed as higher than soffit level in surcharged pipe networks (in which case the displayed water level is essentially the pressure at that location, the static head; though the volume of water present in the pipe is limited to only the space available) I'm pretty confident this is not the case. My understanding is that lfcsh only applies to the cell sides, and hence only impacts on the movement of water. But the cell itself, as a storage bucket, remains unchanged and retains it's uniform plan area all the way from ground level to the sky, right through your building in-between. As long as the additional storage in your model isn't an issue, then this can still be interpreted as the pressure under the building (make sure you building isn't going to float away!) and all will be well. If the storage is an issue then I'm not sure what to recommend, but you'll need to represent things slightly differently. I hope that makes sense, but feel free to come back with further questions!
  10. Hi there, It's hard to say for certain without seeing more what you're looking at, but it may simply be that you're not running more than 10 simulations at once? A single simulation (in classic at least, things will be different in HPC) can only harness a single core worth of CPU. I would expect that it would be close to fully utilizing one core worth though, so perhaps when you're running 4 concurrent simulations it shows as using about 20% of your CPU? Sorry if this is all way too low level an answer and you're actually running 20 sims at once! If that's where you're at and it's using less than 50% of the CPU then you've a bottleneck in your hardware somewhere (possibly RAM speed..?); but I'll leave it to another more knowledgeable person to discuss that! Hope that's of some use, PHA.
  11. Hi folks, For context, I've an HPC model that's not happy and is getting a lot of repeated timesteps before death, so I've set "Control Number Factor == 0.8" to make sure that everything is solidly staying below the theoretical limits even when not actually exceeding the repeat timestep criteria. All well and good. The thing that's got me asking is that it looks as though timesteps are being repeated when the control number limit is exceeded by only 10%, not the documented 20%. Is this supposed to be the case? In particular, it's Nd that's controlling my timestep most of the time, and it was repeating timesteps at around and in excess of 0.331 (here's a full sample line: "Repeating step 3729 due to high control numbers (0.549011 0.856216 0.336456). Reducing target timestep to 1.0738"), or after I've applied the Factor of 0.8 it's repeating at just, for example, 0.264801. In which case I'd be safe with "Control Number Factor == 0.9", unless it's still 20% on the Nu and Nc and only 10% on Nd? Perhaps I've missed something in the manual/release notes, but I've had a good look! I'm currently running 2018-03-AB. PHA.
  12. Hi there, Have you considered using the 2d_fcsh, flow constriction shape? Section 6.12.2 in the 2017 manual. (or even the layered FC shape, but I don't suppose much water goes over your vessels!) This type of object specifically supports floating decks (type "FD"), so your vessels can rise and fall with the tide, but maintain a constant draft. This also lets you specify a Manning's n value for roughness of the underside of the obstruction. Hope that helps! Let us know how you get on or if you've further questions. PHA.
  13. Is it possible that the water is ending up behind the embankment via another route? If the embankment is only a thin z-line/shape and cells on either side end up wet then in the results it will look like the water surface goes straight through the embankment, but isn't actually doing so. The step change at the embankment amid the otherwise very flat levels might indicate this..? Perhaps check our your velocity vectors and see if any are going through the embankment, or if all velocities by the embankment are actually running parallel to it (in which case the embankment is holding firm). If you haven't already, it'd also be a good idea to step through your model results and not just examine the maximum water surface, as this will be more informative for the flood development and progression, so would hopefully give you a clear pointer to the source of your flooding on the 'wrong' side of your embankment. Hope that helps! ...Is what I wrote on the day that the original question was posted! Just found it when tidying up some old tabs in my browser. Oops. Mostly it agrees with Pavlina, but I think there are a couple of extra bits that are worth having out there. Sorry if it's too late to be of use on this project...
  14. Hi again, Sounds like your linking is all good, so leaving that and moving on... It looks as to me as if in general you are seeing the effect you describe, with flows being slower at the sides of the channel and faster towards the centre where it's deeper. More local effects won't follow this same trend though and your depression (the red circle in the DTM image) is only very locally deeper; in this circumstance the approach and departure flows remain limited by the depth of the channel upstream and downstream, but that constant flow now has greater depth to flow through, and so gets to flow more slowly to pass the same flow- hence the reduced velocities at this location. Similarly, but conversely, where there's the lump in the side of the channel, water is having to squeeze around and over this and so is having to travel faster to get the water past. I would think it's this lump that's also causing the slower velocities on the east of the main channel, despite it being deepest there, as the lump disrupts and diverts what would otherwise be a nice flow path. I hope that makes sense! I summary, I think it all looks fine. If you're looking at making alterations in the watercourse here for engineering works, then you could do worse than taking out the lump and filling in the hole! (probably if you took out the lump, the hole would fill itself in over time...) Do ask further if I've not addressed your issue or haven't explained myself clearly. PHA.
  15. Hi Monica, Sounds like an interesting problem for you! Could you post a couple of images to illustrate your setup and the results you're seeing please? I think that'd probably help with trying to think about what might be happening. E.g. What is the distribution of velocities you're seeing? How have you linked the in-channel 2d domain with the surrounding 1d-2d modelling? All the best, PHA.
×
×
  • Create New...