In this case SRTM 1Sec was used (line 69 of this file)
Very strange indeed, your screenshot also indicates that SRTM 1Sec was used. So the problem with the export is not related to the changed availabiltiy of SRTM 3Sec. You did nothing wrong, don’t worry - we just haven’t found the reason for the error in general.
Change it from DEM.srtm3GeoTiffDEM_HTTP = http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/
to DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/
Since I am doing the processing per batch (i.e. per 10-20 images), which is in my experience a lot faster compared to processing the whole dataset in one run given the current resources I have, I didn’t do any interferogram re-computation for the batches I have processed before experiencing the problem.
And to trace any source of error when doing StaMPS analysis after processing all batches, I have separated the diff0 and rslc folders created thereafter (after doing the solution proposed). I will merge all all soon.
I hope this won’t create another issue during the StaMPS analysis.
I recently updated SNAP Latest version for SNAP2StaMPS processing. My server having these below specifications. Processing 52 interferograms creation it took around 3 days time. Please suggest what setup i wanna change in my Windows 10 server.