Releasing a Tool I Wrote Out of Necessity – ISCE2 topsStack Wrapper Scripts

I came to InSAR processing relatively late in my research career. My doctoral work at IIT Kanpur was grounded in fluvial geomorphology and wetland remote sensing – optical data, Landsat time series, morphometric analysis of floodplain wetland systems. Radar was not part of that toolkit. It was during my Alexander von Humboldt Fellowship at the University of Potsdam, hosted by Professor Bodo Bookhagen, that I first seriously engaged with Sentinel-1 data and the ISCE2 + FRInGE/Mintpy/MiaplPy processing chain. Bodo is one of those rare supervisors who teaches not just the what but the why – the signal, the geometry, the limits of what the data can and cannot tell you. Much of what I know about InSAR processing I learned in Potsdam, including utilizing bash scripts to automate the processing chains – especially while working with HPC clusters. Automation scripts from Bodo seeded the ideas and are the foundation of what I am releasing here.

After moving to Aberystwyth as a Newton International Fellow, I no longer had access to HPC infrastructure. Instead, I worked with a single high-performance workstation – more typical of many InSAR practitioners. I therefore re-engineered the workflow to run entirely on a workstation, eliminating the need for manual input, any hardcoded parameters , while enabling flexible handling of varying numbers of SAR swaths and bursts.

The result is a fully automated pipeline based on ISCE2’s topsStack, implementing the standard sequence of sixteen run steps, from unpacking SLCs to interferogram unwrapping. While robust in routine operation, the workflow remains sensitive to failures, particularly when processing long stacks or large datasets.

The motivation is straightforward. The topsStack processor generates a series of shell scripts – run_01 through run_16 – that must be executed in order, each one processing all dates or interferogram pairs in the stack. When a single job fails partway through a step, whether due to memory, a corrupted acquisition, or a cluster timeout, the default approach is to re-run the entire step. For a stack of 200+ dates and thousands of interferogram pairs – typical for basin-scale analyses – this becomes highly inefficient. Re-running phase unwrapping because only a few pairs failed can require reprocessing nearly the entire stack, except for those that completed successfully. This is not a minor inconvenience: it translates into hours of additional compute time and quickly compounds during iterative workflows involving parameter tuning, network adjustments, or data curation.

The solution is not technically complicated. Before running any job, check whether its expected output already exists. If it does, skip it. Collect only the missing jobs and run those. But implementing that check reliably – across sixteen steps, three possible IW swaths, variable burst counts, two different workflow modes – takes time to do properly. I did it incrementally over several months of active processing, fixing edge cases as I encountered them. The scripts worked well enough for my own use. At some point I realised they were also something I should share.

The ISCE2 topsStack InSAR Processing Wrapper is the result. It covers Steps 2 through 16 of the topsStack pipeline, with each wrapper script checking for existing outputs before queuing any work, and configurable parallelism that runs multiple dates or pairs simultaneously. It works with both the standard interferogram stack workflow and the SLC stack mode.

The automatic multi-swath and burst detection is worth noting specifically. Sentinel-1 IW acquisitions can have one, two, or three swaths depending on the track and AOI, and the number of bursts per swath varies with the scene. The scripts detect all of this at runtime from the reference/ directory, including handling the zero-padding that ISCE2 uses for burst indices. This makes the tool usable for any Sentinel-1 scene without modification.

Releasing these scripts properly took more effort than I expected. Not the code – the code was mostly done. What took time was the surrounding infrastructure: a README that actually explains the workflow rather than assuming the reader already understands it, a licence that makes the terms of use unambiguous, a CITATION.cff file so that researchers who use the tool can cite it, a Zenodo DOI for archival, a .gitignore that keeps hundreds of gigabytes of SAR data out of version control. These are not glamorous tasks, but they are the difference between code that exists and code that is actually usable by someone else.

I think early-career researchers often underestimate the value of releasing tools properly. There is a tendency to treat software as a by-product of research – something written to get results, not something worth maintaining or documenting. I understand that instinct; it reflects real pressures on time and output metrics. But for methods-heavy fields like remote sensing and geomorphology, the tools are often where the intellectual contribution lives. A well-documented, openly licensed piece of software that solves a real problem is a contribution, and it compounds in ways that a paper describing the same method often does not.

If you work with Sentinel-1 data and run the topsStack pipeline, these scripts may save you meaningful time. If you find a bug, or have a use case I have not handled, I would welcome an issue or a pull request.

Repository: github.com/manudeo/isce2-topsstack-wrapper
DOI: 10.5281/zenodo.19294500