Jump to content
TUFLOW Forum

tuflow support

Administrators
  • Content Count

    142
  • Joined

  • Last visited

Everything posted by tuflow support

  1. Auckland 20th February, 2018 - Modelling Workshop The TUFLOW team are hosting a free lunch and afternoon hydraulic modelling workshop presenting a combination of demonstrations, case studies, technical presentations, and question and answer sessions focusing on common modelling challenges faced by industry. You will have access to hydraulic modelling experts who will share their experiences and approaches to model review, assessment of hydraulic structures, when are 1D and 2D solvers accurate, sub-surface pit and pipe drainage networks, and 2D hydrologic techniques. The afternoon provides an excellent opportunity to network and discuss hydraulic principles with other modellers and environmental specialists working in the flood risk management industry. The session is designed for engineers, scientists, project managers and others either new to hydraulic modelling or those interested in better understanding the tasks involved to prepare and deliver floodplain and coastal hydraulic assessments. Auckland 21st-22nd February, 2018 - Intensive 2 Day Computer-Based Training Whether you are new to TUFLOW or a long-term user, this 2 day training is a great way to develop and enhance your understanding of TUFLOW’s functionality, your capabilities and efficiency as a modeller, and to learn about hydraulic modelling principles. Our training aims to ensure you get the most out of hydraulic modelling. Day 1 covers the TUFLOW basics, including TUFLOW theory followed by practical model creation and review of results. Day 2 covers more advanced features and efficient modelling practices. This session also covers the new HPC solver. For more information on content and how to register please check out our New Zealand Training Page: https://www.tuflow.com/Training.aspx?nzbt# If you have any other queries, please send me an email at training@tuflow.com. Kind regards, Mitch.
  2. 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. 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. 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.
  5. 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. 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. 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. 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.
  9. Pre-release testing for the forthcoming update to the 2016 version of TUFLOW has identified a potential issue in the 2016-03-AA version of TUFLOW when using TUFLOW GPU with SA inflows and the latest version of the NVidia drivers (368.81). The issue occurs when the SA inflows are proportioned to depth (which is the default behaviour). Previous versions of the NVidia driver show the correct flows, but for the latest driver, an issue can occur when there are cells wetting / drying within the SA boundary causing an incorrect inflow volume. The NVidia drivers were released on the 14th of July 2016 and the 2016-03-AA version of TUFLOW was released in March 2016. Our SA inflow test results are shown below, for the same model with the NVidia latest drivers (368.81) and an older set of drivers. The results highlight how artificial volume is being created by the simulation run using the new NVidia drivers (368.81). Our testing has shown this error is resolved by using the “Read GIS SA ALL ==“ command, instead of “Read GIS SA ==”. If you are using the 2016-03-AA version with SA inflows within a TUFLOW GPU model, the following is recommended: 1) Quality check you flow / volumes results to determine if the NVidia Drivers your computer uses creates the above mentioned issue. 2) Use the “Read GIS SA ALL” option. An 2016-03-AB update is to be released shortly which will address the issue. For future NVidia driver updates, we are planning on running a series of benchmark models to check compatibility of the drivers. Please contact support@tuflow.com if you have any questions about the above. Regards TUFLOW Team
  10. 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. 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. 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
  13. Welcome to the TUFLOW Forum This forum connects the TUFLOW community through announcements, questions, knowledge sharing and users experiences. The forum has a technical and applications focus, and is moderated by the TUFLOW Support Team. Here are some guidelines to get you started: 1) Register as a forum user Before you can post, please register as a forum user. You need to validate your email address and then be approved by a forum moderator. Using your organisations email address is preferable as we can approve you straight away. This process is needed to prevent spammers and advertisers from registering. 2) Publish a post or ask a question The forum is organised into forums and sub-forums, from which users are able to post questions and comments as topics. Before creating a new topic, it can be worthwhile checking whether a similar one already exists – it may even answer your question! The easiest way to search the forum is to use Google (eg. ‘Tuflow Forum, boundary error’). You can also add your comments or questions to an existing thread in response to other user’s post. When you post a topic, please only click the ‘Submit Topic’ button once, even if the forum pauses for a while (clicking a second time will submit the post twice). The pause is due to email notifications being issued and is a characteristic of the Forum software. 3) Share Your Knowledge Help others by answering their questions and sharing your experience. Sharing tips, resources and ideas contributes to the community user base that TUFLOW has become well known for. 4) Get Updates Under a forum or sub-forum, click ‘Follow This’ on the top right to subscribe to email updates to your favourite TUFLOW topic feeds. 4) Get Started Go the Forum Main Page, have a look around and if you're keen get involved start posting. If you have any queries please don't hesitate to drop us an email at support@tuflow.com and we'd be more than happy to help you out. Regards, the TUFLOW Team.
  14. 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. 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. 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. 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. 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. 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. 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. 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
  22. Q: I have a TUFLOW GPU simulation which I am using “Read RowCol RF == <layer.mid>” to vary my rainfall factors (f1 and f2) on a cell by cell basis. However, when I review the results it would appear that the multiplication factors are not being used (or used as 1). A: As background for other readers, to gradually vary direct rainfall across your code in both TUFLOW classic and GPU area, you can use the: Read RowCol RF == <gis_layer> command and alter the f1 and f2 scaling factors. The hyetograph weights are multiplied together before being applied to the rainfall. When running TUFLOW GPU, the GPU module performs a check that these are within a valid range, currently this range is 0 – 1.The range limit is applied in the GPU to limit the amount of memory required and maintain accuracy of resolution. If the factors are in the range 0 – 1 they are used as expected. However, if these are outside the range the following error occurs in the log file: Adding hydrograph weight layer 1 ... ERROR: Hydrograph weight data not in range [0..1] If the error above is generated, the simulation then discards the weighting factors and proceeds, however, the results should be treated as suspect and not used. Currently, if this occurs the message is logged to the .gpu.tlf file, however, the simulation is not stopped. It is likely the for a future release that we will force the simulation to stop. TUFLOW classic allows the these weighting factors to add to more than 1, whereas, the GPU solver is capped as 1. To maintain consistency with TUFLOW classic, this capped weighting limit is currently under review within the GPU module, we will ensure that should this change then users will be notified. In the interim, to use weighing factors greater than 1 for a TFULOW GPU simulation, you will need to modify the rainfall boundary so that the f1 factors are less than 1. E.g. multiply the rainfall boundary by 2 and divide the factors by 2 so that they are less than 1. For future releases, we have been enhancing TUFLOW to support a wider range of rainfall boundaries (e.g. as a series of radar images). As part of this we are also adding more outputs. We will be including added the following, to make it easier to track rainfall on a cell by cell basis: · Rainfall rate (output as mm/hr) · Cumulative rainfall (output as mm) Regards TUFLOW Support Team
  23. Similar to using events or scenarios, any number of Output Zones can be defined. The “Model Output Zones ==”“ command is used to select which output zones are to be used in the simulation. There is no requirement to have a separate file containing the output zone definitions. However, if there are numerous output zones, it would be good practice to place these in one or more separate files and use the “Read File ==” to reference these file(s) so as to keep the size of the .tcf file minimal. If you want to use multiple output zones for a particular simulation your control file should use the “Model Output Zone ==” command with a vertical bar (pipe) between output zone definitions, like this: Model Output Zones == ZoneA | ZoneB Please note, if you repeat the Model Output Zones command then only the last command will be used to define the output in TUFLOW. For example, if you set out your commands as below, only Zone 2 will be output to your results files. Model Output Zones == Zone1 Model Output Zones == Zone2 Each output zone is defined using a definition block as follows: Define Output Zone == <oz_name> ….. End Define With the exception of “Read GIS Output Zone ==”, all commands are optional. Note that the output zone must be a polygon shape, not a rectangle or square shape. If Tuflow detects a shape that is not a polygon, WARNING 2073 will be in the messages layer. Refer to the 2013-12 Release notes, sections 35 to 37 for commands that can be used within an output zone. An example out an output zone setup is as follows: Model Output Zones == ZoneA | ZoneB Define Output Zone == ZoneA !Zone at the river mouth Read GIS Output Zone == ..\model\gis\2d_OZ_ZoneA.shp !GIS layer that contains polygon(s) of region to be output Map Output Format == XMDF ! Options: DAT XMDF WATERRIDE GRID BLUEKENUE and SMS TRIANGLES Map Output Interval == 300 ! Seconds XMDF Map Output Data Types == h v d q Output Folder == ..\results\<<~s1~>>_<<~s2~>>\zones Maximums and Minimums == ON MAXIMUMS ONLY Map Cutoff Depth == 0.05 End Define Define Output Zone == ZoneB !Zone near the development Read GIS Output Zone == ..\model\gis\2d_OZ_ZoneB.shp !GIS layer that contains polygon(s) of region to be output Map Output Format == XMDF DAT GRID ! Options: DAT XMDF WATERRIDE GRID BLUEKENUE and SMS TRIANGLES Grid Format == ASC Map Output Interval == 300 ! Seconds XMDF Map Output Data Types == h v d q MB1 MB2 Output Folder == ..\results\<<~s1~>>_<<~s2~>>\zones Maximums and Minimums == ON MAXIMUMS ONLY Map Cutoff Depth == 0.05 End Define
  24. Q: I am reading an initial water level into the model to fill the depressions. I am adding the following to my .tcf file: Read Grid IWL == ..\model\grid\pit_filled_dem.flt However i can an error to say that the command is ambiguous. A: If using a Read Grid IWL, this needs to be read into the geometry control file (.tgc) and not the .tcf. If you move the command to the .tgc this should resolve the issue. Please note that any other IWL commands (such as Set IWL) should also be moved to the .tgc file, otherwise these will overwrite the values in the grid.
  25. Q: I’m currently working on a model run on a previous build, 2009 07 AE iSP, and I’m experiencing a WDRVR.DLL dongle error. A: Tuflow builds 2009-07, 2008-08 and 2006-06 predate the newer WIBU CodeMeter dongles and can thus show a WDRVR.DLL error as they look for the old Softlok dongle. Updates for these old builds were released to recognise the new WIBU dongles. These can be found here: http://www.tuflow.com/Tuflow%20Previous%20Release.aspx Release notes detailing these updates are found here: 2009-07: http://www.tuflow.com/Release_Notes_2009_07.htm#8 2008:08: http://www.tuflow.com/Release_Notes_2008_08.htm#12 2006-06: http://www.tuflow.com/Release_Notes_2006_06.htm
×
×
  • Create New...