• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About TeeganB

  • Rank
  • Birthday

Profile Information

  • Gender

Recent Profile Visitors

239 profile views
  1. 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
  2. Hi Helen, What TUFLOW Build version are you using, and is it a GPU run? -Teegan
  3. 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.
  4. 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
  5. 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.
  6. 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
  7. 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