Jump to content
TUFLOW Forum

Search the Community

Showing results for tags 'ARI'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • About This Forum and Announcements
    • How to Use This Forum
    • Forum Feedback
    • Announcements
  • TUFLOW Modelling
    • 1D/2D Linking
    • 1D Domains
    • 2D/2D Linking
    • 2D/2D Nesting
    • 2D Domains
    • Boundaries
    • Documentation & Tutorial Model
    • Dongles/Licensing/Installation
    • Ideas / Suggestions / New Features
    • Mass Balance/Mass Error
    • MATH Errors & Simulation Failure
    • Restart Files
    • Post-Processing
    • Software/Hardware Requirements
    • Text Files (.tcf, .tgc, .tbc, .ecf)
    • Utilities
    • Miscellaneous
  • Other Software
    • ISIS-TUFLOW
    • MapInfo/Vertical Mapper
    • miTools
    • Other GIS/CAD
    • SMS
    • XP-SWMM2D
    • UltraEdit/Excel
    • TUFLOW Apps

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. There is guidance on how to apply blockage matrix as per ARR 2016 guidelines in the latest TUFLOW manual.However, the commands still require blockage factors as "Blockage ARI" and the matrix has ARI as an input column (section 5.12.6 of the TUFLOW manual 2018-03-AD). I was wondering if there were any plans to fully transition all commands and inputs from ARI to AEP. I believe it would add a bit more consistency to the modelling and will make it easier to reference things to clients as per ARR guidelines. At the moment, there are several different notations floating around everywhere in the industry. The blockage assessment tool provided by ARR conducts the assessment in AEP: http://arr.ga.gov.au/__data/assets/pdf_file/0011/40511/BLOCKAGE_ASSESSMENT_FORM.pdf The paper used for the matrix (Ollett and Syme (2016)) uses a combination of AEP and ARI: http://www.hydralinc.com/wp-content/uploads/Ollett-Syme-2016-ARR-Blockage.pdf The ARR guidelines seem to generally use AEP (Book 6, Chapter6): http://book.arr.org.au.s3-website-ap-southeast-2.amazonaws.com/
  2. Q: I would like to vary the magnitude and duration of events using variables so that I don't have to create separate tcf files. What is the appropriate use of 'BC Event Source ==' and can I specify a unique initial water level for each discharge? A: The “BC Event Source == “ command sets up a wildcard in the bc_dbase and replaces this wildcard with a second argument wherever it is found. In the following case: BC Event Source == _ari_ | 550 This is looking for a wildcard “_ari_” in the boundary database and where this is found this will be replaced by “550”. The wildcard you set is entirely up to you, but do make it something that doesn’t exist anywhere else in the boundary database. For example if you were to use “BC Event Source == a | 550”, it is likely that another “a” occurs somewhere in the boundary database! In the example above _ari_ was used to denote the Average Recurrence Interval. In the example below two wildcards are used: BC Event Source == _durn_ | 010min BC Event Source == _ari_ | 010yr This allows the event magnitude denoted by the average recurrence interval (wildcard = _ari_) and the event duration (wildcard = _durn_), to be varied independently. In this case we can run any combination of durations and return periods. In the bc_dbase, for boundary name “Local” the source is listed and includes both the _ari_ and _durn_ wildcards. For example when we run the 010min event for the 010yr event the source filename will become “rafts\Local_Flows_010yr010min.loc.ts1” Name Source Local rafts\Local_Flows__ari__durn_.loc.ts1 Note the wildcard can occur in either the filename or the header columns. The following are all possible: Name Source Column 1 Column 2 Inflow1 Inflows__ari_.csv Time Flow Inflow2 Inflows.csv Time _ari__durn_ Inflow3 _wildcard_ For inflow 1, the wildcard is part of the filename and could be replaced by for example 550cms and TUFLOW would look for a file called Inflows_550cms.csv and extract the data from columns “Time” and “Flow”. For Inflow2, this wildcard is in the header, for a flow boundary, this is the column to extract the flow data from. TUFLOW will open Inflows.csv and would extract the data from columns “Time” and “550cms” (if the event source was set to 550cms). This would allow all boundaries to be stored in the same file and use the same Time data. For Inflow3, a constant value is being specified. In this case the wildcard replacement would need to be a value “BC Event Source == _wildcard_ | 550”. If this was “550cms” this would cause an error about being unable to convert to a real number. This does not allow for a ramping up of the inflow and may cause stability issues. For the Initial water level, this can be set with the “SET IWL == “ command. For example: Define Event == 550cms BC Event Source == _flow_ | 550cms Set IWL == 149.9 End Define Define Event == 750cms BC Event Source == _flow_ | 750cms Set IWL == 149.9 End Define And finally, in the filenames you can use ~e1~, for the output and log files this will be replaced by the event. If you were to change the filename of your control file to TUFLOW_EXAMPLE_~e1~.tcf, When you run the outputs would become TUFLOW_EXAMPLE_550cms, TUFLOW_EXAMPLE_750cms… etc. As events and scenarios are also automatically classed as variables, wildcards can similarly be used in filepaths within your control files, using the following syntax for example: Output Folder == C:\TUFLOW\Results\<<ari>>\<<durn>>
×
×
  • Create New...