BRAT comprises three separate processes that are run in order. Operations that involve data that change infrequently and also don't involve human judegment are broken out into their own process. This avoids unnecessarily performing time consuming processes on data that hasn't changed. Conversely, the third step is designed as a separate process because it requires the selection of hydraulic equations and vegetation suitability, which is subjective and might change over time.

1. Riverscapes Context

The first step is not actually BRAT related at all. The Riverscapes Context step is a GIS housekeeping exercise to obtain and organize all the necessary layers required to run BRAT. It collects together several geospatial datasets that are useful for understanding riverscapes (the channel, its floodplain and valley bottom). The goal is to reproject the data onto the same spatial reference (WGS84), clip all the layers to the watershed boundary and organize them within a riverscapes project.

For users in the continental United States we have automated this process for eight digit hydrologic unit (HUC) into the rs_context.py script. This script downloads most of the data from the relevant USGS sources and builds a riverscapes context project for you. If you're using BRAT outside the continental United States then you can skip this first step, but you are going to need many of the layers used in the Riverscapes Context project for the next step. See the instructions for international users.

Note that this first step does not involve any parameters or human judgement. There are no decisions to be made. It's simply gathering and organizing BRAT input data. For an eight digit HUC in the continental United States this process takes approximately 50 minutes.

2. BRAT Build

The BRAT build process creates a new BRAT project by performing the following operations:

1. it creates a new, empty folder and copies into it all the relevant layers needed to run BRAT.
2. it makes a copy of the channel flow lines and segments these polylines at the specified length (being careful not to create any lines less than a specified tolerance). These flow lines are copied into a SQLite database that becomes the centrepiece of the BRAT project.
3. Writes the riverscapes project file containing the necessary metadata.
4. Finally, several rudimentary attributes are extracted from the GIS layers for each reach such as slope, drainage area and vegatation within the specified buffers.

The end result of this step is a partially complete BRAT project that has all the relevant GIS layers to run BRAT as well as the SQLite database. The reach information is also copied to a ShapeFile that can be viewed in GIS software. At this stage there are no output values (e.g. dam capacity or conservation) in the SQLite database or ShapeFile. The only columns that are present and populated at this point are the geophysical properties extracted from the GIS layers during the BRAT Build process.

For an eight digit HUC in the continental United States this step takes approximately 5 minutes.

3. BRAT Run

The final step is to actually run the BRAT model! This is separated into its own operation to make it extremely fast. Users typically want or need to repeat this process, tweaking the model parameters iteratively until they are satisfied with the results. This involves applying human judgement in three ways:

• Vegetation suitabilities stored in the database are applied to the buffers around each reach for both the existing and historical vegetation conditions.
• Low and peak flow hydrological equations for the watershed are applied to each reach to calculate discharge and stream power.
• The maximum drainage area threshold is applied that overrides the dam capacity for reaches with high flows in which beaver are unable to maintain dams.

Each of these three parameters can be adjusted and BRAT rerun quickly to assess the output. This final BRAT Run step does not involve any lengthy geoprocessing. An eight digit HUC in the continental United States takes approximately 1-2 minutes.

The process updates the existing BRAT project that was created during the BRAT Build step. It does not produce a new or separate copy of the project. Moreover, BRAT currently only stores a single realization of the model results. Repeated runs will overrite any previous results. This is intentional and supports the goal of interactively refining the results to hone in on the desired outputs.