TUFLOW Forum

tuflow support

142

2. Upcoming TUFLOW Training (AU, NZ, UK, USA) and Conferences

TUFLOW 2017 – Additional Australian Introductory and Advanced Training Sessions - Filling Fast!!! Hi All, The 2017 version of TUFLOW has some of the most exciting new computational features for several years. Following the sell-out of our mid-year training and workshop days we will be re-visiting Brisbane, Sydney and Melbourne in late November and Early December showcasing the new features of TUFLOW and offering ‘hands on’ introductory and advanced training sessions. Please note that our Melbourne Introductory training day is now FULL. Other sessions are also filling up quickly but there’s still time to get involved. For more information check out our flyer or email training@tuflow.com. https://www.tuflow.com/Download/Training/L.TPS000.0_2017_TUFLOW_Extra_Sessions.pdf Cheers, Mitch.
3. Plot Output flow line along a HX 1D/2D boundary

Q: I want to output the flow between my 1D channel and the adjacent 2D overbank area. Will drawing a Plot Output line exactly along the 1D/2D HX boundary line provide the correct flow information? A: If you draw the Plot Output (PO) line directly on the HX line, the output may not include some of the flow that is crossing the boundary. This is because the HX line selects an entire row of cells, where one side is “active” in the 2D domain, and the other side is “inactive” in the 1D domain. The "Q_" type PO line on the other hand will select a polyline that goes along cell edges (see Figure 9-2 of the 2016-03-AE TUFLOW Manual), and there is the potential that it will select one of the sides of the HX cell where it is inactive for the 2D domain. This is demonstrated in the image below where a PO line (blue) exactly overlaps an HX boundary. The HX boundary would select entire cells (pink), where one side is inactive in the 2D domain (marked "x"). The "Q_" type PO line would select the cell sides (dashed black line). You can see that here are some locations where the PO line is selecting cell sides that aren’t active (highlighted yellow). Try digitising the PO line adacent to the HX boundary, just into the 2D domain. This should avoid selecting these inactive cell sides. Use the _TS.mif or _TS_L.shp results files to confirm which cell sides have been selected by your PO line.
4. Global Rainfall Boundary

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.

Hi dsheehy, Out of interest, how big are the result files you're trying to open up? We think Crayfish is a great product and are certainly interested to explore options to help out the Lutra team. At the moment we haven't planned on expanding TuPlot to read in 2D results, mainly because Crayfish has proven itself an excellent plugin for these purposes. Can you send us an email @ support@tuflow.com and we'll get in touch to discuss further. Cheers, Mitch.
6. Decimal Values in Hazard Outputs

Question: Why can I see decimal values in my hazard results? How should these values be categorised? Answer: The hazard results in TUFLOW will be output as integer values in the .xmdf and .dat files at the cell corners. However, when exporting to grid (in either .flt, asc or .nc format), the raster output is north south aligned and a regular grid (but your TUFLOW model may be rotated, may have 1D triangles and may have multiple domains). Therefore, the TUFLOW results are interpolated onto a north-south grid when directly writing grids from TUFLOW or when using the TUFLOW_to_GIS utility. Since TUFLOW build 2013-12-AD when directly writing a gridded output (e.g. .asc, .flt, .nc) the hazard outputs (except for z0, which is the velocity - depth product) are always output as an integer value, i.e. you only get a value 1,2,3 or 4 when directly writing hazard output to .asc . This is done in by rounding to the nearest integer, e.g. when interpolating a hazard value of 3.05 this is output as 3.0. If using an older version of TUFLOW, or using TUFLOW_to_GIS to post process, this can result in decimal values in the .flt or.asc grids between the desired integer values for hazard classification. To be consistent with how the latest TUFLOW Build is categorising floating point decimal values to integers when it directly outputs hazard grids (described above), the approach would be to categorise to the nearest integer value, e.g. 1.500-2.499 as 2 etc. If you did wish to reclassify 1.001-2.000 as 2 etc, this would provide a conservatively high hazard classification for decimal values, as you would be counting anything greater than the absolute integer in the next band.
7. TUFLOW GPU: Gridded Rainfall Input

Just an update to the above post, we are in the final stages of testing for a 2016-03-AB update, which will hopefully be available shortly. Also a word of caution about the work around above, if the boundary update interval is rounded number e.g. 5min / 60min per hour = 0.0833, then rounding in the grid time may also cause the boundary not to be updated and the rainfall rate / cumulative rainfall outputs (as described above should be used to confirm the rainfall depth applied).
8. TUFLOW GPU: Latest nVidia drivers (368.81)

Further to the above - the latest Quadro drivers (10.18.13.6886) which were also released mid July also appear to exhibit the same issue.

