XAJ ​

This page presents the typical XAJ model path in HydroPilot: how an xaj.yaml plus CSV-oriented project can be organized into a runtime that is verifiable, repeatable, and ready to connect with UQPyL.

This case shows how HydroPilot supports CSV-oriented hydrological workflows.

What stands out ​

• CSV-based readers and writers
• RIVID-aware parameter targeting
• template support for a non-SWAT hydrological model

When this case fits best ​

Use this path when:

• the project is based on an XAJ workflow with xaj.yaml and CSV inputs/outputs
• parameters are stored in parameters.csv
• outputs are read from CSV files such as streamflow.csv or Runoff_Yield.csv
• model targeting is easier to express through RIVID-based filtering than through SWAT-style HRU logic

Typical configuration pattern ​

The normal entry is version: xaj:

version: xaj
basic:
  projectPath: ./xaj
  workPath: ./work
  command: ./pyxaj.exe run xaj.yaml

The template expands this into a general config with CSV readers and CSV writers.

Why this case is useful ​

It demonstrates that HydroPilot is not only a SWAT wrapper. The same orchestration approach can support other hydrological models when parameter writing and result reading can be formalized.

What HydroPilot handles here ​

For XAJ-style projects, HydroPilot can:

• discover project metadata from xaj.yaml
• resolve parameter write targets from parameters.csv
• map named variables to output files and columns
• use rivid to target specific rows or result columns when needed

Minimal example shape ​

version: xaj
basic:
  projectPath: ./xaj
  workPath: ./work
  command: ./pyxaj.exe run xaj.yaml

parameters:
  design:
    - name: KC
      bounds: [0.5, 2.0]
    - name: WM
      bounds: [80, 200]
  physical:
    - name: KC
      mode: v
      filter:
        rivid: 60711600

This reflects the typical XAJ starting shape: CSV-based parameters, RIVID-aware targeting, and a template that expands into a general config.

This makes the XAJ path a good example of HydroPilot as a generic hydrological execution layer rather than a SWAT-only tool.

What this case supports well ​

• CSV-based parameter writes
• CSV-based output extraction
• row and column resolution from project metadata
• model-specific execution without fixed-width SWAT assumptions

Suggested first move ​

Start from an XAJ project that already has a stable xaj.yaml and CSV outputs. Validate that HydroPilot can discover the parameter table and output headers before trying to add objectives or optimization logic.

Connection to UQPyL ​

The same pattern still applies: HydroPilot owns model execution and CSV-level integration, while UQPyL can own the optimization or calibration logic through UQPyLAdapter.