All Activity

This stream auto-updates   

  1. Last week
  2. Q: "What are some suggestions for checking direct rainfall boundaries have been applied to my model correctly? For example, I wanted to verify that the correct rainfall depth of 90 mm was applied across the model. I divided the “total volume in” by the total area of active cells, and came up with only 72mm. I cannot track how the histogram relates to the hyetograph." A: There are a number of things that can be looked at, depending on the type of rainfall boundary being applied, and if rainfall losses are applied to the model. Rainfall losses applied through the Materials Definition file (.tmf or .csv format) removes the loss depth from the rainfall before it is applied as a boundary on the 2D cells. Soil infiltration losses however remove water from wet cells, after the rainfall source has been applied. Is the model health (mass balance, negative depths etc) acceptable? If using TUFLOW classic (as opposed to TUFLOW GPU) direct rainfall models should be run with double precision and the recommendation is to lower the cell wet / dry depth to 0.2mm. For 2d_rf boundaries, the rainfall time-series data must be in mm versus hours, and is converted to a hydrograph to smooth the transition from one rainfall period to another (the converted hydrograph is reported in the .tlf log file for cross-checking). After subtraction of rainfall losses, this is applied to the model cells as a source volume. The Map Output Data Types RFR and RFC (see Table 9-10 of the 2016-03-AE TUFLOW Manual) may be used to view the rainfall rate (mm/hr) and cumulative rainfall (mm) over time respectively. As these are model outputs, they are inclusive of the rainfall losses and any adjustments made in the BC Database (eg. multiplication factors/time shift). For rainfall grids generated from point rainfall data with a Rainfall Control File .trfc, the rainfall control file is processed during model initialisation and a series of rainfall grids are output, which are then used by the simulation to vary the rainfall over the 2D domain(s). This feature may also be useful simply to generate the series of rainfall grids for other purposes or display. The rainfall grids are pre-processed to reduce memory usage whilst TUFLOW is running. Whilst there isn’t a specific check file for the rainfall distribution when using generated rainfall grids, another advantage of the pre-processing of rainfall grids is that they can be interrogated prior to the end of the simulation to allow for checks. Note that the generated rainfall grids are inclusive of adjustments made in the BC Database (e.g. multiplication factors used for climate change) and of adjustment factors in the input GIS layer’s attributes, but because they are an input to the model, they are not inclusive of rainfall losses that may be specified in a materials file. Again, the Map Output Data Types RFR or RFC can be specified, these are inclusive of the rainfall losses, however these results are output as the simulation progresses. To confirm the rainfall losses applied across the model, use the grd_check file with the Materials Definition file .tmf.
  3. New Price List – First Update in 6 Years! We’re finally updating our price list, and offering new licensing options, for the first time since 2011! Note: the new prices come into effect on May 31st, 2017, but any new sales quotes issued prior to this time using the existing price list will be honoured within the 30-day expiry date of the quote. The 2017/2018 annual software upgrades and support fees will be based on the new price lists. Links to the new price lists are provided at the end of this post. The main points and changes are: Introductory Perpetual Licences (Local 1 to 4 and Network 1 to 3) remain unchanged for our base AUD rate. The monthly rental rate of 10%, and the annual software upgrades and support fee rate of 15%, remain unchanged. Australian rates are now listed including GST. Previously, the rates were excluding GST. GBP, USD and EUR prices better reflect current exchange rates relative to the AUD. Perpetual Licence prices have increased by up to 10% (depending on the currency) for Local 8 and greater and Network 5 and greater. The Local Licence multiple purchase discount has been reduced from 15% and 30%, to 10% and 20%, for the 2nd, 3rd, … licences to the same Licensee. The GPU Hardware Module (formerly GPU 2D Solver Module) is now priced in the same manner as other modules, i.e. as a percentage of the TUFLOW Engine price. For example, a Local 4 GPU licence is now simply 50% of the Local 4 TUFLOW price. Previously, GPU Licences had their own (somewhat confusing!) pricing structure. Of note is the new approach translates to lower prices for larger local GPU module orders. Yearly Subscription licences are now available. A Yearly Subscription is 40% of the Perpetual Licence price plus one year’s annual software upgrades and support fee. This option is also potentially very attractive to Licensees considering renting for 4 months or longer. Software Locks in addition to the existing Hardware (Dongle) Locks will be available with the 2017 release and potentially updates to past releases. Rental locks no longer need to be returned, but are covered by a one-off nominal purchase/admin fee. The Lock may be retained by the Licensee indefinitely for future rentals or purchases. The 50% of rental costs discount on Perpetual Licences is being discontinued (we will honour this discount for rentals invoiced prior to May 31st, 2017 if the rented licences are purchased at the end of the rental period). A new Cloud Simulation Service is now available. The BMT WBM Cloud Simulation Service is a bespoke service quoted at a per hour rate, which varies depending on the hardware, priority and order size. This service is suited to short term bulk simulations. For example, Monte Carlo simulations, where large numbers of simulations are to be completed within a short timeframe. TUFLOW Classic 2017 Release and the New HPC 2D Solver The new HPC 2D Solver (formerly referred to as TUFLOW GPU) is now included, at no extra cost, in the TUFLOW 2017 release for CPU processors. The 2017 release includes: TUFLOW Classic’s well-established 2D ADI Implicit Solver on CPU (single-threaded). TUFLOW’s new HPC (Heavily Parallelised Compute) 2D Explicit FV Solver, with 1st and 2nd Order options, on CPU (multi-threaded). Full 1D/2D linking and all 1D functionality available via the new HPC solver running on CPU or GPU devices. HPC’s 2nd Order Finite Volume solver offers similar performance to the world leading, proven and tried, TUFLOW Classic 2D Solver, with the addition of being unconditionally stable, mass conserving and benefiting from FV shock capturing. The HPC 1st Order solver was previously branded as TUFLOW GPU, but has now been further enhanced. Backward compatibility to the original TUFLOW GPU 1st Order Solver to be provided for legacy models. The GPU Solver Module is replaced by the GPU Hardware Module that can reduce HPC run-times by one or two orders of magnitude by allowing simulations to run across one or more GPU devices, significantly reducing TUFLOW licensing costs. The HPC Solver is also multi-threaded (parallelised) for CPUs. Links to New Price Lists Fixed Grid Modelling: TUFLOW Classic and HPC (formerly TUFLOW GPU) Solvers AUD: TUFLOW_Fixed_Grid_Modelling_Price_List_AUD.pdf EUR: TUFLOW_Fixed_Grid_Modelling_Price_List_EUR.pdf GBP: TUFLOW_Fixed_Grid_Modelling_Price_List_GBP.pdf USD: TUFLOW_Fixed_Grid_Modelling_Price_List_USD.pdf Flexible Mesh Modelling: TUFLOW FV AUD: TUFLOW_Flexible_Mesh_Modelling_Price_List_AUD.pdf EUR: TUFLOW_Flexible_Mesh_Modelling_Price_List_EUR.pdf GBP: TUFLOW_Flexible_Mesh_Modelling_Price_List_GBP.pdf USD: TUFLOW_Flexible_Mesh_Modelling_Price_List_USD.pdf miTools: All Currencies: miTools_Price_List_ALL.pdf Please don’t hesitate to contact sales@tuflow.com should you have any queries. Best Regards Bill Syme BMT WBM Software Business Manager
  4. Earlier
  5. LiDAR and most other topographic data sets are discrete point measurements of elevation which are then interpolated to produce an estimate of elevation across a wider area. To use the channel bathymetry you will need to produce an interpolation of the channel bathymetry and overlay this on the DTM. If you create your interpolations as grids outside of TUFLOW, you can overlay the channel bathymetry using judicious use of the Read GRID commands in your tgc file. The last elevation assigned to a Z-point will always take precendence. If you were to first assign a value using the LiDAR data and then the bathymetry data you will have achieved what you desire.There are traps for new players with this approach of course. For example will your channel data and DTM match nicely at the borders of your channel dataset? If not you might like to use the MIN option of the Read GRID Zpts command to ensure that the Z-points only take on the value of the channel dataset where your channel is lower than the DTM. Alternatively, you can use the TUFLOW command Create TIN Zpts to create a TIN of your channel data which is then applied to the existing Zpt values. There is even an example of using this command in the TUFLOW manual which you could adapt to your situation.
  6. Hi Francis, Sorry for the late reply. My notifications have not been working on the forum. Please find attached the document requested. Hope it all makes sense. Regards, Paul. www.HydraLinc.com Catchment Slope Calculation - Vertical Mapper.pdf
  7. All If I wanted to model a large river channel and floodplain using 2D only, how would people go about including the river channel bathymetry into the DTM? LiDAR will provide the terrain data, but will poorly-define the river channel itself. Is there a way to use channel cross section data to modify the base DTM to reflect the surveyed channel? We have regular channel cross-sections, and would like to use this data to 'carve' a more detailed channel through the DTM. The method will need to account for any meanders etc... Are there clever ways to do this in Arc/MapInfo/QGIS? Any pointers gratefully received :-)
  8. We've run into a bug in convert_to_ts1 (2012-06-AA) utility. This bug is identical to the one outline in this thread from 2007: As explained in the old thread, when converting to a ts1 file, a value is randomly added to end of the hydrograph when using the e0 and * wildcard. We were using the following batch file command: convert_to_ts1.exe -wbnm -ts1 -b -e0 *Meta.out After some testing we've found the bug only occurs for us when running the utility on our external NAS drives. It is also noted that the value added to the end of the hydrograph is different depending on which NAS it is run on! The error does not appear to be occurring when running the utility on local drives of fast server storage (SAN).
  9. Hi, Just wondering if anyone has overcome the issue of large file sizes in Crayfish? I've got a 4.5 Gb file that caused crayfish to crash. Appreciate any help. Cheers Scott
  10. Hi, The configuration you described would be used where you have a 2d_bc layer which has elements defined for the boundary conditions, as well as for defining the active code. If you look in the layer that both commands are referencing, is there a polygon with a "CD" type attribute and a value in the f attribute? This indicates the polygon is for defining the active code. The "Read MI BC==" command in the TBC only reads the boundary condition elements. The "Read MI Code BC ==" command in the TGC only reads the code element (specifically from a 2d_bc layer). So if you have updated elements of both boundary conditions and code in the one file, but only updated the reference in your TGC, then the new code will be applied, but not any changes to boundary conditions that may be included in the same file. If your 2d_bc_code layer only contained code information, then the command in the TBC will essentially not be doing anything, because there wouldn't be any boundary condition information to read. An alternative configuration is to separate the two element types so that you have a 2d_bc layer that contains only boundary condition information, and then make a 2d_code layer (different to 2d_bc) that contains only the code information. Note that the 2d_code layer must then be used in conjunction with the alternative "Read MI Code ==" command. Please review Section 6.7, page C-7 & C-8, and the "CD" Type under Table 7.4 of the 2016-03-AE TUFLOW Manual. Let us know if you need further clarification. -Teegan
  11. Hi Helen, What TUFLOW Build version are you using, and is it a GPU run? -Teegan
  12. Hi, I've been tweaking a model over the last few months and I've just realised I have a discrepancy regarding the 2d_bc_code layer. I updated this layer to widen the model domain in a specific section of the model to improve our understanding of overland flow paths, however I have recently realised that the 2d_bc_code layer is referenced in both the .tgc and .tbc model files. I am now in the scenario of having the updated 2d_bc_code layer referenced in the .tgc file and the older superseded file referenced in the .tbc file. From the model output, Tuflow seems to be using the updated 2d_bc_code layer (so the command in the .tgc file), which I guess is why I never picked up on this oversight until now. But that raises a few questions: Is the above assumption (that the model seems to prioritise the command in the .tgc file) correct? Why are no errors raised when two different 2d_bc_code layers are referenced in the same model? Does the 'Read MI BC ==' command need to be stated in both .tgc and .tbc files and if so, why? The only variation I can find is in the .tgc file, the command is 'Read MI Code BC ==', however in the .tbc file the command is as above in the last bullet point. Is this a relic from a previous version? As above, the model output seems sensible in conjunction with the updated 2d_bc_code layer, so I am unsure of the purpose/authority of the command in the .tbc file. Any clarification would be greatly appreciated. Thanks.
  13. There are limited places left for the March Introductory Training in London, UK! If you have any questions or would like to register, please feel free to message me or email training@tuflow.com.
  14. Hi I'm trying to stop a simulation (so it writes the maximums) using ctrl c. The dialog box displays and asks me whether I would like to stop the simulation I press stop and the model stops running but the TUFLOW window remains open, it does stop at that timestep but does not write maximums or close? Do you know why that would be? Thanks Helen
  15. Sorry Phil didn't get a prompt for your reply!! Yes it was converting over database to Tuflow format, ive got a workaround now just through excel with a couple of formulas, but just out of curiosity is there an easier (read faster) way?
  16. I'm reviewing a 1D-2D model using XP2D and the final CME% is less than 3%, but the peak CME% is higher than 3% (there are several models with different return periods and the errors range from 4-9%). I'm reading that a healthy model should have both peak and final CME% less than 3% - is that true in all cases? If so, I've having trouble figuring out how to reduce the peak CME. The model simulates runoff at an airport. It uses direct rainfall and combines 2D surface flow with 1D storm drains. It uses 15-ft cells and a timestep of 0.6 seconds. The 2D domain has an inflow boundary on one side and a normal depth boundary condition around most of the rest of the model boundary to allow 2D flow to drain either offsite or into the ocean. The 1D pipes outfall into the ocean and have been given a head boundary equal to MHHW level. I've attached the MB files that were written out for one of the models. Any thoughts on what might be causing the high peak CME% and how we might resolve it? Thanks! Clark data_MB.csv data_MB2D.csv
  17. Hi. I'm trying to model a water main burst on a 36" trunk main, currently I've used an "ST" boundary type and a 1m model grid. The problem I'm having is that I don't think TUFLOW is taking into consideration and velocity the water is coming out of the ground and therefore the localized depth, is there a more suitable boundary type? Cheers
  18. Hi Francis, We'll likely need more information to be able to help out with your above issue. What TUFLOW Release Build are you using? A CPU or GPU simulation? Is there an initial water level set at the tailwater boundary? Could you please send an email through to support@tuflow.com with the above info and a copy of your TLF log file to begin with. We will probably need to look at a copy of your model or some input files, but we'll take a look at your TLF first.
  19. Hi, We have noticed that when modelling extreme depth tailwater conditions (i.e. depth > 15 m), we are getting oscillations across the floodplain. Review of the PO.csv file reveals that the flood height at the tailwater boundary is fluctuating below a fixed tailwater level. We don't understand how the water level can drop below the fixed global level. We have tried adopting a boundary viscosity factor of 4 in lieu of the default 1, and it had no measurable effect. We have also tried reducing the timestep - which did not change the results. We mapped the courant number for a problem timestep, and the maximum value was 4.9 - which would appear to be okay. We would appreciate some advice on how to minimise this oscillation. Is this a known issue when modelling extreme depths? We have had the same issue with models elsewhere in the same floodplain when modelling deep regional tailwater conditions. Regards, Francis
  20. We are pleased to announce a series of Introductory TUFLOW Training workshops to be held in our central London, UK office. The course is ideal for users who are new to the software and will be run in a small group setting, providing maximum benefit to all attendees. Dates announced so far are: 21st – 22nd March 2017 19th – 20th September 2017 For further information or to register, please visit the dedicated page on the TUFLOW website: http://www.tuflow.com/Training.aspx?ubt
  21. Q: When using a Global Rainfall boundary (via the "Global Rainfall BC == " command) do the spatially varying losses via the materials file apply, or only the Global Rainfall losses ("Global Rainfall Continuing Loss == " and "Global Rainfall Initial Loss == " commands)? A: When using a Global Rainfall BC the approach is more simplistic than the one than used for a 2d_rf layer. No memory is allocated for spatial losses and the global rainfall losses are the only ones that apply. These global losses are subtracted from the rainfall before the simulation and each cell gets the same rainfall applied. Therefore: The global rainfall losses commands only apply to global rainfall boundaries and not to 2d_rf polygons. The material losses do not apply to global rainfall boundaries. We will issue an updated 2016-03-AE manual in the coming weeks and this behaviour has been clarified. For future versions we will likely; add some warnings if either of the above configurations is specified, we will also look at supporting spatial losses for global rainfall, but will likely make a new command for doing so, to keep the existing behaviour.
  22. Hi All, A fix for the above issue has been included in the latest TUFLOW update (Build 2016-03-AE). Please see Item 167 of the release notes. Cheers, Teegan
  23. We are pleased to announce an update to the 2016-03 TUFLOW Release (Build 2016-03-AE) is now available. It is recommended that all users update to this build. The changes consist of minor enhancements and bug fixes - please see Item 153 onwards at the end of the release notes for details. Links:Downloads Page2016-03 Release NotesLatest 2016-03 Manual (*.pdf) (Please note: A manual update commensurate with 2016-03-AE is to be uploaded in the coming week.) Any queries or issues, please don't hesitate to email support@tuflow.com. Best Regards TUFLOW Team
  24. Hi Sam Sorry, we're not quite sure where that line came from! Most of the functionality we've been using for large scale Monte Carlo simulations stepping of a single .tcf file were already built in (for example If Scenarios/Events, etc). The line has been removed from the release notes and I'll edit the above post. And yes, Set IWL == Auto was extremely useful for running 11,340 MC events, each with a different starting ocean level! Thanks for alerting us to the above. Cheers Bill
  25. Thanks Phil, that is fantastic. I had not even noticed that output before. Cheers!
  26. Hi Michael, If you have grid output directly from TUFLOW (in either .asc, or .flt format) and you have the maximums on (which is the default), this should already be output directly from TUFLOW. In your grids folder you should see a number of maximum grids: _h_Max - the maximum water levels _V_Max - the maximum velocities _TMax_h - the time of maximum water level _TMax_V - the time of maximum velocity. Hope that helps, get back to use if you have any questions. Phil
  27. Hi, Is it possible to obtain a grid of the time to peak/time of peak? I can see there are options for Time Output Cutoff (TUFLOW output) and time of inundation / time of increase (RES to RES), along with the usual PO outputs. We are looking at producing a grid that would display the time to peak so you can track the movement of a flood wave through the model domain. Is it possible to obtain this output from TUFLOW or during post-processing? Cheers, Michael
  1. Load more activity