10. TUFLOW GPU: Gridded Rainfall Input

We have recently become aware of an issue affecting TUFLOW GPU simulations using the new gridded rainfall inputs. If the map output interval exceeds the interval in the rainfall grids, then the applied rainfall boundary condition is not updated. Choosing a map output interval that matches or divides into the boundary rainfall data interval will alleviate the issue. For example, if the gridded rainfall has a grid every 30 minutes, a Map Output Interval of 30, 15 or 10 minutes will all work. It is also important that the start map output time matches the gridded rainfall input start time. This will occur by default, though may be altered if a user defined Start Map Output time is specified. This does not affect TUFLOW “classic” simulations and the issue will be corrected in the 2016-03-AB release which will be available within the next month. If you're concerned about large file sizes resulting from your map output interval being reduced to fit your rainfall data interval you can use an output zone. For example with a 10 minute rainfall interval an output zone can be defined with an output interval of 10 minutes and the entire model output can be 1 hour. Again this work-around will only be required until the 2016-03-AB release. The 2016-03-AA release has the option to output the instantaneous rainfall rate and cumulative rainfall can be output with the RFR and RFC output types respectively. These can be used to cross-check the results. For example to output the depth, levels, velocities, rainfall rate and cumulative rainfall the .tcf command would be: Map Output Data Types == d h V RFR RFC Please contact support@tuflow.com if you have any queries relating to the above. Regards TUFLOW Support Team
11. Percentage Sign (%) in filenames

Q: When trying to run a batch file to convert a maximum water level from .dat format into .asc format I get an unexpected error. The batch file line is: C:\TUFLOW\Utilities\w64\TUFLOW_to_GIS_w64.exe -asc -b -t99999 M01_5m_1%AEP_001_h.dat A: This is most likely that the percentage character is treated as a special character in a batch file. For a description on this, please see the Microsoft site here: https://support.microsoft.com/en-us/kb/75634 In general I would tend to avoid special characters such as % in filenames where possible, for example there is a list here: http://www.mtu.edu/umc/services/web/cms/characters-avoid/ Whilst the % characters should generally fine in TUFLOW, are supported by Microsoft, however, they may require additional effort in batch files, e.g. may need to be wrapped in quotes (“) or have escape characters ignored. Another thing to note is that TUFLOW can directly write the outputs to .asc grid. You can output multiple file formats from TUFLOW and can set the data types, output interval etc based on the output format. For example in the below, the model will output dat and asc formats with only the maximums for the asc. Map Output Format == dat asc Map Output Data Types == h V q d Map Output Interval == 300 ASC Map Output Interval == 0 !only maximums for asc format ASC Map Output Data Types == h V d Z0
12. 1D/2D pit flow transfer

Question: I am receiving different opinions about the flow transfer rate regarding flow from the 2D terrain to a 1D subsurface element. Group 1 says that flow is transferred from 2D terrain to 1D catch pit using the weir equation. Group 2 says that the user can enter the capture rate using a depth (m) to hydraulic capture (m^3/s) chart. All flow will be tranferred from the 2D terrain to the 1D catch pit according to the parameters of the chart. Which of these two groups is correct? How does TUFLOW transfer flow from 2D to 1D? Answer: In TUFLOW a pit channel is designed to convey water to/from a 2D overland domain to a 1D pipe network. There are multiple options available for calculating flows, these are: Depth-discharge curve ("Q" type pit)Weir flow ("W" type pit)Rectangular culvert ("R" type pit)Circular culvert ("C" type pit, this one is rarely used)For more information on setting these up please see the Chapter in the TUFLOW manual on Pits and Pit Channels. Regards TUFLOW Support Team

14. Losses for J type manhole

