Hello, I’m starting this topic with idea to share the experience for speeding up the processing with SNAP. I faced long delays in producing interferograms from S-1 data. For some data sets it took more than 24 hours so I wanted to check what could be done. I suggested that I need fast processor and more RAM, so I started with upgrading my laptop’s memory to 16GB. It resulted that the bottleneck is the speed of the hard disk due to constant read/write operations. One solution was to change the disk of the laptop, but decided to invest a little bit into hardware so I ended up with a workstation with 4 core Xeon processor and 48GB RAM. I wanted to create a hard disk into the RAM and work faster. I divided the RAM between memory for SNAP 16 GB and 24 GB virtual RAM disk. It is to mention that one needs to change the config file of SNAP setting the max memory to the value needed - in my case 16 GB. With this setup I was able to process single data set in about 6 hours . I experienced some delays while copying the intermediate file to the hard disk.
Yes, speed of the hard disk is fundamental if RAMDISK is not used. The fastest SSD:s for workstations are very fast compared with HDD:s but of course RAM is orders of magnitude faster.
In doing GTCs, I found the largest time user was saving the result after each processing step (e.g. saving after calibration, after applying the orbit file, after multi-looking. etc.). The actual processing step would take only a few seconds, but the writing of the data to a geotiff would take anywhere from a few minutes to a few tens of minutes.
If you know that your processing steps are correct, I would suggest getting rid of every save step except for the final product.
Otherwise, if you can upgrade your hardware, I would also suggest installing SSDs. They’re expensive, but much faster (and more durable).
@knicely Could you please define the computer you are using? My experience is that during processing reading file from HDD is also time consuming. Also most of the processing I’ve done takes more than few seconds, sometimes more than an hour for example ESD step takes time. What I’m waiting for is the developers of SNAP to allow subsetting immediately AFTER co-registration.
There are technical reasons why subsetting SLC-products before deburst and merge is not supported. If you cannot deburst and merge early in your processing you should be able to work with debursted individual swaths - not ideal but reduces processing-time.
@hriston_bg
The computer I’m using is a windows machine with 16 GB of RAM and an i7 processor running at 3.4 GHz (8 core, I think).
Most of what I do is geometric terrain correction (GTC), which involves multi-looking (increases pixel size and reduces computation time), applying an orbit file, calibrating the data, and then doing the GTC. A lot of that can be done in parallel and make use of every processor independently, which I’m pretty sure speeds up the process a lot.
@mengdahl I’ve heard your argument several times, but still need this option. You can imagine that if the region one works on needs processing of two SAR images. Even selecting single swath one needs to create two IFs and then merge them.
@knicely Do you perform multi-looking BEFORE apply orbit file?
@hriston_bg
The multi-looking should be done after applying the orbit file and calibration (Orbit file -> calibration -> multi-look -> terrain correction). Otherwise, the pixel values aren’t considered quantitatively accurate.
There are many ways by which you can increase your laptop or pc performace.
But I would highly recommend to use a new RAM.
But Alternatively you can read this speed up laptop guide. By following the steps mentioned in this guide you can easily speed up by 30%.