CRHM

Follow the six-stage pipeline: create HRUs from a DEM and land cover, convert forcing to .obs format, select a module chain by landscape type, generate and validate the .prj file, then run the CRHM binary and parse outputs. Always run preflight_check.py first to verify the binary and data.

Use tools/s2_observation_data/convert_vic_to_obs.py, which handles the critical specific-humidity-to-relative-humidity conversion via the Tetens formula plus precipitation rate scaling. Then validate the result with validate_obs_file.py before running the model.

CRHM has silent failure modes: humidity passed as kg/kg instead of percent zeroes sublimation, and parameters outside declared ranges are clamped without warning. Check diagnostics/triplets.yaml for the matching symptom and verify max(RH) exceeds 1.0 in your .obs file.

Use the mountain chain including Slope_Qsi for slope radiation correction, walmsley_wind for topographic wind amplification, pbsm, ebsm, crack, evap, Soil, and Netroute. The select_modules.py tool auto-detects basin type from the HRU config when relief exceeds 500 m.

Yes, stage s6 merges CRHM and VIC outputs using merge_crhm_vic.py, but you must define a process ownership table first. Both models compute snowmelt, ET, and soil moisture, so double-counting processes produces water balance errors over 100%.

CRHM is HRU-based rather than grid-distributed, does not perform flood inundation modelling, and has no built-in automatic calibration. Decadal runs also carry a roughly 4-5% un-closable water-balance residual from Netroute lag-storage states that lack output variables.