Alright, well I finally managed to execute all scripts up until the export to Stamps (coregistered and interferogram image outputs all seem correct) storing everything on the external drive- no unusual processing times there. However, the export to Stamps appears to be still taking quite long, both using the script and SNAP graph builder. I set the config file to allow full (32 gb) RAM use, CPU usage to 25%, and tried exporting only one pair at a time- the script still ran for several hours without any change; similarly the graph builder export remained at 0% for hours (with -Xmx set to 32G in the gpt.vmoptions file).
I’ve now changed the cache folder to one on the external drive, however, I noticed that previously the path was “/home/user/.snap/var/cache” and I’ve been unable to locate that folder; does it matter that there was a “.” in the path name? There is only a “snap” folder, but it does not contain the sub folders that appeared in the SNAP GUI when I navigated to the new cache location (on the external drive).
Again trying to export one image pair (located on the local drive now) with full RAM use and snap.properties adjusted according to Snap2stamps package: a free tool to automate the SNAP-StaMPS Workflow, this time using the SNAP graph builder, it has been over an hour now remaining at 1%. I realize sometimes the export can take a long time, but could anything else be the issue at this point? Does there even seem to be an issue? It strikes me as such because Stamps Export took only about 45 minutes when I went through the process manually (as per Foumelis et al. (2018)), and that was before the RAM upgrade (8 gb at that time).
Also, are the coregistered and interferogram image files supposed to be named identically (i.e. the outputs for both are named 20181104_20161021_IW1.data and 20181104_20161021_IW1.dim)? That’s how they were output by the scripts, but I wondered if maybe that could result in error while running the Stamps Export.
Thanks (and I hope your new year is off to a decent start)!