Guide to Installing the Developer Version of sDRIPS¶

This guide explains how to set up the Developer Version of sDRIPS in a dedicated project environment.

Step 1: Create the Project Directory
Create a new project directory (e.g., sdrips_project) along with the required subdirectories:

mkdir sdrips_project
cd sdrips_project
mkdir Shapefiles

Step 2: Clone the sDRIPS Repository
Clone the sDRIPS repository into your project directory:

git clone https://github.com/UW-SASWE/sDRIPS.git .

Step 3: Set Up the Conda Environment
Create and activate a new conda environment for sDRIPS:

conda create --name sdrips_env
conda activate sdrips_env

Install the required dependencies and configure sDRIPS for development:

mamba env update --file environment.yml
mamba install conda-build
conda develop src/

This setup allows you to import sdrips and immediately apply any changes made in the root directory immediately.

Step 4: Initialize sDRIPS
Some sDRIPS functionalities require credentials. Update the secrets.yaml template located in config_files_templates/secrets.yaml. Detailed instructions on configuring secrets are available here. Run the initialization script:

python src/sdrips/cli/sdrips_init.py -d .

Step 5: Prepare Shapefiles and Configuration
Add all required shapefiles to the Shapefiles/ directory. Create ca_config.yaml based on your farm or command-area specifications using cmd_config module. Update the sdrips_config.yaml file with the appropriate parameters.

- Irrigation_cmd_area_shapefile
- GEE_Asset_ID
- Date_Running
- Irrigation_cmd_area_shapefile_Bounds
- Cmd_Area_Config

Step 6: Running sDRIPS in Developer Mode
After initialization, you can begin testing and integrating your code by placing it in the src/ folder.
To test sDRIPS:

python src/sdrips/cli/ sdrips_test.py -d ./tests/

To run sDRIPS:

python src/sdrips/run_sdrips.py config_files_templates/sdrips_config.yaml

Testing¶

sDRIPS includes a testing framework to verify both correct installation and pipeline stability when new modules are introduced. The pipeline is tested under two scenarios:

• Satellite + weather model data – Runs the functional logic using satellite datasets in combination with numerical weather model data.
• Satellite + weather model data (bias-corrected with in-situ sensors) – Extends the first mode by integrating in-situ observations to bias-correct the numerical model data before estimating evapotranspiration and generating advisories.

Raster Output Tests¶

sDRIPS validates three ET-based raster outputs (sebal, penman-montieth, irrigation). For each raster, it checks both the existence of the file and its values by comparing development-run outputs against a stable version. To perform this check, sDRIPS randomly selects five pixel locations (after masking NoData values) from the raster generated by the development run and compares them with the expected raster downloaded from Google Drive (based on a stable run of sDRIPS).

IMERG and GFS Module Tests¶

For IMERG and GFS, sDRIPS only checks whether the precipitation rasters are generated and can be opened successfully. Raster values are not compared because IMERG data links are frequently updated, which can cause inconsistencies and may lead to broken testing pipeline. The precipitation value may be zero, but the file must exist and open without errors.

Percolation and Net Water Requirement Tests¶

sDRIPS verifies the percolation and net water requirement modules by comparing the percolation outputs (Percolation_currentweek.csv) and the field statistics CSV (Landsat_Command_Area_Stats.csv). If additional columns exist in the development output compared to the stable output, those columns are ignored. Similarly, any column containing IMERG precipitation data or derived from IMERG is also ignored. The purpose of this test is to confirm that the addition of new modules does not break the stable sDRIPS pipeline.

Extending the Test Suite¶

Developers can add new tests for additional functionality by extending the sdrips_test.py module, and uploading the expected data output to the Google Drive.

Contributing to sDRIPS¶

We welcome contributions to improve sDRIPS — whether it’s fixing bugs, adding new modules, improving documentation, or refining existing workflows. This section outlines the recommended workflow for contributors.

Step 1: Fork and Clone
Start by forking the sDRIPS repository and cloning your fork locally:

git clone https://github.com/UW-SASWE/sDRIPS.git .

Step 2: Create a Feature Branch
Always create a new branch for your changes to keep development organized:

git checkout -b feature/my-new-module-in-sDRIPS

Step 3: Development Setup
Follow the Developer Installation Guide to configure your environment. This ensures you can import and test your changes immediately.

Step 4: Write Your Code

1. Add new modules under src/sdrips/. Modules should follow PEP 8 and PEP 257 guidelines as much as possible.

2. Update or add configuration templates if required

3. Document any new features in the appropriate section in the docs/.

Step 5: Run Tests Locally
Before submitting a pull request, make sure your changes do not break the existing pipeline. Run the sDRIPS test suite:

python src/sdrips/cli/sdrips_test.py -d ./tests/

Step 6: Commit and Push
Use clear commit messages describing why the change was made:

git add <changed-or-new-script>
git commit -m "Adding XXXXX functionality"
git push origin feature/my-new-module

Step 7: Open a Pull Request
Go to the GitHub repository and open a Pull Request (PR) from your branch. Please describe:

• What the change does
• Why it is needed
• Any new dependencies introduced
• Instructions for testing

Step 8: Review Process
Your PR will be reviewed by maintainers. Requested changes by maintainer should be addressed promptly. Once approved, your contribution will be merged into the main branch.