Performance of snap/gpt

snap
#1

How best to debug performance issues with snap, gpt, etc?

I’ve found that the s1tlbx terrain correction operator (performed on a given scene subset with a given DEM subset) takes about 3-4min from the SNAP GUI, about 4-5min from the GraphBuilder GUI, and much longer (>12hrs) from GPT (either by xml or command line arguments).

(SNAP v2.0.3 or v3.0.1, MS Windows 7 sp1, quad-core i5-3470, 8gb ram, local hd.)

Terrain correction bug
GPT performance better on 6-core i7 vs 2x18-core Xeons
#2

More than 12 hours? This is really to long compared to the few minutes when processing in SNAP.
Can you provide us with graph xml file you are using? We need to reproduce it.

#3

Here are the steps to reproduce:

  1. Create a small SAR subset (e.g. 34mb)
  • Drag and drop S1A_IW_GRDH_1SDV_20150223T090912_20150223T090925_004748_005E1F_4B90.zip into SNAP3.0 (64bit MS Win7E)
  • Raster Subset (10000,5000 to 12000,7000 pixels)
  • File save product as subset.dim
  1. Create an external DEM file
  • From SNAP GUI, Radar geometric Terrain Correction RD (SRTM 3s auto-download) with output band for DEM enabled. (Takes half a minute to download, then 20s processing.)
  • File export geotiff, band subset to elevation only (and metadata none), as dem.tif

  1. Test terrain correction from GUI using external DEM. (Succeeds after 6s processing.)

  2. Test terrain correction from command line (does not complete after tens of minutes with 50% CPU utilisation by gpt).

  • Open cmd.exe and cd to directory containing subset.dim and dem.tif,
  • “gpt Terrain-Correction -Ssource=subset.dim -PexternalDEMFile=dem.tif”
  1. Test another operator from the command line (works fine).
  • Delete target.dim and target.data,
  • “gpt Calibration -Ssource=subset.dim”
  • open target.dim into SNAP GUI and inspect.
#4

@lveci Is this a problem of the terrain correction?

#5

This appears fixed in version 4.0.0 (tested using linux 64 release), thanks!