Error/Stalled in run_01_unpack_topo_reference #28136
Unanswered
maipleasurre
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
run_01_upack_topo.txt
I am currently processing Sentinel-1 IW SLC data using ISCE2 topsStack, and the processing becomes stalled during Step 1, run_01_unpack_topo_reference, specifically in the topo.py stage. The reference SLC is successfully unpacked and the reference directory contains four IW1 bursts (burst_01–burst_04). I am currently testing the processing using IW1 only. The DEM used for the processing is a GeoTIFF (demA.tif) with a relatively high spatial resolution, and the same processing workflow has previously worked with other DEM datasets. The topo.py process does not produce any Python error or exception, but it continues running for many hours with the worker consuming approximately 99% CPU. After several hours, the geometry directory contains only hgt_01.rdr, incLocal_01.rdr, lat_01.rdr, lon_01.rdr, los_01.rdr, and shadowMask_01.rdr, while no geometry files are generated for bursts 02–04. The next processing step, run_04_extract_burst_overlaps, consequently fails with a FileNotFoundError because it expects geom_reference/IW1/lat_02.rdr.xml. The ISCE log does not report an actual error and only shows the warning Default Peg heading set to: -0.21010205856693734. The topo.py source indicates that it should process all bursts using for ind in range(reference.numberOfBursts). I would like to know whether this behavior could be related to the DEM characteristics, such as its resolution, size, format, or metadata, or whether it is more likely related to burst-specific processing in TopoZero. What would be the recommended way to diagnose why topo.py remains running for many hours without producing the geometry files for the subsequent bursts?
All reactions