Jump to content
TUFLOW Forum

tuflow support

Administrators
  • Content Count

    142
  • Joined

  • Last visited

Everything posted by tuflow support

  1. Q: I am trying to generate the Zpts for a model which is about 20km wide and 12 km high. When I hit run the model crashes due to a lack of RAM. Is there anyway of knowing how much RAM is needed to get it to run or ways for it to us less RAM when it generates the points. Currently the computer has 2GB of RAM. A: Check the .tlf file and search for "memory". It should get to a point where it has worked out how much memory is required for the 2D domains. If the amount in the .tlf file starts to exceed 1.5Gb, then you'll have problems (Win32 struggles with any single process exceeding 2Gb noting that in addition to the amount in the .tlf file there are additional amounts needed for the .exe process and other memory needs). If your machine only has 2Gb RAM, have IT check that you have adequate virtual memory allocated to extend RAM requests by at least another 2Gb. Note however, as soon as your computer goes over 2Gb in total RAM requests (noting that Windows can be consuming a large chunk of this) it can become very slow as it is continually swaping information between RAM and the HDD. Also make sure you have no other processes consuming lots of RAM, ie. close everything else down. Use Task Manager, Performance and Processes tabs to monitor the situation (a good tip is using View, Select Columns... under the Processes tab, add "Peak Mem Usage" and "VM Size" as these will give a better picture as to which processes are using up your memory - click on the column to display in ascending/descending order). If you are going to construct large models, 2Gb RAM is probably insufficient, especially if you want to have other processes such as a GIS open as well. Also check you've set up the /3Gb switch when booting - see Section 9.3 of the 2008 TUFLOW manual and http://www.tuflow.com/forum/index.php?showtopic=519. You can reduce TUFLOW's requirements for temporary RAM using the "Maximum Points" and "Maximum Vertices" commands - see the 2008 TUFLOW manual. This may help if you're on the edge!
  2. Q: We are trying to generate a UK Hazard map using the UK Hazard Formula. Unfortunately, the TUFLOW does not recognise this formula and it crashes reporting an error message: ERROR 2131 - Reading parameter(s) or option for .tcf command below, or command is ambiguous. Line = UK Hazard Debris Factor == DF A: ERROR 2131 means that TUFLOW does not recognise or cannot interpret the command shown after "Line =". In the above case you have set the value of the debris factor to "DF", when it should be a number (eg. 0.5). In the TUFLOW manual, if the option is enclosed by "<>", this means that you need to enter a value. For the above the manual quotes the command as: UK Hazard Debris Factor == [ <DF> | {1} ] Because DF is enclosed in "<>", you need to enter a value for DF. FYI, the value or keyword enclosed in "{}" refers to the default value (ie. 1 in the above case). Other common reasons for ERROR 2131 are: specifying only one "=" instead of two "=="; a typing error; or having two or more spaces between words. Always good practice to cut and paste from the manual or another control file.
  3. Q: I'm getting this error with the Read MI Z Shape: Error 2226 - Multiple region objects not supported for Read MI Shape commands I've attached the zsh files. A: The Z Shape region contains a hole within it (see attached). When a region has a hole in it MapInfo treats this as a Multiple Region object (there are actually two polygons, one for the outer perimeter and one for the perimeter of the hole). To resolve this, split the polygon into two (for example at the black lines in the attached image). Some of the miTools functions are excellent for this. You may also need to Objects, Disaggregate... any regions still containing more than one polygon after splitting. You can check whether a region is made up more than one polygon by double clicking on the region and viewing the number of polygons.
  4. Q: My understanding is that stage boundaries are normally only used as downstream boundaries, with flow boundaries used to put flow into the 2D domain? Is it acceptable to derive HT boundaries along an embankment using a 1D solution and use this as inflow to the 2D domain? I’m not sure about the validity of this. The downstream boundary is also a 2d_bc HT boundary. A: The preferred approach is to use flows for upstream boundaries, and water levels for downstream boundaries. The problem with having water level boundaries upstream and downstream is that nowhere is the flow defined. The modeller is relying on the flow generated across the upstream water level boundary to be a reliable approximation. The flow generated is, however, very much a function of the Manning's n values and other influences. Without good calibration data it is difficult to support the logic of using an upstream water level boundary (you really need water level time histories throughout the model to check that both the timing and the shape/volume of the flood wave are adequately reproduced). Sensitivity testing of different n and other values is also a good idea to ascertain the sensitivity of the generated flow to uncertain parameters. We have successfully used an upstream water level boundary for calibration events where there is a good recorded stage hydrograph and uncertainty over the existing rating curve. This has typically been on very large river systems where a hydrologic model is not feasible or does not provide the accuracy required. The approach was to calibrate the model using the recorded stage hydrograph as the upstream boundary, then use the flows generated across the boundary to derive a more accurate rating curve that can be applied to other events. If using upstream water level boundaries, the bottom line is whether the flow being generated across the boundaries is appropriate. Look closely at the flows across the upstream boundaries (digitisie 2d_po Q_ lines one or two cells in from the boundaries), and validate these flows using desktop calculations or alternative modelling. There could also be concerns that by not having the in-bank (presumably the 1D) flow dynamically linked with the flow over the embankments into the 2D there would be added uncertainty (if anything the 1D water levels are likely to overestimated, which would in turn overestimate the flow into the 2D, ie. give a conservative outcome).
  5. Q: I'm running a model which has a common 1D component across several events. To cut down on managing excessive files, all my .tcf files point to a single .ecf file: ESTRY Control File == Common_1D.ecf The .ecf file contains commands to read in a 1d_nwk (with S channels), 1d_tab (with XS and NA tables), and 1d_bc layer (with QT and CN boundaries). The model runs fine, except if I try to run two events at the same time, I get the following error message: forrt1: severe (47): write to READONLY file, unit 538976288, file J:Jobs\27036-02\TUFLOW\runs\fort.538976288 The offending file is attached [not attached to this post however]. It appears that TUFLOW is writing out some cross-section information to the fort.538976288 file for later use, and then the second run tries to write to the same file but can't because it is "owned" by the first TUFLOW process. Is it essential that ownership of the file be maintained during the run? It seems the problem might be solved by simply cleaning up the first "fort" file once pre-processing is complete, or by writing the file to the results directory instead of the run directory, or perhaps by using a different naming/FID convention so that each run gets a different temporary file. A: You're approach to utilising the "Read File" command to minimise the number of .ecf files should work fine, except as explained below. FYI, the fort.XXXX files are not created by TUFLOW, rather they are a dump from the exe process if something goes wrong. The dump you provided shows check file output, so the only known reason that this might occur is if your check files are being written to the same name. This occurs if there is no backslash at the end of "Write Check Files ==", for example, the line Write Check Files == ..\check\1d will prefix all check files with "1d" and write the files to the "check" folder. Therefore, if you have two simulations starting up at a similar time, they might both be trying to write to the same check file. If this is the case, to resolve the problem either comment out the "Write Check Files ==" line (both .ecf and .tcf files) so that no check files are written, or place a backslash at the end. For example, the line Write Check Files == ..\check\1d\ in the .ecf file will place all 1D check files in a folder "check\1d" and prefix each check file with the .tcf filename so that they are unique. The same applies to the identical .tcf command. If this isn't the reason, please get back support@tuflow.com.
  6. Q: I’m trying to run Build 2007-07-BD (for a previous model) and cant get it working when I double click the .exe file. And when I try to run the model it gives: ERROR - Dongle is invalid for this build or model, or is unmaintained. Please contact support@tuflow.com and provide dongle details above. (NOTE - Model specific dongles can only be used on that model.) A: For that dongle (U0808) you'll need to be running Build 2007-07-BE or later (see http://www.tuflow.com/Release_Notes_2007_07.htm). You can download the latest 2007 build (BH) from http://www.tuflow.com/Downloads_TUFLOWExe.htm. These later builds should give identical results to previous 2007 builds.
  7. Q: We are having issues trying to run TuFlow software [build 2006-06-CC] on one of our PC's here in the office. Whenever the application is loaded, an error message displays "Premature EXT of TUFLOW Simuation" (See Attached Screenshot [not uploaded]) I have remote accessed the users PC - Restarted machine & application - This did not solve the issue I have attempted to run the application as local admin, but the same thing occurred. A: This is a characteristic of the 2006 and previous builds (later builds terminate with a more appropriate message). When just double clicking on TUFLOW.exe, the DOS window indicates whether a TUFLOW licence is valid or not for that build of TUFLOW, the available modules, and then terminates after displaying a message dialog. To carry out a TUFLOW simulation see Chapter 5 of the manual. Please note that TUFLOW.exe is only a Console (DOS) Application, and what you are seeing is as expected and that your licence is valid for that build.
  8. Q: When I am using HQ boundary in the d/s node and assigning relationship in the boundary correctly, the check file reads in the reverse order i.e. flow as water level and water level as flow. Probably this could be a bug. Can you please look into if it is so? A: Yes, it's a bit confusing in that you must specify the columns in the reverse order to the boundary letters. Therefore, in the bc_dbase.csv file for a HQ boundary Column 1 must be flow (Q) and Column 2 water level (H). Similarly for a HT boundary the Column 1 is time (T) and the Column 2 is water level (H). If you swap the Column 1 and Column 2 labels around for your HQ boundary in the bc dbase file it should work fine.
  9. Q: We're having a few problems with the installation. Our IT manager logged onto the server, where the dongle is attached and followed the instructions in the manual. At this point we can see the dongle. However, when he logs off from the server we cannot get access to dongle - see his comment below. "As soon as I log off from the server the process that manages the dongle (VSServer.exe) stops. It’s not going to work until I log back on and start the process up again. If this process ran as a service then it would run independently of any user sessions so would start as soon as the server boots. All the network software we currently run (AutoCAD, Plaxis, Windes etc) use services so all the software is available immediately when the server boots. If should be fairly easy for them to convert the exe file in to a service. Is this possible or do you have to have an administrator constantly logged into the server where the dongle is installed or are we missing something during the installation. Any thoughts?" A: The server machine has to be up and running at all times. It doesn't require an administrator to be logged in, but probably someone has to be logged in. As long as the "Security Server" program has started - you set this up to start every time someone logs in by placing a shortcut to Security Server in the startup folder (eg. C:\Documents and Settings\All Users\Start Menu\Programs\Startup). This way, it should always be running. A good tip is to not have the "Show starting window" ticked in the dialog below (you can bring this up by clicking on the red and yellow icon in the icon tray). Note that with the 2007 release onwards the Security Server can be stopped and restarted even if there are TUFLOW simulations underway. The active TUFLOW simulations will retake their licenses once the Security Server is up and running again. A: (from dongle providers) We have looked at running the security server as a service but there were some technical problems with this so we decided in the end to leave it as an exe. This does unfortunately mean that a user needs to login for it to work though. I did find this page about running exes as a service which may work. When we tried to create the service originally it was with NT so perhaps things have changed http://support.microsoft.com/kb/137890
  10. Q: What strategies do you use to improve results when linking 2D domains? On the lines that join the domains there is an attribute to adjust the storage multiplier. How do you use this value in your models? A: At each vertice along the 2d_bc 2D link line (and any automatically inserted vertices using the d maximum distance attribute) a "hidden" 1D node is inserted. The 1D nodes act as storages that convey the water from one 2D domain to the other. The most important aspects of the 2D linking are: 1. The water levels along the 2d_bc 2D line are linearly interpolated using the water levels in the hidden 1D nodes. If the water level profile in reality is not close to being linear between vertices, then weird flow patterns may occur. So it can be wise to avoid areas of rapidly changing water level. Where there are significant changes in water level, for example such as across a road embankment, the location of the vertices can be very important so that a 1D node is inserted either side of the embankment centreline. 2. It is tempting to simply specify a d value the same or smaller than the larger 2D cell size. Unfortunately this can create many very small (in storage) 1D nodes that can be quite unstable. In general terms, the rule-of-thumb is to not specify a d value less than 2 or 3 times the larger 2D cell size. 3. Increasing the a attribute value so as to increase the storage of the hidden 1D nodes may help, but this should only be done if it can be demonstrated that the increase isn't unacceptably attenutating the results as this is effectively adding storage to the model. Values for a of up to 5, possibly 10, are usually fine, particularly in conveyance dominated models. 4. Build 2008-08-AE introduced a new .tcf command "Link 2D2D Approach == Method B" that we have found improves the performance of the 2D linking. This approach will become the default in the 2009 release (unless further improvements are made). See http://www.tuflow.com/Release_Notes_2008_08.htm#5 for more info. 5. A large change in 2D cell size from one domain to the next can sometimes not work well. For example going from a 100m cell size to a 10m cell size. 6. The 2D linking can be problematic in very deep water (we believe this is due to the very large volumes of water than can flow into/out of the 1D nodes with only a very very small water level difference across the 2D link line). 7. For those interested, the storage of the linked 2D cells (see the 2d_2d_check.mif layer) is not used computationally and this storage is applied to the hidden 1D nodes. 8. For those really interested, you can see in the check layers and in the results the hidden 1D nodes by specifying the undocumented .tcf command "Reveal 1D Nodes == ON". This can be useful for helping to understand a problematic link. Anyone else's experiences are most welcome.
  11. Q: We are having a problem running Build 2008-08-AG – an error comes up saying “C:\ ; Above folder does not exist! Create?” . The problem occurs using both the single precision and double precision versions. The problem does not occur when running Build 2008-08-AF (the file structure is setup the same way plus tcf / ecf are the same etc). A: Build 2008-08-AG onwards includes a new check on the availability of C:\ to write the global "_ TUFLOW Dongle XXXXXXX Simulations.log" file. If you don't have write permission to the C:\ folder, the above message will now occur (whereas in previous builds the file was simply not written). The solution is to use the -slp option to set a folder that you do have write permission to onto the dongle. For example, if you type the below in at a DOS prompt or place in a .bat file and double click the .bat file, it will set the global simulations log folder to "C:\Program Files\TUFLOW\log" for the current dongle. TUFLOW.exe -slp "C:\Program Files\TUFLOW\log" (make sure you use a minus sign in front of slp and not a long dash) If the folder specified does not exist, the next time you run a simulation, you will be prompted if you want to create it. A URL somewhere on you intranet can also be specified - see Table 5.2 in the 2008 manual for more info. Build 2008-08-AG does include a new .tcf command "Simulations Log Folder ==" to set the path to where the global simulations.log file is written to as an alternative to using the -slp option above. However, it is strongly recommended that the -slp option be used so that all simulations for that dongle are written to the one log file (this can be invaluable later on when trying to determine what models were run on which builds, etc, etc). The -slp feature is particularly useful for network dongles.
  12. Q: I would like to enquire about if Tuflow can directly read in RORB's flow time series output as it can read in Rafts' flow time series. If not, is there a utility affiliated to Tuflow that can help the process? A: TUFLOW at present (2008-08) can't read RORB files directly, but RORB output can be converted to the .ts1 format using convert_to_ts1.exe (see Section 11.7 of the 2008 manual). Also see the BC Database Source keyword in Table 4.26 of the manual. The .ts1 format has advantages in that it is fast to process when running TUFLOW, and is a comma delimited format (.csv) so you can also load it into Excel (you may need to change to extension fo .csv).
  13. Q: I've noticed that is possible to run a number of TF simulations in parallel. On my quad core PC I can run up to four simulations without compromising the run time of the parallel simulations. Is it possible to run models in parallel like this using a batch file? From what I can see in the manual batch simulations typically work in series. A: If you use the start command without the /wait option this will kick off that simulation and immediately proceed to the next. For example the lines below will kick off two simulations in parallel. start "TUFLOW" /low "C:\TuflowEstry\Tuflow\Release\Intel\TUFLOW.exe" -b a.tcf start "TUFLOW" /low "C:\TuflowEstry\Tuflow\Release\Intel\TUFLOW.exe" -b b.tcf pause If you want to control what happens after these simulations are finished you may have to nest .bat files within .bat files to maximise your processors such as the below (this needs to be tested): start "Block 1" /wait block1.bat start "Block 1" /wait block2.bat pause
  14. Q: I am currently setting up a TUFLOW only model using the latest version of TUFLOW. The model boundary is very large and when it is run large results files are created in excess of 2GB. Currently I only have a demo version of SMS version 9.0. When the results are loaded into SMS I can only see the elevation. As a test I tried running the model for a shorter duration, which produce smaller results files and these opened without a problem. Is there any way to view the large results files using the demo version of SMS? Also, what is the file size limit which the demo version of SMS can open the results? A: Yes, SMS (and other software), can fail when files exceed ~2Gb on Win32 machines. It is not due to SMS being run in Demo mode. Suggest reducing the frequency of the map output (see link below), or optimising the number of active (Code 1) cells (inactive Code 0 cells are not written to the output files, but note that inactive Code -1 cells are so if you have any Code -1 cells, change these to Code 0). We've nearly finished incorporating a new XMDF (HD5) output format which is much faster to load up than the .dat files, and I believe doesn't suffer the 2Gb problem (need to confirm this) for the 2009 release. SMS and other software (eg. Matlab) recognise this industry standard. I suspect that if using a 64bit machine the 2Gb problem doesn't occur. Note that it's possible to use the post-processing utilities such as TUFLOW_to_GIS.exe to process .dat files greater than 2Gb, and view the results in GIS. Also see: http://www.tuflow.com/forum/index.php?showtopic=127
  15. Q: I am currently having some problems running the tuflow program with regards to the downstream boundary condition. I have been racking my brains trying to sort it out but I was hoping that you guys had run into the problem previously with somebody else. Everything seems to run fine until the program needs to try and compute the automatic downstream HQ boundary in which the error reads "XY: ERROR 2194 - Column 1 values not ascending in HQ table". A: The problem is being caused by your first HQ boundary in that the lowest to highest elevation along your HQ line is just one metre, and the flow estimated is coming out as repeatedly zero (when rounded to 3 decimal places) for the first elevations in the automatic HQ curve (see end of the 2d_bc_table_check.csv file), hence the flow is not "increasing" with elevation. If you extend your HQ line to cover a higher height range, this should solve the problem. The automatic HQ curve uses 100 points, so if the height range is very small, the increase in flow from one H level to another may end up being "zero", hence the ERROR 2194 message. Note that we have made a note to review this check for a future release.
  16. Q: My run keeps crashing with the following message, have you got an idea what it is about? I can't figure it out Reading Read MI Code BC File: F:\..............\model\mi\2d_code_Bil_003.MIF ERROR 2148 - Reading line in MID file or premature end of file. Line Number = 1 A: Error 2148 means that there was a problem reading a .mid file. A couple of reasons are as follows: 1. The command and the type of mif/mid layer are incompatible. This is the case above where you are using a "Read MI Code BC ==" command to access a 2d_code layer. "Read MI Code BC ==" is designed to read code polygons from a 2d_bc layer, not a 2d_code layer as you have specified. 2d_bc layers have a different attribute set than a 2d_code layer, hence why the error occurred. Change the command to "Read MI Code ==" and it should work fine. 2. Other reasons are if the .mid file has got corrupted or has been edited/changed so that the attribute data has become incompatible with the original data. (Some users carry out modifications to the attribute data using Excel by changing the .mid file to a .csv extension and double clicking on the file to open it in Excel.)
  17. Q: I am getting a fortran error half way through my tuflow run, when linking with ISIS about half way through. It is a visual runtime error stating "access violation. Stack trace terminated abnormally". My version of ISIS is 3.0.1.29 with TUFLOW build is 2008-08-AB-iSP. A: I suspect you need to upgrade to ISIS 3.0.2 - please see http://www.tuflow.com/forum/index.php?showtopic=319
  18. Q: I am currently trying to write and run a batch file to set a couple of models running over the weekend. I have followed the example in the manual but and running the batch file opens up tuflow, however, tuflow then prompts me to enter in the name of the .tcf file, which kind of defeats the purpose. the test line of code I am using in batch file is as follows (excuse the long file paths): C:\tuflow\TUFLOW.2008-08-AB-iDP\TUFLOW_DP.exe -b D:\Current work\Current work\Rildley_ver2\tuflow\runs\Project models\RR Q10 model incl surge\Q10_RR_surge_project.tcf pause I have tried copying the tcf into the same folder as the Tuflow.exe but the result is the same I am prompted for a tcf file name. I figure I must be missing something pretty basic or simple and it'd awesome if you could let me know what it is as soon as possible - would love to be able to run multiple models over the weekend (oddly enough if I do initiate multiple models the normal way each tuflow window now only seems to retry for the dongle for finite amount of time, so it seems I can't do it that way). would appreciate any input. A: You need to include quotes ("") around the pathname to the .tcf file because it has spaces in it. Also note that if the pathname to TUFLOW.exe has spaces in it this also needs to be quoted. The line below should work fine. Another useful tip is to use the -t option (this tests the input data is all there, but won't start the simulation) before you use the -b option so as to make sure that all of your runs startup OK. "C:\tuflow\TUFLOW.2008-08-AB-iDP\TUFLOW_DP.exe" -b "D:\Current work\Current work\Rildley_ver2\tuflow\runs\Project models\RR Q10 model incl surge\Q10_RR_surge_project.tcf"
  19. Q: I am about to perform a breach analysis in a ISIS-Tuflow 2008-08 iSP format. I need to trigger my beach at a specified water stage in the 1D (ISIS). What I am thinking of doing in the 2d_vzsh Attributes is: - Shape Options: TRIGGER - Trigger_1: a point in the _1d_to_2d_check file, i.e. the relevant BC cell (picked by the 2D HX Line and therefore having Flags:2, 2D Link:HX, 1D Link:QX) ---> is this doable and the correct way of picking the trigger WL from ISIS? - Trigger 2: blank - Trigger_Value: the water level that trigger my breach as instructed Is this the correct way of doing it? A: Yes, that should be possible (that is to trigger based on the water level in a HX cell, ie. the interpolated water level between ISIS nodes). If you are lowering the HX cells you must be careful that the level of the HX cells does not fall below the interpolated bed levels of the ISIS units - there is a check for this when you start the simulation, but there is no check (at present) during the simulation. If the HX cell falls below the 1D bed, this can generate flow if the ISIS units become dry. Note there is an improvement in Build 2008-08-AC (should be uploaded this week) that does adjusts the IWL of 2d_vzsh cells that are dry when the breach commences (at present the IWL is set to the dry cell level and is not adjusted as the cell is lowered, thereby leaving a perched water level that creates flow).
  20. Is your 2d_zpt layer on a network drive because reading the 2d_zpt layer(s) across a network can be VERY slow. Modellers often place the larger input layers on their local drive and read from there. This may also be relevant for the 2d_mat layer if it contains a large amount of polygons. If the 2d_mat polygon processing is the slow part, you can setup the materials in a similar manner to Zpts (ie. use a Read MID Mat command rather than the Read MI command). To do this, select all ZC points from the 2d_zpt_check.mif layer, save the Selection as a 2d_mat_pt layer, remove the Type attribute and replace the Elevation attribute as Material of type Integer (ie. there should be three attributes n (row), m(column) and Material). Using MapInfo's Update Column... dialog assign the material values at each point by setting a join where the 2d_mat_pt point falls within the 2d_mat polygon layer. Alternatively, if you have or can create a VM grid of the materials, you can do a Point Inspection on the 2d_mat_pt layer. Note that if using Read MID Mat ==, then the .tcf command Bed Resistance Cell Sides == AVERAGE M or AVERAGE n will need to be used. On the R&D list is to offer a binary dump of the input data which can then be used as a binary read - this will be very fast. If it is the 1D input that is slow, this will be greatly improved by the binary read option. Out of interest, how long is your simulation taking to pre-process?
  21. Q: When I went to inspect the check files to ensure the block-out had indeed occurred I found they had not been saved as expected? Does Tuflow periodically overwrite check files from time to time? Alternatively is there anyway you can inadvertently prevent the check being generated? A: For the .tcf Write Check Files == command, there is a subtle difference depending on whether the last character is a "\" or not. If the last character is a "\", the check files are all prefixed with the .tcf filename, and therefore every simulation will have its own set of check files (remember to delete these from time to time as they will quickly fill up your HDD!). If you don't have a "\", the check files are all prefixed by the last part of the pathname. These check files will keep being overwritten by other simulations using the same Write Check Files pathname.
  22. Q: For irregular culverts, I don't think the pBlockage factor works (contrary to what the [2008] manual says). Skewing like a bridge appears to work fine though. A: Yes, that is correct, the pBlockage attribute in Table 4.12 of the 2008-08-AA Manual is incorrectly stated as being applicable to I channels. I channels are treated the same as for B and W channels, ie. this attribute is not used. And yes, using the new 1d_tab (1d_xs) Skew attribute (Table 4.15) is an easy way of partially blocking a cross-section for B, I or W (and other) channels. The manual has been corrected and will be uploaded with the next patch.
  23. Q: I have been trying to use the new variable shape for a breach scenario. To start with, I did not apply any head boundary behind the defence and just outputted the Z values to see the change of topography. But it seems, the initial water level translates into flow due to the collapse of the wall. I remember I had the same problem with the early versions of VG tables. A: Yes, that's an interesting one. The initial water level in an initially dry 2D cell is set at the ZC level plus the wet/dry depth (default 2mm). If the Variable Z Shape starts changing the elevations of a dry 2D cell the initial water level needs to be adjusted downwards as well (whilst the cell is dry). We'll look into adding in this feature as a patch to the 2008 release.
  24. Q: Regarding the bc database set-up, how do I save the individual worksheets as .csv and retain these within the parent/host bc database.xls worksheet - as shown in in Chapter 4.10 of the Tuflow manual? Is it necessary to have them saved in this format? I’ve tried using the Tuflow tools.xls download and that seems to create individual .csv files outside of the parent worksheet. A: The best way to work is probably the way you're doing it, ie. to have a spreadsheet that contains the bc_dbase sheet (usually the first sheet) and other sheets that contain the time-series data referenced by the bc_dbase sheet. To export these to .csv format, use the Save csv tool in TUFLOW Tools.xls. Unfortunately, you have to do this one sheet at a time (we need to look into providing an option for the TUFLOW Tools macros to export all sheets as .csv files). TUFLOW can't (yet) read .xls files directly, hence the need to export to .csv files. Using a .xls spreadsheet to manage all of the data instead of directly working with .csv files keeps all of the data together and allows you to have charts and other information stored within the one file. You can also place charts etc on the sheets that you export to .csv (Excel only exports the tabular data when saving to .csv). The downside is that you must remember to press Save csv (ie. export to .csv) if you change the contents of a sheet, otherwise TUFLOW won't know about your changes. Also see http://www.tuflow.com/forum/index.php?showtopic=268
  25. Q: I am having a problem mapping the 1d flood extent within a 2d domain using Tuflow_to_GIS. There is a discontinuity in the map at each junction in the network. Is this a known problem or are we doing something wrong? A: It is most likely that when TUFLOW has created the 1D WLL triangles that it is getting confused as to which is the main channel due to the junction, and has not created triangles in the area not appearing as being mapped. In these situations it is best to use Connectors ("X" Channel_Type) to distinguish between side channels and the main channel. This also helps the 1D WLL mapping and also application of cross-sections at channel ends. In the image you supplied, I have shown how you would connect the side channel to the main channel using a connector (red arrow - note the last side channel would have to be shortened). The WLLs (black arrows) could now be digitised so that there is a WLL at the end of the last side channel and ones progressively along the main channel. You can also have WLLs anywhere along a channel (see grey arrows as examples) which may help with the 1D WLL triangulation, particularly around bends. A good tip is to view the triangulation created by the WLLs by using SMS and showing the elements (see the Mesh tab under Display Options), or using TUFLOW_to_GIS.exe -mif <file>.2dm (this should create a .mif file of the 1D WLL triangles and 2D cells). Also make sure you digitise the the WLLs left to right looking downstream otherwise overlapping triangles can occur between WLLs. For more info on how WLLs are created and the protocols for setting water levels along WLLs see Section 4.11 of the TUFLOW Manual. Note that WLL Method A is not supported anymore and that older versions of TUFLOW have reported bugs in regard to triangulation of WLLs.
×
×
  • Create New...