Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About peteraylett

  • Rank
    Advanced Member
  • Birthday September 1

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Bristol, UK

Recent Profile Visitors

5700 profile views
  1. Hi, just came across this post. Sorry it's probably not in time to be much use for you Adrian, but maybe it can be of use to others who find this thread in future. These are just my thoughts on the matter, I think the application of rainfall across 2D catchments is still sufficiently new that there probably isn't yet a consensus on best practice, just a bunch of modellers with their own thoughts and attempts! Anyway, here goes... 1. Simply applying SPR to the total runoff would be a simplistic approach to handling the losses within your system. Given you've made use of FEH to generate the inflows and rainfall data, you already have the data to go a step better by using the net rainfall, which has the losses accounted for. If you were to look at the ratio of net rainfall to total rainfall, as generated by FEH units, you would see that higher return periods (lower AEP events) generate a higher percentage of runoff than smaller events (as one might expect in the real world) and probably none of them match the SPR. 2. The loss model does indeed already consider infiltration, so if applying net rainfall from FEH then you need to make sure you don't also have losses in the TUFLOW model. An alternative approach, which can more closely reflect physical processes, would be to apply the total rainfall to TUFLOW and apply suitable soil conditions to represent the spatial distribution of the losses. It can be tricky to get hold of suitable information to inform (and calibration data to be confident in) your soil parameters though, in which case applying the net rainfall from "conventional" rainfall runoff techniques can be a good approach to follow. I don't feel like the above is my best writing, but hopefully it'll be of use to someone. As ever, if others have different thoughts on the matter I'd love to hear them! It's good to try and hash these things out together. Peter.
  2. Hi there! The first thing to note is that you've labelled your columns for height and width, but the data you've got in there is Z,X. Rather than a spatial coordinate, TUFLOW needs the actual width of the opening. So what you need to do is look at a set of elevations and establish how wide the opening is at each elevation. Then as long as your height data is in ascending order from the bottom to the top, things should be good! The width column does not also have the requirement for ascending order (otherwise, as you suggest, you wouldn't be able to have pipes which were narrower at the top than they are further down, so you could never have an arched top). I've amended your spreadsheet, so the data you supplied is now in columns D and E, and you've got new HW data in columns A and B. I hope that makes sense! Let us know how you get on. Peter. elliptical_culvert_Rev2.xlsx
  3. Excellent, well done! Thanks for following up with the feedback, that's good to know.
  4. Something of a late follow up to this, but I have a handy diagram which might be the explanation to what is being described here. In short, there's scope for it to simply be a reporting issue rather than a real depth occurring on this slope. Particularly in rainfall models, where some cells are wet but many are dry, because of how little and shallow the flow is, the model is prone to misreporting due to the use of cell corner data formats. See the attached diagrams for further explanation, but the steeper the slope the worse the reporting can get! ... I don't know whether the maximum tracking follows the max in the cells, in which case the final thing presented at the corners should be all good, or if it tracks the corner data, in which case the peak result is not going to be correct. I think it must do the first, as I don't recall noticing anything too funny in peak results! Hope so. One can these days make use of a cell centred output, which would avoid these issues altogether; but they do seem less commonly used. Hope this might help someone, Peter. Depth Reporting On A Slope.pdf
  5. Hi there, I don't know if this is either definitively a thing or the source of your problem, but I've had a bit of trouble using CN points recently; maybe they're a thing HPC doesn't like? Though I haven't actually noted that correlation, it could easily be a thing. Each time I've had troubles, I've switched out the CN points for a CN line (which has typically meant moving the 1D node(s), as the boundary wants to be where it wants to be) and this has worked. Your thing could be something completely other though, I don't know... But as an idea that might help, I give you this! Good luck! Peter.
  6. Hi Sam, Happily the result on that plot is not limited to quad-tree users, and works for 'plain' HPC too. (Though as Joe says, when you combine quad-tree and SGS then things get really good, as you can still get good expansion losses from structures with smaller cells and have the improved flow conveyance from lack of saw-teeth and trapping water which SGS brings) So you ask the very sensible question "what grid size to select?". I think though, that you've probably already given the best answer with "you should satisfy yourself that the results are reasonable"! On the plus side, all your trial runs with coarser than 'normal' meshes will at least be nice an speedy as you look for some result convergence and satisfaction that results are fine. For my part, and without much evidence to back it up, I'll say the following... For those less interesting channels one finds around the place, I'm much happier to have them at 1-2 cell kind of resolution (with more careful z-shape definition required) compared to when one was relying on a gully line to do the job. But any channel whose capacity you really care about should still probably be at least 4 and preferably 6 or more cells across. But now you can do that and switch on SGS! Referring back to the plot, you'll see that the high-res result is still a ways off the SGS result (and we'd like to hope the SGS results presented are the 'best' answers in this instance), so while you can maybe make your cells bigger to some extent, I think the important thing is to turn on the SGS. Others' views may differ of course. 😉 Happy modelling! Peter.
  7. Hi Duck, I'll let Joe come back on your other questions, but specifically that error 1033 is relating to TUFLOW trying to interpolate the inverts of your channels. With channels, setting inverts to -99999 asks TUFLOW to interpolate the inverts at the end of your network lines using known invert elevations from further away in your network. I'm not sure why it's doing that for your bridge, since it should be just applying the lowest from your XZ table (or HW like you had before). For the one structure then, you could stop TUFLOW trying to interpolate anything by manually setting the inverts yourself instead of going with -99999. It may be that this only helps move TUFLOW on to a different step which might reveal some data issue elsewhere and explain the odd behaviour, so don't expect it to cure all. I might even be more worried if this fixes the thing, as it would mean bridges weren't being handled as expected! I've just twigged it's not only trying to interpolate inverts, but the whole set of properties, so what I wrote above doesn't apply. Suggests it's not recognising the cross section data being applied, though your command looks right. Sorry, not sure what to suggest! Hope this helps, Peter.
  8. You're quite right; so tidal profiles could be built up of astronomical profile and surge profile, for example. The place it isn't allowed is when dealing with HX boundaries (and by extension QT boundaries) and HQ boundaries where adding up the water levels makes no sence. From the reading of those release notes Phil, such tidal examples would no longer function though? They'd only apply the first HT they read in (a solution which I wholeheartedly approve of for HX and HQ though, and will make downstream ends of 1D/2D river models that bit easier). Could TUFLOW perhaps permit multiple HTs (or at least have the option to do so for legacy models), and only if any of the other flavours of H boundary are applied do the "first one wins" approach? Easy enough for the user to just change the input data though, I suppose. Also, as a thought, in just about every other walk of TUFLOW life, when conflicting inputs are applied in the same place it's the last that wins; is there a rational for diverging from that approach here? Many thanks, Peter.
  9. ...so the rectification is to check your digitisation of your H boundaries at this location (as indicated by your spatial message(s)) and re-digitise at least one of them so they aren't selecting the same cell. 😉 If you think there's a reason why there should be more than one HT being applied at the same place, do come back and there can be some discussion on that! As a rule though, it's not allowed, as you're instructing the model to apply two (presumably conflicting) water levels at the same place, and the model can only every have one water level in a cell. If they are always applying the same level and you've snapped them together to ensure continuity, consider making them into a single feature.
  10. Hi Josh, It sounds like it could be a mass balance issue in ESTRY. When you run on GPU, you're normally pushed into running single precision, and sometimes that's not quite good enough. This could be on one of those times. You can test for this easily enough but simply running you model with the double precision engine and see if it comes out different! You'll need to add the command "GPU DP Check == OFF" to run this on GPU. Another possibility is that you need to run with a smaller ESTRY timestep (which would again manifest as mass balance problems). If you've got small elements then your timestep needs to be smaller. Often ESTRY timesteps seem to be a neglected consideration, and set at 1 (default) and ignored. You may very well need to go smaller. Finally though, are you sure it's not correct? A small trickle slowly draining off such an area would accumulate through a pipe network into something non-negligible. I'd start by looking at your mass balance outputs and see if there's anything untoward in there. Let us know how you get on, I'm sure other folk are likely to run into similar and would like to know the outcome! PHA.
  11. The big question is, what is it that would govern the transfer of flow from the one place to another? Passing flows from a 2D cell to a 1D node would normally be done using an HX or SX boundary, and which you'd use would depend upon what you've got going on. An SX boundary can draw water from (or pass water into) an area, if that's appropriate. Probably transferring water from an area of 2D to another area of 2D would also be done via a 1D network of some sort (making the starting assumption that it's not a 2D flow route between the two or you wouldn't be asking!), but again what you'd actually use would depend what was really going on. I'm not sure the above is the most helpful answer I've ever given though; if you wanted to come back with a bit more detail I could try for something more specific! PHA PS. It's nice to see you on the forum again, it's been a while!
  12. 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.
  13. ...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.
  14. 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.
  15. 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.
  • Create New...