Q: When using the "J" junction type manhole which losses / equations are applied? A: When using the Engelhund method, the J type 'manhole' uses the same equations as for the R and C type manholes in for the losses associated with change in direction (K-theta) and change in elevation (K-drop) at the junction. However, for expansion and contraction losses at the junction, these are recalculated every timestep according the departure/approach velocities of the downstream/upstream culvert (see Equations in Section 4.7.4.1 in the 2010 manual. These equations are essentially the same as used the manhole expansion/contraction losses, however, instead of using the manhole area for the term Am, the area of the downstream/upstream culvert is used. The applied entry and exit losses at a J 'manhole' are therefore a function of the approach and departure velocities which are derived from the incoming and outgoing pipe respectively. The calculated losses throughout the simulation can be reviewed in the _TSL output layer.
15. TUFLOW FV New Features and Application Seminars - Melbourne & Sydney

We’re pleased to announce the forthcoming TUFLOW FV New Features and Application Seminars. The seminars are free to attend and will be led by Dr Ian Teakle, the primary developer of TUFLOW FV. The next seminars will be held in: Melbourne on Tuesday, 12 May 2015 Sydney on Wednesday, 13 May 2015 Please refer to the TUFLOW website for more information about the seminars: http://www.tuflow.com/Training.aspx?ws To register for one of the events please contact training@tuflow.com and specify your city
16. TUFLOW FV New Features and Application Seminars - Brisbane Agenda

Dear TUFLOW users, The agenda for the TUFLOW FV New Features and Applications Seminar in Brisbane on Thursday 19 March 2015 is now available via the TUFLOW website: http://tuflow.com/Training.aspx?ws There are only a few places still available for the Brisbane event so please register by contacting training@tuflow.com. Dates for other capital cities will be announced shortly. Regards TUFLOW Team
17. Tidal Estuary - rising bed conditions

Hi Chris, If the change in elevation is linear then you could use the Variable Z Shape. If not you may need to use the "VG" type in the 2D_bc layer, in this you can specify a timeseries of elevation over time. Are you running the model for long periods of time (years), or are you running the model at discrete climate conditions. E.g. a simulation with 2050 and 2100 conditions? Regards Phil
18. TUFLOW 2013-12-AC and Windows XP?

Hi All, Thanks for pointing this out. It appears that in the TUFLOW GPU updates for the 2013-12-AC release a newer function is called and this is not available in Windows XP (only in Vista and newer): http://msdn.microsoft.com/en-us/library/windows/desktop/dd318702%28v=vs.85%29.aspx We are looking to issue an update which resolves this issue. Regards TUFLOW Support Team
19. Using Multiple Variables and Events

Q: How do I set up a run for two different independent variables? I have a tributary and a main channel and I would like to instigate the joint probability of a range of events occurring in both channels. A: Using a TUFLOW event file you can set multiple sets of events, in this case we will set M_<event> for the main channel and T_<event> for the tributary. This will set the event magnitude of the main channel and tributary separately. See the example excerpt from a tef file below. The event file (.tef) is read into the .tcf with the command “Event File == <.tef>” # MAIN CHANNEL definition Define Event == M_Q005 BC Event Source == __Main__ | Q001 End Define Define Event == M_Q010 BC Event Source == __Main__ | Q010 End Define Define Event == M_Q100 BC Event Source == __Main__ | Q10 End Define # TRIBUTARY definition Define Event == T_Q005 BC Event Source == __Trib__ | Q005 End Define Define Event == T_Q010 BC Event Source == __Trib__ | Q010 End Define Define Event == T_Q100 BC Event Source == __Trib__ | Q100 End Define In the bc_dbase, we will use these BC event sources (_Main_ and _Trib_) as wildcards. Refer to the below example, assuming that the boundaries in your model are called Main_Flow and Trib_Flow Name Source Column 1 Column 2 Main_Flow Main__Main_.csv Time Flow Trib_Flow Trib__Trib_.csv Time Flow The events in the .tef are set separately so that at the run start you can specify which one to use. If running from a batch file the –e (event) inputs can be used. For example, in your batch file: Start “TUFLOW” "C:\TUFLOW\Releases\2013-12\w64\TUFLOW_iSP_w64.exe" -e1 M_Q010 -e2 T_Q100 example_~e1~_~e2~_001.tcf The above would run a Q10 in the main channel (-e1 M_Q010) and a Q100 in the tributary (-e2 T_Q010), referencing flows from Main_Q010.csv and Trib_Q100.csv This can also be done by setting the “Model Events” command in the .tcf. To run the Q010 Main channel and Q100 Tributary (as above). The following would be needed in the .tcf. Model Events == M_Q010 | T_Q100 Note the use of the vertical bar (|) used to separate the two events. Specifying the events within the .tcf, would require modifying and saving the .tcf for each event you wish to run. This is a bit cumbersome and batch files become very powerful when running multiple events. For example if you wanted to run all combinations of events you could use a looped batch file, see here for more info: http://wiki.tuflow.com/index.php?title=Run_TUFLOW_From_a_Batch-file#Looping_in_a_batch_file ### Start Batch file @echo off :: This sets the variables as local, so you can use another batch file with A and B variables SetLocal :: set up variables set A=M_Q001 M_Q002 M_Q005 M_Q010 M_Q020 M_Q050 M_Q100 M_Q200 set B=T_Q001 T_Q002 T_Q005 T_Q010 T_Q020 T_Q050 T_Q100 T_Q200 :: Loop Through FOR %%a in (%A%) do ( FOR %%b in (%B%) DO ( Start “TUFLOW” "C:\TUFLOW\Releases\2013-12\w64\TUFLOW_iSP_w64.exe" -e1 %%a -e2 %%b example_~e1~_~e2~_001.tcf ) ) pause ### End Batch file If you wanted to also set the event durations as well as the magnitudes you could use 4 events (two for the event magnitudes and two for the event durations). Regards, TUFLOW Support
20. Direct Rainfall Approach, 2d_rf versus 2d_sa_rf

Q: What is the direct rainfall approach and what is the difference between the 2d_rf and 2d_sa_rf layers? A: For both the direct rainfall and the SA RF approach the specified boundary is a rainfall hyetograph. The direct rainfall approach applies the rainfall hyetograph to active cells with the region. For the SA RF the rainfall hyetograph is converted to a flow (in m3/s or ft3/s using the area attributers in the GIS layer, this is described further below. For both types the input hyetograph must be in mm (or inches) versus hours. The first and last rainfall entries should be set to zero, otherwise these rainfall values are applied as a constant rainfall if the simulation starts before or extends beyond the first and last time values in the rainfall time-series. Each value represent the rainfall that falls per increment, for example in the table below between 0.0833 (5 minutes) and 0.1667 (10 minutes) a rainfall depth of 2.5mm is applied, as opposed to a cumulative depth or rainfall rate. A total of 16.5mm of rainfall is applied over a 30min period in the hyetograph below. Time Rainfall 0.0000 0.0 0.0833 0.0 0.1667 2.5 0.2500 5.4 0.3333 3.5 0.4167 5.1 0.5000 0.0 The rainfall (2d_rf) layer applies the rainfall hyetograph to all the active 2D cells, the attributes are: · Rainfall name · factor 1 · factor 2 Both of the factors are multipliers and can be used to modify the boundary. E.g. an f1 might be an area reduction factor and f2 a climate change factor. These are multiplication factors and should be set to 1 if no change is desired. If these are set to 0 no rainfall will be applied and you will get a warning to tell you that this has occurred. For the direct rainfall approach the losses can be specified in either the materials database (the can be varied based on the land-use or 2d_mat layer) or via a soils / infiltration layer. Note: using the double precision build of TUFLOW is recommended for direct rainfall models to ensure accuracy in small flows. The sa rf layer (2d_sa_rf) also uses a rainfall hyetograph, but the required attributes are: · Name · Catchment_Area · Rain_Gauge_Factor · IL · CL The catchment area, factor, IL and CL are used to convert the rainfall, to an inflow boundary (e.g. time - flow). This is then applied to the 2D cells using the source area inflow type (2d_sa). For the SA inflow the default approach (for the 2013 version) is to direct the flow initially to the lowest cell within the polygon and when multiple cells are wet the flow is then spread between wet cells with the flow being proportioned by the cell depth. To turn off the proportioning to depth use the .tcf file command: SA Proportion to Depth == OFF A minimum depth can also be set, below this depth the cell will receive no inflow: SA Minimum Depth == <minimum depth> Regards TUFLOW Support team
21. Mismatched graphics cards and TUFLOW GPU

Q: We have hit out memory limit with a very large TUFLOW GPU model and were interested in adding another graphics card to our machine. Does SLI increase the memory available for TUFLOW GPU - if we add a 6GB card (GTX Titan) to our existing 3GB card (GTX 780) will this mean we have 9GB available or do the cards need to match? A: SLI is a method for enabling rendering on multiple cards. The TUFLOW GPU extension is written with NVIDIA CUDA which does not support the use of the SLI. However, you can run a large model on up to four cards on the same motherboard (data is transferred between cards via the motherboard using the PCI bus). Essentially the model is split between the cards, so the memory requirement will be shared amongst the cards. This means that running on multiple GPUs increases the size of the model that can be simulated. It is noted that you will need a GPU licence for each GPU card you wish to access. For example, if you have more than one GPU card and you wish to run the model across both cards, you will need two (free) GPU licences. In terms of the cards matching you should be able to use mis-matched cards, however, the model is currently split evenly between the cards. This means that: * The slowest card will limit the speed as they have to synchronise every timestep * The card with the smallest RAM will limit the model size to N x Smallest RAM, where N is the number of cards being used. If interested, we can looking at allowing the user to define the split between the cards, however, an uneven split may not be ideal. For example, if you were to run a very large (i.e. a 9GB model) split unevenly across the two cards (3GB 780 and 6GB Titan) for memory reasons the Titan would need to process twice as much of the model as the 780. Given the Titan and the 780 have similar CUDA core counts (identical, depending on if you are using Ti or black variants), this would mean that the 780 would be waiting for the Titan. Regards TUFLOW Support Team