Jump to content
TUFLOW Forum

All Activity

This stream auto-updates     

  1. Last week
  2. Hi Ben, We haven't heard from any of our users about using github for TUFLOW control files. If you do try it, please let us know about your experience. Kind regards, Pavlina
  3. Earlier
  4. We are pleased to announce the release of TUFLOW Classic/HPC 2020-10-AA. This release is a substantial update to the 2020-01 release that includes enhancements to the HPC and Quadtree solvers and new default settings. HQ boundaries in HPC and Quadtree now default to the same approach as used by Classic solver Dambreak piping failure and new 1D dambreak channel Automatic adjustments of 1D structure losses according to the approach/departure 2D velocities Two new layered flow constriction approaches for improved modelling of pressure flow at bridges A range of bug fixes primarily relating to the new functionality in the 2020-01 release The new executable and the 2020 release notes are available for download from: https://tuflow.com/downloads/#tuflow. This release is included in the 2020/2021 maintenance period, which was invoiced mid year, therefore licences will need to be updated for the 2020/2021 period. For any licensing queries, please contact sales@tuflow.com. An update to the TUFLOW manual for the 2020 releases is now underway, but in the meantime the 2018-03 release version of the manual is the latest and should be read in conjunction with the 2020 release notes. Happy modelling from the TUFLOW Team and as always, any queries, suggestions or issues, please don’t hesitate to contact support@tuflow.com. Best regards The TUFLOW Team
  5. For anyone arriving on this page after the 22nd of October: the forums are online at their new address and no further outage is expected. Forwarding has been put in place to ensure any old links still work, but please follow Bill's advice and update your links and bookmarks where you can.
  6. Hello all We are pleased to announce that we are transitioning to a new website (same www.tuflow.com address) over the next day or so which will change the URL to the forum. Whilst old URLs will be redirected, should you have any shortcuts to this forum it is recommended to change from the old link (https://www.tuflow.com/forum/) to the new link (https://forum.tuflow.com/) to maximise access speeds. The TUFLOW Wikis will not be affected by the changeover. Please note that during the transition the website and the forum will experience outages. Once the transition has completed we will make an announcement on this channel. Apologies for any inconvenience during the transition and we look forward to showing you our brand new website. Should you have any queries or experience any problems after the transition, please don't hesitate to contact support@tuflow.com. Best regards The TUFLOW Team
  7. Hi Helen, Can you please send .tlf to support@tuflow.com so we have a bit more information about your model? Thank you. Kind regards, Pavlina
  8. Hi I have a model of a breach of the defences in a tidal estuary. We have set up a 2d_vshp to lower a section of the defences just prior to the tidal peak and then repair them in 18hours. Normally, I would snap a 2d_bc with the tidal levels in along the defences but this does not seem to work in this case. I’ve found tuflow has a problem when the 2d_bc and 2d_vshp are being applied to the same cells. I’ve got around it by setting back the 2d_bc into the estuary. Is this a know problem? I would prefer snapping the 2d_bc to the defences to avoid instabilities in the estuary. Thanks Helen
  9. Hi Jason, The increase in startup time might be insignificant for some models and to some extent noticeable for others depending on how the model is built. Keep in mind that this would only affect the initialisation run time for the first time when XF files are used (the default). We will consider if skipping the grids that doesn't fall within the refinement domain can be implemented for future releases. Thank you for the suggestion. Cheers, Pavlina
  10. Hi, I was trying to model evacuation routes with depth cut-off values of .1, .3, .5 & .7. I didn't specify Z values to any of the road geometry but bridges. Examining results indicate all road triggers have the same start, stop & duration readings irrespective of trigger depths. However all bridge crossings report varying start, end times & duration based on cut-off depths. Assuming roads report the same duration for all four cut-off depths due to no Z value field, I split roads layer into multi segments (same as grid cell size) and assign Z elevations to each segment to rectify this issue. In this approach, multiple route segments with the same route name were read into the model. Models produce the following error message after this modification. NoXY: ERROR 2409 - Cut off types must also match when extending route with matching name. Route Name: Test01 RD Route Type: https://wiki.tuflow.com/index.php?title=TUFLOW_Message_2409 Why am I getting this error message? I don't have any Cut_Off_Ty or Cut_Off_Va attributes filled in the GIS data layer as I am reading these values through a tgc file. I am using Tuflow 2018-03-AE version and the line layer is digitised using Multi Line Strings. Kind Regards Nilantha
  11. Hi Bonnie, Surcharging manholes are not currently supported in TUFLOW, however they are on our development list to consider for future releases. Q pit with 1d_na user defined storage might be a reasonable workaround in the meantime. Is there a storage node in your current model? Cheers, Pavlina
  12. Hi All, Does anyone have any advice on how best to model a soakpit? The soak pit is similar to a 1050mm diameter pit, 3m depth and field inlet. The soakwell has a connecting upstream 450RCP. I am currently modelling it as a Q type pit but it doesn't seem to be representing it well. Ideally it would be good if there was a surcharging manhole options so that you could see when the soak pit initially blows out. But as far as I know surcharging manhole isnt an option currently in TUFLOW. Thanks in advance!
  13. Has anyone used github to track model files? Given they are text files it seems it could be a good option for documentation and tracking file changes...
  14. The 2017 TUFLOW release notes mention that input grid extents are checked when using the "Read GRID ==" command. If the extent is outside the 2D domain the grid is skipped to reduce simulation startup. I have noticed that for quadtree models with nesting, that inputs grids are processed for each refinement level even if some grids do not fall in the refinement region. For example, a quadtree model with base 10m grid size and one 5m refinement area using DEM tiles to set Zpts. Each tile in the DEM will be processed to the 5m refinement level (GRID_TILE_X.5m.xf4) even if that tile does not fall within any part of the 5m refinement region. Does this unnecessarily increase startup times by generating xf files that aren't needed?
  15. Hi, I've just been reading through this thread and had a thought. For point 3 if the 1d_xs line is simply a reference file, what does this mean for HX boundaries snapped to the end of the 1d_xs lines? If the 1d_xs lines are for example too wide (but the referenced .csv files have the correct width) and HX lines are snapped to the 1d_xs; would water be entering the 2d domain the incorrect location? Should the HX lines be moved to the channel width represented in the .csv? Cheers Louise
  16. Hi Matthew, Well spotted. It seems the only option for grids is to output to -asc. I have added this on our development list. In the meantime, you can use asc_to_asc utility to convert created asc grids to the binary format. Cheers, Pavlina
  17. Dear GamesMaster, The tuflow_to_gis util description says it can output binary grid types, ie .flt files. But I can't get this to work (I've assumed the flag is -flt but also tried -f, -fl and -float). Can you advise on whether this feature is functioning in the 2020 build of tuflow_to_gis and if so, how to enact it? Cheers!
  18. Hi Duck The 1d_xs line should be type HW connected to HW table starting from elevation 0. The invert/bed level will be then taken from the 1d_nwk layer attribute and the elevations from HW table will be automatically risen to the invert level. Cheers, Joe
  19. Thank you Peter for the suggestion, great advice. If you or Paul still have the model with CN points that doesn't work well with HPC, please send it to support@tuflow.com and we can investigate if it should work. Cheers, Pavlina
  20. Hi Peter, Thanks for the response. I'm still not 100% certain I've got this right. I amended columns A+B to add the ground elevation so I am using the Height and Width in columns D+E (read in a table as XZ). Is this right? Couple things I'm not sure about this though - wouldn't this shape now not match what I am trying to achieve as it is arch shaped rather than elliptical? Also when I ran the model the 1D-ta_tables check file appears as though it has used my Z column (column D in the Rev3 spreadsheet) as the width of the culvert. Is this right? The culvert should be 5.1m height from a bed level of 2.455 and the widest point of the culvert is 8.5m. Thanks elliptical_culvert_Rev3.xlsx RD_Model_Build_04_1d_ta_tables_check.csv
  21. 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
  22. Hi, I have a large elliptical shaped culvert, what is the best way to model the shape (spreadsheet attached shows the shape I want to achieve)? The widest point is about a third of the way up the culvert so if I try using the values in the spreadsheet in a csv table I will get the ascending order values error. Is there anyway around this while maintaining the shape? Thanks elliptical_culvert.xlsx
  23. Excellent, well done! Thanks for following up with the feedback, that's good to know.
  24. My thing was this. Bravo! Errors be gone now (note to others, even though they were errors, the model ran, just ignoring the boundary) Many thanks to Peter
  25. 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
  26. It's got to be worth a try! off I go... Thanks!
  27. 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.
  1. Load more activity
×
×
  • Create New...