Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Hi this was raised in 2009, but I've a colleague with the same problem - trying to get overlapping variable z shapes to work for a dam embankment failure. The overlapping variable z shape regions are in separate shapefiles that are meant to be triggered one after the other. That is, the Trigger Value of the first v_zsh is 1 hour, with a Period of 0.25, and then the next Trigger Value is 1.25, etc . However what happens is the embankment doesn’t do anything until the final v_zsh (at 3.5 hours) and then fails the whole way to the bottom. There is also a warning: type (1 2 3 or 4 randomly) WARNING: Variable Z mismatch zCur == (number), but z1 = (number), forcing zCur=z1. I have tried them all in one shapefile, and get an error* Does anyone have an experience with this? Does the order that the v_zsh are read in matter? The next approach is to conceptualise the failure without having the shapefiles overlapping - but we're still interesting if anyone has got overlapping variable z shapes to work. Thank you. *NoXY: ERROR 2232 - Failed to complete triangulation. Check region perimeter does not cross or snap onto itself. Otherwise please contact support@tuflow.com. Unused internal points = 1; Remaining perimeter nodes = 6 https://wiki.tuflow.com/index.php?title=TUFLOW_Message_2232
  3. Earlier
  4. I have run into this same issue and would rather not have to cut a section from a raster. Could TUFLOW add functionality to the lp_po, so besides just velocity (V_) and water level (H_), add ground surface elevation. Then all the data to make the cross-section would be in the csv. Thanks, Scott
  5. Hi Duck, Cheers for the input Peter, always appreciated. I'll look into this a bit further but I'd assume as when you're modelling a bridge in a full ESTRY network it looks to the xs associated with channels to bring that to the bridge unit as a bridge effectively has a length of zero as discussed above. In that sense, having a bridge unit standalone in the 2D, I would assume it takes your invert levels (so in the case of -99999 the lowest point on your HW table) and applies this as a flat value across the bridge bed and because of this doesn't accept xs data being applied. BB bridges differ from B bridges in that the losses due to flow contraction and expansion, and the occurrence of pressure flow is handled automatically. The only loss coefficients required to be specified are those due to any piers, and the bridge deck when it is submerged and not under pressure flow. Further information on how losses are applied can be found in section of the 2018 TUFLOW manual. Cheers, Joe
  6. 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.
  7. Hi JJStobart, thanks for the reply. This is the method I was going for but I keep getting 'Error 1033 - No XS line data downstream of channel "XXXX". Could not interpolate cross-section properties.' I added a 1d_xs line (the 1d_xs line was instead of the HW line, is this correct that I don't need both?) crossing the 1d_nwk line the same way as the 1d_bg in your example with a 'XZ' type. I read in the 1d_xs in the ecf like this; 'Read GIS Table Links == xs\1d_xs...' and had it pointing to a csv with X and Z values for the river cross section through the bridge. I can't work out why it is not liking that. Any ideas? Also if I use BB as the bridge type does that mean I don't need a 1d_bg file with the losses?
  8. Hi there, In short, yes it is possible to connect a 'standalone' bridge in a 1d_nwk file connected to the 2D with SX links. 1d_nwk file with a B/BB type input (for this example i have used a B bridge type). The only attributes needed will be a unique ID, type (B), and then an US/DS inverts set at -99999. (setting the invert levels at -99999 will force tuflow to set both inverts at the lowest point on your HW table, you can enforce invert levels and use the Z flag in your SX line if the user wants this). once you have your 1d_nwk file set up with your CN/SX links snapped to either side you just need to use the 1d_bg file to digitise lines intersecting the the 1d_nwk file. One that links to your HW table and one that links to your LC (losses table) as im using a B bridge type. the only attributes needed here will be the type of each and the source linked to the csv containing the info on the HW and LC values. schematisation of this below/attached: Useful pages with further helpful information: https://wiki.tuflow.com/index.php?title=1D_Bridges https://wiki.tuflow.com/index.php?title=TUFLOW_1D2D_SX_Advice Also as TUFLOW looks at bridges with a length of zero (assuming short structure with little frictional influence) if you have substantially long bridges it might be worth considering changing to a culvert set up. Cheers, Joe
  9. Hi, I am trying to add a bridge to a model using a 1d_nwk file but I am having issues (I usually model bridges in 2d but the preference for this model is 1d bridges) The model is a 2D rain on grid model with only culverts and bridges modelled in 1D. I am therefore trying to connect a 1d_nwk bridge to the 2D using SX/CN lines the same way you would with a culvert. The error I get is '1033 - No XS line data upstream of channel' between this and the only examples I can find being connect a bridge to a 1d channel line, I am not sure if you can connect a bridge as you would a culvert. Can you connect a bridge using SX/CN lines upstream and downstream? If not is there a way around this like creating a short 10m channel leading up to the bridge?
  10. 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.
  11. For the 2020-01-AB update, this message has been changed from ERROR to WARNING 2807 as per point 3.1.7 of the release notes https://www.tuflow.com/Download/TUFLOW/Releases/2020-01/Doc/TUFLOW Release Notes.2020-01.pdf. Regards Phil
  12. Historically TUFLOW has allowed multiple HT boundaries to be applied to the same cell. The water level used by TUFLOW is the sum of all HT boundaries. See the notes in table 7-4 (page 7-11) of the 2018-03 TUFLOW Manual.
  13. We are pleased to announce that an update to the 2020-01 TUFLOW Release (Build 2020-01-AB) is now available. This update includes a range of enhancements and bug fixes. The release notes (link below) provide a complete description of the 2020-01-AB improvements highlighted in light green within the document. The most significant changes are: More options for SGS map output with partially inundated cells More options for how infiltration applies to SGS cells New hazard output More robust handling of shapefile projections Workflow using asc_to_asc to remap output to a fine resolution for SGS models A range of other bug fixes Links to download: Downloads Page Release Notes (for changes from 2020-01-AB refer to light green shaded text) Any queries or issues, please don't hesitate to email support@tuflow.com. And enjoy! Best Regards TUFLOW Team
  14. Online Training We have recently published our new online training program so everyone can continue their professional development and TUFLOW learning from home. All fees associated with the 2020 online training schedule can be credited 100% toward any perpetual licence purchases or upgrades made before 1st January, 2021. Details are on the training page of the website: http://www.tuflow.com/Training.aspx?gblrmt. Training Courses can be filtered by location and include TUFLOW 2020 New Release training, integrated urban drainage modelling with TUFLOW training and Flood Modeller-TUFLOW linking training.
  15. Hi Josh, Could you please send a .tlf to support@tuflow.com so we have a bit more information? Thank you. Kind Regards, Pavlina
  16. Hi, We're currently modelling a 460ha catchment with rainfall on the grid. We are modelling roughly 2000 pits and pipes in the network. I have run ten ARR2019 temporal patterns for the 1% AEP 30 minute duration storm, and on first glance all seems well. However, I started looking at the flow going into all the pits and found a lot of the pits are showing a strange inflow hydrograph. It generally looks like the top of the hydrograph I’m expecting to see has been inverted on itself. See attachment. It seems to mainly occur where there is substantial flooding around the pit entry area. It also always starts around the 0.2 hour mark, generally a little before but it changes by pit. I was hoping someone could offer some advice. Many thanks
  17. ...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.
  18. This indicates that there is a Quadtree cell for which more than 1 water level boundary (HT, HQ, HX or QT) is being applied. There should be a spatial messages in the _messages GIS file which locates the cell.
  19. suggested putting an IWL of to be the same as the HT boundaries
  20. Running the new 2020 release and have just come across the following error: 2807 trying to apply more than 1 level boundary. Can not find any literature on this error. 😞 Any guidance on rectifying this issue would be greatly appreciated. πŸ™ Cheers πŸ‘½
  21. Hi Peter and Pavlina, Thanks for your help. It turns out that this too was fixed by running the model in double precision. Happy to have got to the bottom of it. Many thanks, Josh
  22. Hi Josh, Recently we had model (not rain on grid) with similar behaviour and double precision was the fix. Due to not enough significant numbers in single precision there was a trickle flow remaining throughout the pipes. The rest of Peter's suggestions are also worth checking, e.g. 1D timestep and justification for the trickle flow, especially with your model being rain on grid. If you can't get to the bottom of this, please send the model to support@tuflow.com for investigation. Thank you. Kind Regards, Pavlina
  23. 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.
  24. Hi, I am modelling a 460ha urban catchment with a large number of pits and pipes (~2000). The model is running as expected however between bursts the pipeflow in most pipes does not return to 0, and instead plateaus at a number greater than 0. By the time that flows are reaching the bottom end of the pipe network the cumulative effect of this is significant (see attachment). I've cross checked flows entering the pipe network via the pits and they don't seem to match. i.e. pit inflow =0, pipeflow > 0 (even at the most upstream pipe). The model is rainfall on grid and being run using GPU HPC. Does anyone have any ideas about what might be causing this? Many thanks, Josh
  25. COVID-19 has introduced numerous challenges globally across all sectors and regions, and is placing tight financial constraints on organisations and businesses. To help TUFLOW modellers with financing new licences we have introduced temporary measures that will allow clients to credit 100% online training and rentals towards new perpetual licence purchases made before 1st January, 2021. Online Training We have recently published our new online training program so everyone can continue their professional development and TUFLOW learning from home. All fees associated with the 2020 online training schedule can be credited 100% toward any perpetual licence purchases or upgrades made before 1st January, 2021. Details are on the training page of the website: http://www.tuflow.com/Training.aspx?gblrmt. Rental Licences Monthly licence rentals are a popular method of upscaling licence volumes when short term demand requires it. In numerous regions we are seeing governments invest in engineering projects in an effort to protect industry and employment within their respective jurisdictions and we have noticed a marked increase in the number of rentals in the past few weeks, possibly in response to this shift. To help finance new purchases, retrospectively from 1st April 2020, any monthly licence rentals made up until 30th September 2020 will be available as a 100% credit for any new perpetual licence purchases or upgrades made before 1st January, 2021. The TUFLOW team hope you stay safe and well through these challenging times. Please feel free to email sales@tuflow.com should you have any queries. Thank you, The TUFLOW Team
  26. Hi, Have you looked at the 1d_ta_tables_check.csv file? This reports the calculated hydraulic properties of any cross sections read into TUFLOW. https://wiki.tuflow.com/index.php?title=Check_Files_1d_ta_tables In QGIS 2 you can load in this check file and view visually in Tuplot - which makes it just a little easier to check. Unfortunately this feature has not made its journey across to QGIS 3 yet. To use follow the steps below: Open QGIS Open Tuplot Click 'Add Res + GIS' - select your 1D resuilts (.tpc file) Click 'Add 1D Table' - select the 1d_ta_tables_check.csv check file Open the 1d_xs GIS layer in QGIS Select 1d_xs layer in Layers Panel Should now be able to select cross sections and their hydraulic properties - you can also view result water levels on the cross sections Thanks, Ellis
  27. Hello, I am trying to use the TUFLOW plugin flux plot tool to plot flow from the xmdf's depth layer. I followed the example shown in the TUFLOW wiki: https://wiki.tuflow.com/index.php?title=TUFLOW_Viewer#Plotting_Flow Drawing the flux line works fine, but when I right click to end the line, it either displays zero for the entire time period, or produces the python error copied below. This occurs for a line drawn on both the max depth result and depth at a time. There should be data there, as the PO line shows a hydrograph. I tried this in a blank QGIS map, with projection set and xmdf projection set, and in my working QGIS file. I tried this with multiple xmdf results files. QGIS version: 3.8.2 TUFLOW plugin version: Output is xmdf results every 30 min for 24hrs; other TUFLOW plugin viewing utilities (cross section, timeseries) work well TypeError: 'float' object is not subscriptable Traceback (most recent call last): File "C:/Users/jmital/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\tuflow\tuflowqgis_tuviewer\tuflowqgis_tuflowline.py", line 255, in rightClick self.createMemoryLayer() File "C:/Users/jmital/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\tuflow\tuflowqgis_tuviewer\tuflowqgis_tuflowline.py", line 330, in createMemoryLayer worked = self.tuPlot.tuPlot2D.plotFlowFromMap(None, feat) File "C:/Users/jmital/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\tuflow\tuflowqgis_tuviewer\tuflowqgis_tuplot2d.py", line 602, in plotFlowFromMap velMag = velDataValue[0] TypeError: 'float' object is not subscriptable
  1. Load more activity
  • Create New...