SWAT+ ​

This page presents the typical SWAT+ model path in HydroPilot: how a SWAT+ project, calibration.cal parameter writing, and output extraction are organized into a repeatable runtime workflow.

What it emphasizes ​

• template-oriented model support
• SWAT+-specific parameter writing paths
• model output extraction for calibration and evaluation

When this case is the right one ​

Use this path when:

• the target project is a SWAT+ project rather than SWAT 2012
• parameter updates should follow the SWAT+ calibration.cal route
• model metadata needs to be discovered from files such as file.cio, time.sim, print.prt, and hru-data.hru
• you want HydroPilot to stay aware of SWAT+ object types and filtering limits

Typical configuration pattern ​

The normal entry is version: swatplus:

version: swatplus
basic:
  projectPath: ./TxtInOut
  workPath: ./work
  command: swatplus.exe

HydroPilot expands this template into a general config, but parameter writing is still conceptually centered on generated calibration.cal records rather than direct ad hoc file edits.

Why it is different from SWAT 2012 ​

SWAT+ has a different project structure and parameter-writing strategy, so HydroPilot needs model-aware handling rather than a generic copy of the SWAT 2012 path.

What HydroPilot currently provides ​

The current SWAT+ direction already covers several important layers:

• dedicated template expansion
• project discovery from real SWAT+ files
• parameter database support for selected groups
• calibration.cal-based writing
• tier-1 flow series extraction at common output frequencies

Minimal example shape ​

version: swatplus
basic:
  projectPath: ./TxtInOut
  workPath: ./work
  command: swatplus.exe

parameters:
  design:
    - name: surq_lag
      bounds: [0.05, 24.0]
    - name: esco
      bounds: [0.0, 1.0]
  physical:
    - name: surq_lag
      mode: v
    - name: esco
      mode: v

This captures the normal starting shape for SWAT+ support, even though a real project config still needs series and evaluation definitions.

The practical consequence is that users can think in terms of named parameters and supported filters instead of manually editing individual SWAT+ source files at runtime.

Current boundaries ​

This case is usable, but it is still more constrained than mature SWAT 2012 support.

Known limits include:

• filter support varies by parameter group
• some selectors are exact-match only
• richer calibration condition syntax is not yet covered
• broader real-project validation is still valuable

What this case already supports ​

• SWAT+ aware project discovery
• parameter writing through calibration.cal
• selected group-wise filter handling
• common flow-series extraction patterns

Suggested first move ​

Treat this as a supported but still evolving path:

1. start from the SWAT+ template structure
2. validate the config early
3. confirm one real project run before adding optimization
4. only then connect to UQPyL if repeated search is needed

That means this path is best treated as a growing but already practical capability, especially when your project fits the currently supported parameter groups and series outputs.

Connection to UQPyL ​

Once a SWAT+ config is validated and runnable through HydroPilot, the same runtime can be exposed to UQPyL through UQPyLAdapter. That keeps SWAT+ file handling inside HydroPilot and leaves optimization behavior to UQPyL.

Suggested next pages ​

• Examples
• UQPyL Integration