TeeganB

Administrators
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About TeeganB

  • Rank
    Member

Profile Information

  • Gender
    Female

Recent Profile Visitors

274 profile views
  1. Q: "What are some suggestions for checking direct rainfall boundaries have been applied to my model correctly? For example, I wanted to verify that the correct rainfall depth of 90 mm was applied across the model. I divided the “total volume in” by the total area of active cells, and came up with only 72mm. I cannot track how the histogram relates to the hyetograph." A: There are a number of things that can be looked at, depending on the type of rainfall boundary being applied, and if rainfall losses are applied to the model. Rainfall losses applied through the Materials Definition file (.tmf or .csv format) removes the loss depth from the rainfall before it is applied as a boundary on the 2D cells. Soil infiltration losses however remove water from wet cells, after the rainfall source has been applied. Is the model health (mass balance, negative depths etc) acceptable? If using TUFLOW classic (as opposed to TUFLOW GPU) direct rainfall models should be run with double precision and the recommendation is to lower the cell wet / dry depth to 0.2mm. For 2d_rf boundaries, the rainfall time-series data must be in mm versus hours, and is converted to a hydrograph to smooth the transition from one rainfall period to another (the converted hydrograph is reported in the .tlf log file for cross-checking). After subtraction of rainfall losses, this is applied to the model cells as a source volume. The Map Output Data Types RFR and RFC (see Table 9-10 of the 2016-03-AE TUFLOW Manual) may be used to view the rainfall rate (mm/hr) and cumulative rainfall (mm) over time respectively. As these are model outputs, they are inclusive of the rainfall losses and any adjustments made in the BC Database (eg. multiplication factors/time shift). For rainfall grids generated from point rainfall data with a Rainfall Control File .trfc, the rainfall control file is processed during model initialisation and a series of rainfall grids are output, which are then used by the simulation to vary the rainfall over the 2D domain(s). This feature may also be useful simply to generate the series of rainfall grids for other purposes or display. The rainfall grids are pre-processed to reduce memory usage whilst TUFLOW is running. Whilst there isn’t a specific check file for the rainfall distribution when using generated rainfall grids, another advantage of the pre-processing of rainfall grids is that they can be interrogated prior to the end of the simulation to allow for checks. Note that the generated rainfall grids are inclusive of adjustments made in the BC Database (e.g. multiplication factors used for climate change) and of adjustment factors in the input GIS layer’s attributes, but because they are an input to the model, they are not inclusive of rainfall losses that may be specified in a materials file. Again, the Map Output Data Types RFR or RFC can be specified, these are inclusive of the rainfall losses, however these results are output as the simulation progresses. To confirm the rainfall losses applied across the model, use the grd_check file with the Materials Definition file .tmf.
  2. Hi, The configuration you described would be used where you have a 2d_bc layer which has elements defined for the boundary conditions, as well as for defining the active code. If you look in the layer that both commands are referencing, is there a polygon with a "CD" type attribute and a value in the f attribute? This indicates the polygon is for defining the active code. The "Read MI BC==" command in the TBC only reads the boundary condition elements. The "Read MI Code BC ==" command in the TGC only reads the code element (specifically from a 2d_bc layer). So if you have updated elements of both boundary conditions and code in the one file, but only updated the reference in your TGC, then the new code will be applied, but not any changes to boundary conditions that may be included in the same file. If your 2d_bc_code layer only contained code information, then the command in the TBC will essentially not be doing anything, because there wouldn't be any boundary condition information to read. An alternative configuration is to separate the two element types so that you have a 2d_bc layer that contains only boundary condition information, and then make a 2d_code layer (different to 2d_bc) that contains only the code information. Note that the 2d_code layer must then be used in conjunction with the alternative "Read MI Code ==" command. Please review Section 6.7, page C-7 & C-8, and the "CD" Type under Table 7.4 of the 2016-03-AE TUFLOW Manual. Let us know if you need further clarification. -Teegan
  3. Hi Helen, What TUFLOW Build version are you using, and is it a GPU run? -Teegan
  4. Hi Francis, We'll likely need more information to be able to help out with your above issue. What TUFLOW Release Build are you using? A CPU or GPU simulation? Is there an initial water level set at the tailwater boundary? Could you please send an email through to support@tuflow.com with the above info and a copy of your TLF log file to begin with. We will probably need to look at a copy of your model or some input files, but we'll take a look at your TLF first.
  5. Hi All, A fix for the above issue has been included in the latest TUFLOW update (Build 2016-03-AE). Please see Item 167 of the release notes. Cheers, Teegan
  6. Thank you for the further information. The above issue has turned out to not be isolated to Override files and can in fact occur in any control file. Currently, if a scenario (or event) variable occurs in any line, there must be a value specified for it, regardless of whether or not that line occurs inside an active scenario/event block. Your use of something like -s2 DUMMY (or even just "_") as per above description is a good work around for the time being. Assigning a “dummy” name will be required for all scenarios/events which are not intended to be active, but which are referenced as variables anywhere in the control files. This had been added to TUFLOW’s development list.
  7. Hi, Generally TUFLOW's Override Files are intended for the more simple commands such as output drive, number of GPU, check files etc. We might need a bit more information to understand what you are trying to do. Are you able to please post what your Override File looks like? I can then follow up with TUFLOW's developers to check specifically if what you are trying to do should be possible or not. I believe that calling scenario wildcards should still be allowed e.g. Output Folder == results\<<~s1~>>. Cheers, Teegan
  8. Apologies for the delayed response here. Daniel please see Item 62(b) of the TUFLOW Build 2016-03-AC Release Notes providing the following correction to the 2016-03-AA Manual: "A normal flow boundary in the GPU Solver is not activated by having the HT boundary level below the ground level. A normal flow boundary is invoked in the GPU Solver by specifying an automatic HQ boundary as per TUFLOW Classic. This is done by assigning a blank Name attribute in the 2d_bc layer, and the “b” (slope) attribute needs to be non-zero, although the slope value is not used by the GPU Solver. The GPU Solver assumes uniform flow based on the ground slope of adjoining cells. This feature may also be invoked by specifying a HT boundary with a water level of -9999. Note: the assumed water levels at these boundary cells are not presently output and the cells may appear as dry or with very low levels. Also the water levels at the common cell corners of adjoining active cells may be incorrectly low in the output. Improved output at automatic HQ boundary cells for the GPU Solver is planned for the next update." Sam I'll contact you through TUFLOW Support, I might need a bit more information on your problem. Cheers, Teegan