Hello Richard,
Thanks for reporting this, and for the detailed description.
What you are seeing is not expected as normal behavior, especially the large run-to-run differences.
From your description, there are two likely contributors:
1. Non-deterministic pit processing in some terrain configurations
- If many pits have similar/equal elevations, the processing order can influence downstream edits.
- Because each solved pit modifies the surface, different tie/order paths can produce different final outputs.
2. Fill fallback on unresolved pits
- If breaching cannot find an acceptable outlet (for example due to restrictive distance/cost limits), unresolved depressions may be handled by fill behavior.
- That can create broad raised flats/plateaus, including in places that look like topographic highs in profile.
Could you please run the following tests on the same DEM extent and share outcomes/screenshots?
1. Determinism check
- Run the exact same command 2-3 times with all parameters unchanged.
- Report whether outputs are bit-identical or visually different.
2. Disable filling fallback
- Re-run with fill disabled.
- If plateaus disappear, that strongly indicates unresolved-pit fill behavior is driving the highs.
3. Relax breach constraints
- Increase breach search distance and relax/remove max_cost, then compare.
- If plateauing drops substantially, unresolved pits were likely due to restrictive settings.
4. Parameter sensitivity sweep
- Keep everything fixed except one parameter at a time:
- dist: low, medium, high
- max_cost: strict, moderate, unlimited
- This helps isolate threshold behavior.
5. Data sanity checks
- Confirm DEM has no nodata seams/voids, extreme spikes, or mixed vertical units in the affected area.
- If possible, share min/max and histogram stats for the problematic tile.
If you can share:
- exact tool call/flags,
- WhiteboxTools version,
- and a small clipped raster reproducing the issue,
that would make it much easier to diagnose precisely.
The good news is that we are soon going to be releasing Whitebox Next Gen (
https://github.com/jblindsay/whitebox_next_gen/blob/main/README.md), complete with new Python and R APIs and a QGIS 4 compatible plugin. The release will hopefully be in the early summer,
and if we can track down this issue, then we will be able to include it in this release.
Regards,
John