All Activity

This stream auto-updates   

  1. Last week
  2. Earlier
  3. 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
  4. Hi Helen, What TUFLOW Build version are you using, and is it a GPU run? -Teegan
  5. 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.
  6. 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
  7. 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
  8. 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?
  9. 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
  10. 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
  11. 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 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.
  12. 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
  13. 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:
  14. 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.
  15. 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
  16. 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 Best Regards TUFLOW Team
  17. 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
  18. Thanks Phil, that is fantastic. I had not even noticed that output before. Cheers!
  19. 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
  20. 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
  21. Thank you for the further information. The above issue has turned out to not be isolated to Override files and can in fact occur in any control file. Currently, if a scenario (or event) variable occurs in any line, there must be a value specified for it, regardless of whether or not that line occurs inside an active scenario/event block. Your use of something like -s2 DUMMY (or even just "_") as per above description is a good work around for the time being. Assigning a “dummy” name will be required for all scenarios/events which are not intended to be active, but which are referenced as variables anywhere in the control files. This had been added to TUFLOW’s development list.
  22. Hi Mitch, Apologies for the delay in replying, I've only just seen your response. I'll send an email shortly. ds.
  23. Hi Bill any more details about this? I flicked through the manual & release notes but the only things I thought this could be a reference to was the Set Variable command or Set IWL == Auto cheers Sam
  24. Hi Tom. I'm just noticing you say that this is concentrated along your QT boundary, not the HQ. Is that correct? On the basis it is... I assume that a QT has to establish its own stage discharge relationship, based on the underlying cells (in the same way as an HQ does) and if you are putting 'too much' flow into the model then that stage/discharge relationship could be exceeded and TUFLOW won't know what to do. I'd guess there's no equivalent 'd' value here, so your best bet would be to extend your QT boundary further. If "QT" in your post was just a slip of the finger, then hopefully the Riders of Rohan's suggestions will see you right. Please let us know how you get on, PHA.
  25. Hi Bill, Further to your comment above regarding the specification of a different Q pit curve for a reverse flow; is this option available for the current TUFLOW build? Cheers Nick
  26. Hi Teegan, I did some further testing, the order of the scenarios is not important. If any of the variables used in the override file are not specified an error will occur; even if that variable is contained within commands that aren't intended to be used by the current simulation (i.e. within an If Scenario block for a different Scenario). My _TUFLOW_override.tcf looks something like this: If Scenario == M01 Output Folder == C:\TUFLOW\<<~s1~>>_results\<<~s2~>>\<<~s2~>>_<<~e1~>>_<<~e2~>> Else If Scenario == M02 Output Folder == C:\TUFLOW\<<~s1~>>_results\<<~s1~>>_<<~e1~>>_<<~e2~>> Else Output Folder == C:\TUFLOW\EXG_results\EXG_<<~e1~>>_<<~e2~>> End If If I try to execute a single simulation from the command prompt with only -s1 M02 set, I receive the following output: Trying to open (I) file T:\TUFLOW model\runs\_TUFLOW_OVERRIDE.tcf...OK. File Unit: 902 skipping scenario "M01" NoXY: ERROR 0015 - Variable "~S2~" not defined. Line: Output Folder == C:\TUFLOW\M02_results\<<~s2~>>\<<~s2~>>_<<~e1~>>_<<~e2~>> As you can see TUFLOW states ~s2~ is not defined and outputs the path contained within the M01 If statement. If I execute a simluation with -s1 M02 -s2 DUMMY then the simulation will launch correctly and TUFLOW will not produce an error.
  27. Hi, Generally TUFLOW's Override Files are intended for the more simple commands such as output drive, number of GPU, check files etc. We might need a bit more information to understand what you are trying to do. Are you able to please post what your Override File looks like? I can then follow up with TUFLOW's developers to check specifically if what you are trying to do should be possible or not. I believe that calling scenario wildcards should still be allowed e.g. Output Folder == results\<<~s1~>>. Cheers, Teegan
  1. Load more activity