Jump to content
TUFLOW Forum

All Activity

This stream auto-updates     

  1. Earlier
  2. the answer appears to be that initial losses are indeed reset if you start a model with a restart file, so using a restart file to avoid running the preburst period results in double counting it
  3. Hi all are initial losses reset if I start a model with a restart file? I'm trying to avoid running the preburst period for each temporal pattern, as they only change with duration, so I'm using restart files, but obviously if the inital loss resets that would defeat the purpose thanks Sam
  4. Hi, The FEH rainfall-runoff model does consider infiltration losses both in the development of runoff (direct/total runoff and baseflow), as in the case of the upstream 2d_bc boundary, and the development of net rainfall, as in the case of the 2d_rf boundary. Therefore, if you're using runoff or net rainfall from FEH/ReFH and assuming your FEH/ReFH model is calibrated appropriately, you shouldn't have to also apply additional infiltration. To do risks double-counting the losses. Duncan
  5. Hi Ryan, In order to be able to access the TUFLOW licence server, you will need to have setup you machine to access this, as per this instructions on the wiki: https://wiki.tuflow.com/index.php?title=Wibu_Dongles#Configuring_Access_to_Network_Licence As is sounds like you are not in the office, you will likely need to be on a VPN to tunnel into your work network. Regards Phil
  6. HI all, I am trying to Run TUFLOW from Indonesia accessing Councils Server for the License... However I get this error ?? Initialising TUFLOW Dongle Settings... Looking for "C:\BMT_WBM\TUFLOW_Dongle_Settings.dcf"...not found. "C:\BMT_WBM\TUFLOW_Dongle_Settings.dcf" does not exist - default settings assigned. Simulations Log Folder == C:\BMT_WBM\log WIBU Retry Time == 60 WIBU Retry Count == 0 WIBU Dongles Only == OFF ! If set to ON, searches for WIBU dongles only. Searching for a WIBU (Metal) Dongle... TUFLOW Engine Server could not be found. Searching for a SMS WIBU (Metal) Dongle... TUFLOW Engine Server could not be found. Halcrow dongle service is not running. NOTE - 64-bit TUFLOW requires a maintained 64-bit compatible dongle. Closing any unclosed GIS layers... Any Clues how I can resolve this ??? Regards Rudy
  7. AdrianMQ

    Infiltration

    Hi everyone, I am currently carrying out a surface water hydraulic modelling, but due to the huge size of the upstream catchment, I am forced to use two inflow boundary conditions (i.e. 2d_bc QT and 2d_rf). In order to avoid modelling the entire catchment, I established the 2d_bc (QT) associated with the upstream catchment hydrographs based on the FEH method (from Flood Modeller) and catchment descriptors from FEH website (https://fehweb.ceh.ac.uk/). On the other hand, a second boundary condition (2d_rf) has been established for rainfall hyetographs for my ‘active’ catchment (2d_code). These hyetographs were created using the ReFH method (also from Flood Modeller), which calculates the ‘loss model’ and then extracts the ‘net rainfall’. However, in order to consider infiltration within the model, the ‘Standard Percentage of Runoff’ (SPR) of the FEH catchment descriptors would consider the infiltration for both the upstream catchment hydrographs and the hyetographs within the 2d_code area, is that correct? My questions are: Would the ‘Standard Percentage of Runoff’ (SPR) of the FEH catchment descriptors would be enough to consider the infiltration in the upstream catchment hydrographs? Regarding 2d_rf, does the ‘loss model’ from ReFH method already consider the infiltration? Or should I apply an additional method? Many thanks
  8. Hi everyone, I am dealing with a similar situation. I am currently carrying out a surface water hydraulic modelling, but due to the huge size of the upstream catchment, I am forced to use two inflow boundary conditions (i.e. 2d_bc QT and 2d_rf). In order to avoid modelling the entire catchment, I established the 2d_bc (QT) associated with the upstream catchment hydrographs based on the FEH method (from Flood Modeller) and catchment descriptors from FEH website (https://fehweb.ceh.ac.uk/). On the other hand, a second boundary condition (2d_rf) has been established for rainfall hyetographs for my ‘active’ catchment (2d_code). These hyetographs were created using the ReFH method (also from Flood Modeller), which calculates the ‘loss model’ and then extracts the ‘net rainfall’. However, in order to consider infiltration within the model, the ‘Standard Percentage of Runoff’ (SPR) of the FEH catchment descriptors would consider the infiltration for both the upstream catchment hydrographs and the hyetographs within the 2d_code area, is that correct? My questions are: Would the ‘Standard Percentage of Runoff’ (SPR) of the FEH catchment descriptors would be enough to consider the infiltration in the upstream catchment hydrographs? Regarding 2d_rf, does the ‘loss model’ from ReFH method already consider the infiltration? Or should I apply an additional method? Many thanks
  9. Hi everyone I am carrying out a surface water hydraulic modelling using TUFLOW. I have established a 2d_bc (HQ downstream condition of 0.06), along the downstream side of the catchment. However, I tried to establish a second downstream boundary condition via a drainage pipe using a second 2d_bc (SX) that collects runoff, conveys this via a 1d_nwk and then leaves the site via a 1d_bc (QT), without success, since the model does not indicate that flood water leaves the site via the drainage pipe. I mean, I would like that flood water to leave the site through the 2D downstream condition (i.e. to the downstream land) and through a 225mm drainage pipe (i.e. to the drainage sewers). See below a screenshot showing the model and attached the tlf file. How could I fix this problem? Any help would be appreciated thanks
  10. Hi Tom, asc_to_asc utility can be used on any grids regardless of which software produced them as long as the grids dimensions are matching (have identical headers when you open them in a text editor) and number of elements are matching respectively. You might need to do some further GIS post-processing to achieve that........ or use TUFLOW from the start Pavlina
  11. Hi, might be a bit cheeky asking an ICM related question here but I was hoping to use the asc to asc utility When I have a number of storm duration events results for TUFLOW I would use asc to asc to find the maximum water level between each of these durations. I have some ICM results that I have converted from shapefile to ASCII hoping to use asc to asc for finding the critical duration as I would for TUFLOW but I get two erros; 1. ERROR - number of rows for input grids do not match. 2. ERROR - dimensions of grids do not match Is it possible to use asc to asc in this way for converted ICM results and if so how can I fix these errors? Many thanks for any help you can provide.
  12. Dear Mpolak, It appears that your license may not have been coded with threads. As of 2019 each TUFLOW FV license comes with 4 threads as default. The term 'threads' refers to the degree of parallelism a given simulation can be run on (more on this here:https://fvwiki.tuflow.com/index.php?title=A_Model_Runs_Slow#Parallel_Processing). As you have a local 8 of TUFLOW FV you should also have access to 32 threads (8x4=32 threads). So we can take a closer look at your license could you please create a cmDust file (follow the instructions on this link: https://fvwiki.tuflow.com/index.php?title=WIBU_create_cmDust) and send through the resulting to support@tuflow.com. We look forward to getting you back up and running as soon as possible. Kind regards, Mitch.
  13. Hello, We have a standalone license dongle for TUFLOW that will not work on new computer. We are replacing desktop and the hardware dongle will allow the software to run fine on the existing machine. On the replacement, we installed codemeter but then after plugging the dongle into the new machine and trying to run the software we get the attached screen shot error. TUFLOW FV Threads (16) Not licensed or no local licenses free. ERROR: Requested threads licenses not found on available dongle/s.
  14. Hi Joe, Thanks for the response. I ended up just manually setting culvert inverts in QGIS. Cheers, Hamish
  15. Hi Hamish, As far as im aware there is no way to set invert levels automatically to a stand alone culvert (assuming this isnt part of a wider network?). An invert level of -99999 will work providing the pipe is part of a wider network where you do have upstream and downstream inverts defined at either end of the wider system, the -99999 value will then interpolate inverts linearly between the defined inverts. I would recommend either using the value tool over the raster in QGIS to gain ground levels at the desired points (if survey data is not available). Another option would be to run the model without culverts to gain the grid check file, you can then better select your 2d_bc boundary cells and also interrogate the elevation of the cell. I should note that a Z flag can be used in the 2d_bc SX (line or point) to lower the linking cells to that of the defined invert elevations. If a Z flag is used its important to assess the messages layer which will note the change in elevation between in original cell elevation to the lowered value from the Z flag and invert level of the culvert. This should be a 'large' value, the risk is you could get cells that are greatly lowered which will impede flow and possibly case instabilities. Cheers, Joe
  16. Is there a way to automatically set the US_Invert and DS_Invert of a circular culvert in a 1d_nwk file to the ground level? I tried setting both to -99999 but this returned error 2050. Thanks
  17. Hi, I'd like to second Ruth's request. Is anyone aware of any updated or alternate sources for UK specific infiltration parameters for any of the methods available in TUFLOW? Thanks Michael
  18. 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
  19. 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
  20. 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.
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  1. Load more activity
×
×
  • Create New...