Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. 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
  3. 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
  4. 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
  5. Earlier
  6. 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!
  7. 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...
  8. 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?
  9. 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
  10. 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
  11. 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!
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. Excellent, well done! Thanks for following up with the feedback, that's good to know.
  18. 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
  19. 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
  20. It's got to be worth a try! off I go... Thanks!
  21. 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.
  22. Full message: ERROR 2066 - Weighting factors do not add up to 1.0 at connections to 1D Nodes Unidentified and Unidentified This is from a HPC model that uses Quadtree. The set up is that which I have used in a classic model to have a spatially and temporally varying boundary at the edge of a 2D domain (the bank of another watercourse, in this case). So there is a HX line and CN points in a 2D bc layer, a 1D network of nodes and a 1D layer of HT nodes. The set up seems to work when the model is switched to Classic. The messages are accompanied by a single "ERROR 2061 - Could not find a CN connection snapped to the end of HX line. HX Name =" at one end of the HX line. The 2066 error messages don't have a geographical location and there are 24 of them (which is similar to the number of cells under the boundary). The 2061 message points to one end of the HX line. I've tried a few things - including ensuring that each node on the boundary is within a cell that is selected in the BCC check file and applying a Quadtree Nesting Polygon along the boundary to ensure a consistent cell size is present under the boundary. I've also reduced the size of the boundary to a simpler, two node HX line with the same result. First question: is this kind of boundary possible in HPC? If it is, are there any tips on how to make it work?!
  23. 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.
  24. Hi Sam, If you were using just HPC with a fixed grid then i would agree with your above reasons - basically you want to select a grid size to accurately represent the size of the channels you are concerned about and hydraulically significant structures - i.e. those in your areas of interest and all those that route significant flow to and out of said areas. The graph in question in the release notes, you can see that with QPC being used in higher resolution you get a significant increase in routed flow compared to a lower res. In which case when considering grid size of course the higher level of detail the less artificial loss in channels (caused by saw-tooth effects) and less chance of course cells 'trapping water'. Of course when thinking about grid size another limiting factor is the results size and needed memory to run the simulation. The use of QPC allows the user to specify that differing levels of detail in specific areas while having courser elsewhere. The graph really highlights the power of using both QPC and SGS to take advantage of the sub grid elevations to assist in routing flow. Cheers, Joe
  25. Hi TUFLOW people ๐Ÿ™‚ suddenly I am unsure of something as basic as what grid size to select! Looking at the first chart in section 3.2.1 of the release notes, I'm left wondering whether the seeming lack of impact of grid size on results is limited to Quadtree users or whether the results would be similar for standard HPC users. Normally I'd try to select a grid size so that channels & bridges are represented by at least 5 grid cells, but if I'm dealing with a relatively wide floodplain that's a bit demanding. No doubt the usual rule of "you should satisfy yourself that the results are reasonable" applies, but do you have any experiences you can share in that regard?
  26. Thanks Joe, yes we're using HPC. We have workarounds (with a a greater number of smaller variable z-shapes), but it would be worth adding overlapping variable z-shapes to the "wish list" as that could be a more elegant solution.
  27. Hi Colin, As it currently stands overlapping vzsh are not supported, running tests you will get the outcome as you have found that the 'last read in' vzsh takes precedent and is applied and others ignored so to speak. If you are using classic there may be an option of interest to you using the VG option in a 2d_bc layer. This effectively has been replaced now for the vzsh option as itโ€™s a simpler approach. However, the VG type bc layer allows you to apply change in elevation via a time-series specified within your bc_dbase. This is quite a legacy feature so you will have to refer to previous manuals, there is also a short feed here: https://www.tuflow.com/forum/index.php?/topic/162-variable-geometry-modelling-posted-pre-2007/ If you are using HPC this option unfortunately isnโ€™t available so your options are limited I am sorry to say. I will log your query to our developers however and this will be on a list for future releases. Cheers, Joe
  1. Load more activity
  • Create New...