Jump to content
TUFLOW Forum

tuflow support

Administrators
  • Content Count

    142
  • Joined

  • Last visited

Everything posted by tuflow support

  1. Q: When running a model in English Units, what is the output unit for Bed Shear Stress? A: As outlined here (http://www.tuflow.com/forum/index.php?showtopic=989) the metric units for bed shear are kg.m-1.s-2. For English units the Bed Shear Stress output units are: lb.ft-1.s-2. The default value for density is based on 1,025 kg/m3 (63.99 lb/ft3). Note that the “BSS Cutoff Depth ==” setting will affect the BSS results below the cutoff depth. The default cutoff depth is 0.1m under which the BSS is linearly reduced to zero as the water depth approaches zero (otherwise a divide by zero occurs). You will need to be using TUFLOW Build 2012-05-AA or later. Edit It should be noted that the pound (lb) in the units above refers to pound mass (lbm) and not pound force (lbf). The conversion between these is outlined in the equation below. E.g. to convert from lbm to lbf divide by 32.17. For more information please see here: http://en.wikipedia.org/wiki/Pound_%28force%29
  2. This has been fixed and an updated TUFLOW_to_GIS will be uploaded shortly.
  3. Interesting one. We have received the results from Tom and have diagnosed the issue, I think it warrants further description below. The lines of low velocity are occurring in certain locations around the model. When zoomed into one of these areas with the velocity vectors turned on, the flow patterns look like the below. The results are the maximum tracked on a timestep by timestep basis (not an instant in time), the velocities look unusual! The model is tidal and in different parts of the model the maximum velocities occur on a flood or ebb tide. In the location shown on the left the maximum velocities occur on the ebb (outgoing) tide and on the right the flood (incoming) tide. When the TUFLOW_to_GIS utility is performing an interpolation to a regular grid (either raster or gis point layer), the Vx and Vy components are interpolated separately. When outputting to a GIS file (shapefile or MapInfo file) this allows for both a velocity direction and magnitude to be outputted (arrows can be output). However, in this case as the velocity directions are approximately 180 degrees apart, the interpolated vector has very little magnitude, this is showing up as a band of low velocity when converted to a scalar grid. As Tom mentions, this behaviour did not occur in older versions of the utility. When the option was added to use –grid<cellsize> with either –mif or –shp was introduced, the interpolation behaviour was changed. If you output to a regular grid using the –mif or –shp file option you get a regular grid of points or vectors. In order to be able to determine the vector direction it is necessary to interpolate components and not just magnitude. This is an unintended consequence of this. We will update the utility to use vector magnitudes if the output is a raster grid and vector components if the output grid is a GIS (mif or shp) layer. Regards TUFLOW Support Team
  4. Q: I am using the new feature in the 2013 version which allows the direct read of TIN surfaces in Landxml format but aim getting the following error: tgc>> Read TIN Zpts == tin\tin_surface.xml out>> Read TIN Zpts... Processing TIN File: tin\tin_surface.xml Trying to open file tin\tin_surface.xml...OK. Opened File Unit: 920 Looking for XML TINs... Found start of XML Surfaces. Determining memory allocation... forrtl: severe (24): end-of-file during read, unit 920, file tin\tin_surface.xml Are you able to shed any light on this matter? A: After reviewing the culprit LandXML file it appears that the .xml does not require line endings after each tag (example xml tag: <Surfaces>), the file can all be one or two very large lines! The file provided had two lines that were over 100,000,000 characters long. All of the samples we had seen previously have a line ending after each tag. However, depending on the editor it may or may not include the line endings. The more common format of having the line endings seems to be referred to in xml circles as a “pretty print” option. I opened the .xml file you provided in the (free) Microsoft xml notepad (http://www.microsoft.com/en-us/download/confirmation.aspx?id=7973) and re-saved this. The Microsoft xml editor automatically saves the xml out in the more common format with line endings after each tag. With line endings, the file looks like the below: <Surfaces> <Surface name="TIN Surface" desc="Description"> <SourceData></SourceData> <Definition surfType="TIN" area2DSurf="513153.51351" area3DSurf="513153.513153" elevMax="51.3" elevMin="41.4"> <Pnts> <P id="1">83185.8112625852 846513.12499771756 48.6</P> (lots of lines removed here) Once the file has line endings, this .xml works correctly in TUFLOW. We will need to see if we can support the alternative format, as a work around the xml notepad linked above is very simple and quick method. Regards TUFLOW Support Team
  5. Q: I have used the res_to_res utility to extract the maximum stream power from a simulation. I have used TUFLOW_to_GIS to export the maximum stream power to an ascii grid (.asc). However, when i import this to ArcMap some of the data is skewed. The depth and water level grids open without issue. A: We got hold of the stream power grids, which open correctly in MapInfo, but do not in ArcMap. After some investigation the following was determined to be the cause: The ascii grid is a space delimited file, in the stream power grids there were some high values. These values are "10000.000". In the .asc grid this looks like: 1374.2073 3335.155510000.000010000.0000 9174.210910000.000010000.000010000.000010000.000010000.0000 5478.9277 2581.2310 533.0659 13.5509 Using the default .asc output format, there is no separator (space) between the values (e.g. 10000.000010000.0000). This is causing the two numbers to be treated as a single number when imported to Arc, which results in the data being skewed. This is causing the issue when importing to Arc (but MapInfo seems to handle it). In order to get around the issue there are two options: Use a text editor to search and replace “10000.0000” with “ 10000.00 “. This should fix the issue for the grids already created. You can also specify the output format when using TUFLOW_to_GIS utility by using the "-prec" option. Recreating the grids using a precision will resolve the issue. -prec<u>.<d> sets the output precision for -asc and -mif options. Eg: -prec12.3 would output 12 characters (or 11 if the number is negative) with 3 numbers following the decimal place. Your batch file should like like: tuflow_to_gis.exe -asc -t111111 -prec12.3 <filename> However, these stream powers seem quite high. These can occur as the depth goes to zero. Bed Shear Stress (BSS) and Stream Power (SP) map output can be misleading at very shallow depths as the BSS formula divides by the depth. For the 2012-05 release of TUFLOW the BSS and SP outputs are linearly reduced to zero once the depth is below a threshold (by default, 0.1m). To change this threshold, use “BSS Cutoff Depth == <BSS_cutoff_depth>” in the .tcf file. Regards TUFLOW Support Team
  6. Q: I see that IL/CL losses can be specified in either the materials layer or the soil layer. Are you able to explain the differences between these two approaches? A: The infiltration losses (specified in the soil file) and rainfall losses (specified in the materials file) are applied separately. The infiltration losses (using either a Green-Ampt or IL/CL approach) will infiltrate ponded water into the ground, rainfall losses will remove the loss depth from the rainfall before it is applied as a boundary on the 2D cells. Note that the infiltration IL/CL is totally separate to the rainfall IL/CL losses (used to generate excess rainfall for direct rainfall simulations). It is possible to use both methods in the same simulation – for example, rainfall that doesn’t reach the ground, such as interception by trees would be modelled as a material IL (applied as a loss to the rainfall) and infiltration into the ground as IL/CL via soil types. Specifying the “fraction impervious” on the material allows the materials and the soils to be independent, i.e. the same soil can be present under both road and forest. However, this fraction impervious only applies to the infiltration into the soil and not to the rainfall losses. In the log file you will see the material and soil properties reported separately: Example Material Properties #4 - Material 4: Fixed Manning's n = 0.030 IL = 1.0mm, CL = 0.0mm/h Landuse Hazard ID not set. SRF (Storage Reduction Factor) = 0. Fraction Impervious = 0. Example Soil Properties #1 - Soil 1 [based on pre-defined soil type SAND]: Suction = 49.5 mm HydCond = 117.8 mm/hr Porosity = 0.417 Initial Moisture = 0.2 Soil Capacity = 0.217 If specifying infiltration losses these can be checked with the infiltration outputs (CI and IR). The _grd_check.mif will also contain the spatial distribution of soil type as read by TUFLOW. Hopefully this clarifies the way the losses are applied. Regards TUFLOW Support Team
  7. Q: I am getting the following error: ERROR 0104 - Could not find line with column labels "Time" and "Flow" in TUFLOW\BoundaryConditions\Inflow.csv I have checked the file and both the column labels "Time" and "Flow" are present. Is there anything else that could be causing the issue? A: This error can also occur if the file has been saved in "Macintosh" format rather than in "Windows\Dos" format. When saving in Excel there are actually a number of CSV formats (which is confusing) ensure that "CSV (Macintosh) (*.csv) has NOT been selected from the drop list. The correct choice is "CSV (Comma Delimited) (*.csv). TIP The TUFLOW macros for Excel available from the TUFLOW website will ensure that the csv file is saved in the correct format and will also suppress the warnings that Excel generates when saving in csv format. Most text editors, such as Ultraedit and Notepad++ will display the file format in the info display at the bottom of the screen. The following Macintosh format may cause issues: . The Windows/Dos format should work correctly: See also the TUFLOW wiki message for Error 0104: http://wiki.tuflow.com/index.php?title=TUFLOW_Message_0104
  8. Q: Hi, I have a model that is reporting a number of Check 1401 and 1402 messages, are you able to explain why these are occurring? A: When calculating the manhole losses at pipe junctions, by default TUFLOW uses a modified Engelhund approach. This method calculates losses at manholes based on: Expansion / Contraction Change in direction of the culverts Change in height / inverts This approach is outlined in Section 4.5.2 of the TUFLOW manual. As of the 2012-05-AA release of TUFLOW if the invert of an incoming culvert enters above the obvert of the highest outlet, the culvert is not included in the manhole loss calcs. This is described in point 48b of the release notes: http://www.tuflow.com/Download/TUFLOW/Releases/2012-05/Doc/TUFLOW%20Release%20Notes.2011-09%20and%202012-05.pdf If a culvert is ignored due to the high invert, one of two messages is generated. If there are other incoming culverts that are included in the manhole calculations a CHECK 1401 message is generated: CHECK 1401 - <x number> culvert(s) not used for determining losses at Manhole <Manhole ID> If there is only 1 incoming pipe with the invert above the obvert of the outlet culvert, the incoming culvert is ignored and with no other incoming culverts to the node a manhole is not possible and a CHECK 1402 is generated: CHECK 1402 - More than one culvert connected but could not create manhole at Node <Node ID>. If you snap a manhole in a 1d_mh layer, this should resolve the issue (you will need to check the "_mhc_check" to ensure the correct number of inlet and outlet culverts is detected). Alternatively, we can look and including a vertical tolerance for setting when culverts are ignored in the loss calcs. If this appeals to anyone, please email us at support@tuflow.com. See also the wiki entries: http://wiki.tuflow.com/index.php?title=TUFLOW_Message_1401 http://wiki.tuflow.com/index.php?title=TUFLOW_Message_1402 Regards TUFLOW Support Team
  9. Hi Carlos, Yes, this is certainly possible. A typical approach would be to use a 1d_nwk layer with a "W" (weir) type channel. A cross-section representing the weir can be specified in the 1d_tab format with either a "XZ" (offset elevation) or "HW" (height-width) type cross-section. To connect the 1D channel to the 2D cells upstream and downstream of the structure a "SX" connection in the 2d_bc layer can be used. Note the length of the "SX" line should be as wide as the weir cross-section. If a 100m wide weir connected up to the 2D with a 10m "SX" line. The weir will have much more conveyance than the 2D cells it is connected with and is likely to results in instability. The 1d/2d boundary cells can be seen in the _1d_to_2d_check.mif or _1d_to_2d_check_R.shp files. Please let us know if you require any further clarification. TUFLOW Support Team
  10. Q: I have a direct rainfall model which runs when using Single Precision (SP) but does not start when using Double Precision (DP). A: After viewing the log files, the issue occurred immediately after reading the restart files. The restart file stores the information at the precision the original model used to create the restart files was run at. IN this case the model restart file was created with the SP version of TUFLOW, but the model was running in DP. The restart file was recreated in DP and this resolved the issue. We will look into in an additional check or support for restart files for both precisions. For the .xf files (which store the processed elevation data), either .xf4 (4 byte real or SP) or .xf8 (8 byte real or DP) files will be written depending on the precision of the model. The .xf4 and .xf8 naming convention prevents the files from being overwritten or used by a conflicting precision version of TUFLOW.
  11. Q: I have some pit locations which are not all snapped to the underground drainage network. I have tried to use the "Pit Search Distance" command to set a tolerance, however, I am still getting messages about unconnected pits. My .ecf is below: Read GIS Network == ..\model\gis\1d_nwk_conduits_001_L.shp Read GIS Network == ..\model\gis\1d_nwk_pits_001_P.shp Pit Search Distance == 50. Timestep == 0.5 Write Check Files == ..\check\ Output Folder == ..\results\ A: The Pit Search Distance can be repeated for multiple layers, as such the order of the command is important. The pit search command should be included above the the GIS layer containing the pits. In the modified .ecf below, the pit search distance is set to 50 and then reset to 0 after the culprit pit layer is inputted. Read GIS Network == ..\model\gis\1d_nwk_conduits_001_L.shp Pit Search Distance == 50. Read GIS Network == ..\model\gis\1d_nwk_pits_001_P.shp Pit Search Distance == 0. Timestep == 0.5 Write Check Files == ..\check\ Output Folder == ..\results\ Regards TUFLOW Support Team
  12. After looking at the layers there was indeed an issue with the snapping. With the .tcf command: Snap Tolerance == 0.1 The model starts correctly. It should be noted that the snap tolerance command (which controls when two GIS objects such as pipes are considered snapped) is different from the pit search distance (which controls how far to look for a node to connect a pit object to).
  13. We have had feedback that in order to run TUFLOW on Windows 8, you will need to have the latest wibu dongle drivers installed. These drivers can be found here http://www.codemeter.de/us/service/downloads.html. We have also updated the TUFLOW downloads page (http://www.tuflow.com/ProductDownload.aspx) to include the link to the codemeter site. If you have any other experiences with TUFLOW and Windows 8, please share them below.
  14. HI Claire, Are you able to send through the log and boundary files to support@tuflow.com and we'll take a look. Regards TUFLOW Support Team
  15. Q: I am trying to start a model with an initial water level from a previous simulation. I have tried to follow the method outlined in 4.9.1 of the manual (using the Read RowCol IWL command), however, the model is very large and this takes a long time. Is there an alternate approach? A: Yes, as of the 2012 release of TUFLOW, it is possible to read a gridded water level in the .asc format. This avoids the steps of having to inspect the levels in a GIS package. Much the same way as the DEM can now be directly inputted. The process is to convert the results from the previous model into the .asc format using TUFLOW_to_GIS: For example, to use the maximums of a .dat file the command would be: c:\tuflow\utilities\tuflow_to_gis.exe -asc -max results_h.dat For a specific time, in this case 3 hours this would be: c:\tuflow\utilities\tuflow_to_gis.exe -asc -typeH -t3 results.xmdf The initial water level can then be directly read from this grid, with the .tgc command Read GRID IWL == <path to .asc grid> for example: Read Grid IWL == results_hMax.asc Note that this Read Grid IWL command needs to be read into the geometry control file (.tgc) as opposed to the .tcf. For more information please see point 52 in the release notes below. http://www.tuflow.com/Download/TUFLOW/Releases/2012-05/Doc/TUFLOW%20Release%20Notes.2011-09%20and%202012-05.pdf For more examples of the TUFLOW to GIS please see here: http://wiki.tuflow.com/index.php?title=TUFLOW_to_GIS#Converting_to_3D_grids
  16. Q: I have been given a model with the following command in the .tgc: Read TIN Zpts == file.tin Are you able to tell me what the command is doing and what the .tin format is? A: The command is reading the elevations from a triangulated irregular network (TIN). The “Read TIN Zpts” inspects the elevations from the TIN, much the same as the Read GRID Zpts inspects the elevations from a gridded DEM. The read TIN zpts supports both SMS.tin and 12D .12da format, in this case an SMS tin is being read. The SMS. tin format is very basic, essentially this is: VERT <number of vertices> X Y Z of each vertex E.g: VERT 8 !Tin has 8 vertices 500.0000 1000.0000 0.0000 !x y z of 1st Then: TRI <number of triangles> Vertex1 Vertex2 Vertex3 For example TRI 10 !Tin has 10 triangles 5 6 3 !triangle 1, connects vertices 5,6,3 Indicates that the TIN contains 10 triangles and the first triangle connects vertex 5, 6 and 3. The 5th vertex, is the 5th in the order they are listed in the VERT section. I A simple TIN is SMS looks like attached . The TIN is stored in the SMS format. For more information on the file format, please refer to the Aquaveo wiki: http://www.xmswiki.com/xms/TIN_Files The TUFLOW utility TIN_to_TIN, can be used to convert between the SMS, 12da and vertical mapper .tri format. For help using the tin_to_tin utility, refer to the following page on the TUFLOW wiki: http://wiki.tuflow.com/index.php?title=TIN_to_TIN Regards TUFLOW Support Team
  17. Hi Danny, If you have run the coarse model for the same events as the finer model you can probably use a HT boundary and get the time-varying boundary data from the coarse model. If you do modify the slope on the HQ boundary it is good practice to run a sensitivity analysis to verify that changing the HQ slope has not significantly altered the results in the area of interest. Regards Phillip
  18. Q: I am running a 2D only model with a QT inflow and a HQ outflow boundary. I am trialling the adaptive timestep feature (as outlined in point 55 of the release notes http://www.tuflow.com/Download/TUFLOW/Releases/2012-05/Doc/TUFLOW%20Release%20Notes.2011-09%20and%202012-05.pdf). When I start the simulation, I get the following message: SORRY - 1D linking not available yet with adaptive time-stepping. Why is this occurring when I don't have a 1D control file specified? A: The 2D QT boundary applies the flow via a hidden 1D node (this is done to allow wetting and drying along the boundary). For running a model with an adaptive timestep, you will need to replace the QT boundary with an alternative such as 2d_sa inflow. A comparison between QT and SA boundaries is outlined in the following forum post: http://www.tuflow.com/forum//index.php?showtopic=1151 Regards TUFLOW Support Team
  19. Q: Does the line direction of culverts and pipes in the 1d_nwk layer have any affect on the results? A: It depends a bit on which settings have been used in the model! For example, when modelling culverts using adjusted entrance and exit losses (as opposed to manhole losses), the inlet and outlet losses are dependent on the approach/departure velocities to/from the pipe entrance/exit. The approach/departure velocities are taken as those from the primary channels (pipes) upstream and downstream to the pipe. The digitised direction has a bearing on how the primary channels are selected, therefore if the pipe is digitised in the wrong direction and corrected, then the primary channels may change and therefore the losses may change. The primary channels are tabulated in the .eof file if you need to cross-check. However, for the Engelhund loss approach the flow direction (not pipe direction) is used to determine energy losses, although if automatically generating manholes (the default) the pipe directions are used to automatically size the manhole so this could affect results. If the upstream and downstream inverts are applied on the channel (as opposed to using a snapped node object), these are also dependent on the line direction. The Upstream_Invert is interpreted as the invert at the start of the line. So an incorrectly digitised pipe would have the wrong upstream and downstream invert and would mostly experience adverse flow. The culvert flow regimes (See Figure 4-6 and 4-7 of the TUFLOW manual, also shown below) are independent of the digitised culvert direction, ie. the flow direction is used, but are of course dependent on having the correct upstream and downstream inverts. Inlet Control Flow Regimes: Outlet Control Flow Regimes: As a matter of good practice, culverts should always be digitised from upstream to downstream. Regards TUFLOW Support Team
  20. Q: When using dat_to_dat to get the maximum from a number of different durations, the maximum does not match the expected value. The command line I'm using is: dat_to_dat.exe -max Q100_duration1_h.dat Q100_duration2_h.dat Q100_duration3_h.dat Any ideas what might cause this. A: If you have maximums (time 99999) in your output .dat files, then it is wise to use the -t99999 option when creating an envelope of the maximums of two or more simulations. For example use: dat_to_dat.exe -max -t99999 Q100_duration1_h.dat Q100_duration2_h.dat Q100_duration3_h.dat For a description of why this may be occurring please see this previous post on the TUFLOW forum: http://www.tuflow.com/forum/index.php?showtopic=357 Regards TUFLOW Support Team
  21. Q: When modelling a levee breach by applying a inflow hydrograph on the floodplain side of a levee, should a 2d_bc of type QT (flow v's time) or a 2d_sa (source area)? A: Both methods will introduce the inflow into the 2D model. The QT boundary type applied assumes the water level is constant along the line (i.e. perpendicular to flow). TUFLOW uses a hidden 1D node, which the flow is applied to, this is spread to the connected 2D cells assuming the same water levels in all connected cells. In some locations for example where divergent flowpaths are separated by a ridge, this may not be the case. This configurations can cause circulations at the boundary which may force down the timestep. An alternate (and more stable) approach is to use the 2d_sa (source-area) boundary. This allows the flow to be split between the cells, this can be split equally between all cells, between the wet cells, or proportioned using the cell depth. The input uses a GIS region object. The default approach is to direct the flow initially to the lowest cell and then spread this between wet cells with the flow being proportiened by the cell depth has been applied. 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
  22. Q: Can you please detail the steps required to move a network Wibu dongle to a new server? A: The steps you will need to take are: Install the CodeMeter drivers on the new server, these can be found on the TUFLOW downloads page: http://www.tuflow.com/Download/Drivers/WIBU%20Codemeter%20Dongle%20Installation.zip Enter the CodeMeter Webadmin and ensure this is setup as a "Network Server" as per Section 5.1.4 of the 2010 TUFLOW manual, see also this image: At this stage I would suggest testing TUFLOW on the new server to ensure the dongle is working correctly on the server (make sure it is plugged in and detected). You can simply double click on the TUFLOW executable and TUFLOW will report the licence status. Once the licence is detected and working on the new server, the client machines will need to use the new server address. It depends on how the client machines are setup, in most cases the client machines will automatically detect the new server. However in some cases the IP or server name is required. To check how the system is currently setup, on a client machine, Open the CodeMeter Control centre and navigate to the WebAdmin. Go to the Configuration >> Network tab (see image below). If the current server is listed in the “Server Search List” you will need to add the new server. However, if nothing is listed in the "Server Search List" the system currently auto detects the server it therefore should automatically detect the new one. This image shows a client machine with servers listed via both and IP and server name: Regards TUFLOW Support Team
  23. Q: Is there an easy way to run different scenario combinations (i.e. using the –e; -s1 flags), without having to manually write them out in the batch file? A: In order to do this, you will need to set up the batch file using a logic statement. See example below: I want to run a Q005, Q010 and Q100 event for 3 different durations (01hr, 02hr and 12hr) and 3 different scenarios (Exg, Dev and Mit). @ echo off ! This stops each command from being displayed/echoed in the dos window Set local ! This sets the variables to be local. If you set off multiple batch files with the same variable, this command will ensure that they both can run. Set A = Q005 Q010 Q100 ! This sets the range of events you wish to run Set B = 01hr 02hr 12hr ! This sets the range of durations you wish to run Set C = Exg Dev Mit ! This sets the scenarios you wish to run For %%a in (%A%) do For %%b in (%B%) do For %%c in (%C%) do echo Start “TUFLOW” TUFLOW_iSP_w64.exe –e1 %%a –e2 %%b –s1 %%c filename_~e1~_~e2~_~s1~.tcf If you have any issues with the above, please contact support@tuflow.com. Regards TUFLOW Support Team
  24. Hi All, Below is some information on choosing an appropriate 2D timestep. The model in question is a levee breach model with flow hydrographs applied behind the levee as a 2d_SA inflow. There is no 1D in the model. A good step in creating a model is running the model with a variety of timesteps to ensure that reducing the timestep does not significantly alter the results. In this case the model cell size is 150m and as a rule of thumb the timestep (in seconds) would typically be in the range 1/2 to 1/5th of the cell size (in metres), therefore we would expect the timestep to be in the order of 30 seconds to 75 seconds. As the model is purely 2D this also allowed us to test the adaptive timestep feature, for more information on the adaptive timestepping, please see point 55 of the latest release notes: http://www.tuflow.com/Download/TUFLOW/Releases/2012-05/Doc/TUFLOW%20Release%20Notes.2011-09%20and%202012-05.pdf. For both the fixed and adaptive timestep versions the timestep (or courant number for the adaptive timestep) was modified to test the model sensitivty to timestep. The model simulations performed were: Fixed timestep ranging from 15 to 150 seconds Adaptive timestep with maximum courant number ranging from 5 to 60. For each simulation the results, mass error and the number of reported negative depths were compared. Table 1 contains a summary of the CPU time, mass error and negative depths reported for the fixed timestep runs. It is noted that the 150 second timestep simulation went unstable part way through. Table 2 contains a summary of the CPU time, mass error and negative depths reported for the adaptive timestep runs. To check the consistency of the results, the peak water levels were compared at 8 location spread across the model domain. For all simulations except the fixed timestep of 120 seconds and the adaptive timestep with a Maximum Courant Number of 60 (both highlighted in red in the table below) the results are consistent across all points. For this type of modelling (levee breach), the time to inundation is likely to be very important, so time-series of water level were also compared. For the fixed timestep the results up to (and including) 90 seconds are very similar. However, for the simulations with a 120 second timestep, the travel time is delayed compared with the others. This can be seen in the figure below. The outcome of all of the above is that the model can comfortably run the model using a 60 second timestep (or even 90s timestep) without any accuracy concerns. Pushing the timestep higher than this will cause some differences in results. This is all pretty trivial with a short runtime, but for larger / longer models, the difference between a runtime of 3 hours and 12 hours, can be the difference in getting a project completed on time and causing a delay! In terms of negative depths these are also an indicator of model “health” and you may not need to reduce these down to the point where they don’t exist. They are reported as they are an indicator of where a model is overshooting the solution (which can occur with implicit schemes like TUFLOW which solves matrices, or with explicit schemes where the Courant condition is exceeded), or when a cell dries rapidly. Negative depth messages are excellent for identifying problem locations. The ones to focus on are "repeat offenders": ie. if a cell repeatedly and continuously has a negative depth (you’ll have thousands of messages at the one cell), then there is an issue at that cell (usually erroneous topography). If the negative depth warnings come and go (as is in this case) there may be no issue and they do not affect the mass balance of the system. It should be noted that the peak mass error reported in the tables above occurred very early on in the simulation when little volume of water was present, this rapidly diminished to 0. In this case there is no outflow boundary, and the final mass error is a much better indicator of the model mass conservation. In the example provided the timestep was set as a scenario, to make it easier to perform the sensitivity tests. The relevant .tcf section is presented below: If Scenario == FTS ! Fixed Time Step If Scenario == dt15 Timestep == 15. Else If Scenario == dt20 Timestep == 20. Else If Scenario == dt30 Timestep == 30. Else If Scenario == dt45 Timestep == 45. Else If Scenario == dt60 Timestep == 60. Else If Scenario == dt90 Timestep == 90. Else If Scenario == dt120 Timestep == 120. Else If Scenario == dt150 Timestep == 150. Else Pause FTS specified without dt parameter. End If Else If Scenario == ATS ! Adaptive Time Step Timestep == 1. !start with low initial timestep, this will increase to match Courant number If Scenario == cr05 Maximum Courant Number == 5 Else If Scenario == cr10 Maximum Courant Number == 10 Else If Scenario == cr20 Maximum Courant Number == 20 Else If Scenario == cr40 Maximum Courant Number == 40 Else If Scenario == cr60 Maximum Courant Number == 60 Else Pause ATS specified without max courant number. end if End if Finally batch files were used to run the simulations, the batch file for the Fixed Timestep Scenario is provided below. For more information on looping in batch files please see the following page on the TUFLOW Wiki http://wiki.tuflow.com/index.php?title=Run_TUFLOW_From_a_Batch-file. Set A=dt15 dt20 dt30 dt45 dt60 dt90 dt120 dt150 Set exe=C:\TUFLOW\Releases\2012-05\w64\TUFLOW_iDP_w64.exe :: Loop Through Each Courant Number FOR %%a in (%A%) do ( start "TUFLOW" /wait %exe% -b -t -s1 FTS -s2 %%a WBM_~s1~_~s2~_01.tcf ) Hope this helps and explains the logic behind choosing an appropriate timestep! Regards TUFLOW Support Team
  25. Q: It seems the when TUFLOW executes it only is using one core. Is there a parallel version that can be used across multiple cores? We have a 4 license dongles but are aware than only a maximum of 4 cores are in use when running. We have upgraded our modelling machine with 12 cores, so just want to make use of more cores. A: TUFLOW does not currently support parallelisation (cannot run on more than one core). The main reason for this is that TUFLOW is an implicit solution, which means that as it uses matrices to solve the 2D equations with information from the current timestep and from the previous timestep being solved simultaneously. Practically this means that parts of the computation can’t be spread over multiple cores because of the inter-dependencies. However, some sections of the code are not inter-dependent and we are looking to parallelise these sections over the coming year. To run more simulations on the computer, the licence could be upgraded for a local 4, to a local 8 or local 12, which would allow 8 or 12 concurrent simulations. Please be aware that if hyperthreading is enabled, there will be little benefit in using all cores. If the CPU is a hex core with hyperthreading enabled, this will show up as 12 threads, but physically only 6 cores are present going above 6 simulations the speeds will drop. TUFLOW-FV (our flexible mesh solver) uses an explicit solution and is parallelised (uses multiple cores). This allows a single simulation to be run on multiple cores in the same computer. However, explicit schemes tend to use a much smaller timestep. So for exactly the same number of cells, if not parallelised, this will be significantly slower. This engine supports 2D/3D, but does not yet have 1D elements embedded and as such is used more for coastal / estuarine modelling at this stage. We regularly run this on dual hex core machines (12 physical cores). The TUFLOW GPU module, pushes the computational load onto GPU devices (graphics cards) and use multiple cores (for example an nVidia Titan X has ~3,000 cores). Multiple graphics cards are also supported (e.g. 4 x Titan X). This is 2D only at this stage, but is showing great promise, particularly for very large models, where simulations may be up to 100 times faster. See the release notes for more information. Regards TUFLOW Support Team
×
×
  • Create New...