Software

One desktop scientific workflow.

BAITSSS Desktop organizes project definition, scientific input checks, hourly execution of the BAITSSS model, Results inspection, and export within one persistent project environment.

BAITSSS Desktop V1 · First release version · final validation and cleanup.

Development & Verification →

01 · Product walkthrough

BAITSSS Desktop in 4 to 5 Minutes

The short video follows the current BAITSSS Desktop V1 validation build from project preparation through Results.

Current BAITSSS Desktop V1 validation build.Project → data → run → Results

02 · Interface tour

See the actual desktop workflow

These are direct screenshots from the BAITSSS Desktop V1 validation interface. They show the project, AOI, data, execution, and Results environments rather than conceptual mockups.

HomeProject status, workflow entry points, and the current modeling context.

ProjectCreate or reopen a project and keep the modeling period and project identity together.

Area of InterestDefine and inspect the spatial modeling domain before environmental data preparation and execution.

Data and readinessOrganize Landsat, weather, terrain, soil, land cover, and other required BAITSSS model inputs while keeping readiness visible.

Upper LayerReview and prepare the upper-layer weather and scientific inputs within the BAITSSS Desktop workflow.

RunReview execution status, progress, and the current simulation while the BAITSSS model advances hour by hour.

BAITSSS Desktop pixel time series interface

Pixel and time series ResultsInspect selected pixel behavior through time and export data for further analysis.

Select any screenshot to open the full size image. Interface details may continue to change while BAITSSS Desktop V1 remains in final validation and release cleanup.

03 · Workflow

Prepare. Verify. Simulate. Examine. Evaluate.

Prepare the project

Create or reopen a project, define the spatial domain and simulation period, and organize the required environmental inputs.

Verify readiness

Check temporal coverage, required variables, spatial compatibility, data preparation status, and other conditions that must be satisfied before execution.

Simulate hourly

Run the BAITSSS model continuous hourly water and energy balance while preserving the state carried from one hour to the next.

Examine Results

Review mapped outputs, selected pixel time series, soil water conditions, modeled irrigation information, run identity, and scientific exports.

Evaluate the science

Use the selected run and its exported products for the intended analysis or downstream evaluation.

04 · Development scale

Research code was converted into controlled desktop scientific software.

The modernization introduced an installable Windows product, project and run lifecycle management, controlled data preparation, a stable science execution path, recovery, Results authority, provenance, automated equivalence checks, release tooling, and documentation while retaining a frozen scientific reference.

V7 to V8

464commits ahead of the frozen V7 reference in the V8 integration history as checked September 8, 2026.

Long-run proof

3,096 hKansas whole-AOI V7 to V8 numerical equivalence across a seasonal state-propagating run.

Verification matrix

24–3,336 hShort, intermediate, seasonal, and extended-run cases represented in the numerical verification infrastructure.

Release route

Desktop V1Bundled runtime, validation, run and recovery, Results, export, packaging, and release acceptance under one product route.

05 · Software assurance

Current engineering controls and their status

Each item below represents a separate maturity control. Status is stated directly so implemented capability is not confused with work still in progress.

Version control & frozen baseline

Established

Frozen V7 reference and isolated V8 development authorities preserve an auditable before-and-after scientific baseline.

Scientific source control

Established

Core science execution files are source-locked to reviewed identities; changes require explicit integration review.

Numerical equivalence

Established

V7 to V8 numerical comparison infrastructure protects the scientific calculation during modernization, including seasonal whole-AOI evidence.

Regression & contract testing

Established

Automated tests cover runtime authority, engine binding, project lifecycle, Results authority, spatial math, storage, readiness, run recovery, and other release-critical contracts.

Continuous integration

Established

GitHub Actions executes equivalence and contract checks on integration paths rather than relying only on manual testing.

Deterministic restart

Established

Checkpoint and resume behavior is tested to preserve the scientific trajectory when execution is interrupted and resumed.

Input validation & readiness gates

Established

AOI, static data, NLDAS completeness, run readiness, and other required inputs are validated before scientific execution.

Run-local immutable inputs

Established

Critical run inputs are frozen locally for execution and provenance so later project changes cannot silently rewrite an existing run.

Parameter authority

Final audit

Advanced Settings are being traced from saved value through generated constants, runtime contract, and final science-kernel value while duplicate fallbacks are classified and removed where appropriate.

Single execution authority

Established

The product is converging on one supported runtime and engine path rather than multiple interchangeable scientific execution routes.

Architecture consolidation

Expanding

Viewer, Results, lifecycle, runtime, storage, and state authorities have been progressively consolidated to reduce duplicate behavior.

Results authority & export

Final validation

Results are bound to selected runs and simulation periods, with run-specific provenance controlled explicitly. GUI export behavior remains under final end-to-end validation for Desktop V1.

Failure handling & recovery

Established

Run interruption, checkpoint recovery, failure reporting, disk guards, and lifecycle recovery are explicit product behaviors.

Performance engineering

Established

Execution was modernized around RAM-resident state, reduced materialization, parallel spatial execution, and bounded storage while numerical behavior was checked against the reference.

Provenance & reproducibility

Established

Runtime identity, frozen configuration, run-local inputs, selected data sources, and output association are tracked so Results can be tied back to the executed state.

Packaged runtime & dependency control

Established

The Windows desktop package carries its own controlled runtime instead of relying on an unknown system Python installation.

Installer & packaging verification

Established

Build preflight, runtime payload checks, installer identity, release manifest, and package-data cleanup are part of release preparation.

Release acceptance

Established

Release-specific acceptance tooling and documented criteria exist separately from ordinary development testing.

Documentation

Expanding

User guidance, capability documentation, release material, scientific history, software development record, and access guidance are being completed for Desktop V1.

Independent external validation

Still developing

Broader third-party use, independent external V&V, and accumulated field experience across institutions remain future maturity evidence.

Long-term release history

Not yet available

Desktop V1 is the first release version; multi-release backward compatibility and years of operational maintenance cannot yet be demonstrated.

06 · Product architecture

The current desktop system separates responsibility across explicit authorities.

Project & data

Project lifecycle, AOI, data-source state, validation, readiness, and run configuration.

Runtime & engine

Controlled runtime discovery, engine adapter, science bridge, execution authority, and frozen inputs.

Scientific kernel

Established BAITSSS equations, state propagation, model parameters, weather, vegetation, irrigation, and energy and water balance calculations.

Run lifecycle

Execution, parallel spatial work, checkpointing, recovery, disk protection, finalization, and storage management.

Results & provenance

Run-bound outputs, scientific export, reports, retained storage, and traceability back to the executed configuration.

07 · Current stage

What is complete and what still remains for Desktop V1.

Current state

Core software implemented; first-release validation in progress.

The science execution path, desktop workflow, project lifecycle, input preparation, run and recovery, Results, provenance, packaging, and release-control mechanisms are substantially implemented. Current work is concentrated on authority cleanup, final validation, human workflow checks, documentation, and release acceptance rather than creating a new model architecture.

Go deeper

Use the page that owns the question.

For the complete capability inventory, scientific formulation, evidence, or business pathway, continue to the corresponding authority page.

Capabilities →Science →Evidence →Business →