Hello everyone,
A usual run of the attached graph on my computer(win 10, 64-bit, 3.2 GhZ, i5, 16GB RAM) S1 GRD scenes takes just over 20 mins mins, which I thought was reasonable .
But, for some reasons the run of the same graph on “S1A_IW_GRDH_1SDV_20160101T174851_20160101T174916_009304_00D70A_0E31” takes nearly 3 times longer.
I can see that the image has large parts of sea in it so could this be the reason, and if I remove the terrain flatttening step then the performance reverts to of course that of a non-terrain flattening pre-processing. Could there be something in the terrain flatttening that degrades performance when part of the scene has no data e.g. sea etc.
myGraph.xml (5.1 KB)
Any thoughts and suggestions will be much appreciated.
Thanks,
Sanjay.
My feeling is that you should probably do Terrain Flattening and Terrain Correction in separate graphs. Both of them are geometric operations and it’s possible that they traverse the image differently so that putting them in the same graph makes the process inefficient.
Also, your graph is missing updating orbit information and doing radiometric calibration. Try splitting into two graphs where the first one ends at terrain flattening.
Okay - thanks!. maybe splitting the graphs would improve the situation.
You are correct. Process should (and does) have radiometric calibration but it only produces the beta0 band (although i just checked and the attached xml i posted here indeed didn’t have the beta0 option as true but one I ran had - it wouldn’t have run otherwise 
)
I was advised that the orbital file application was only really relevant for SLC products and interoferometry applications but would you suggest that its still useful?
Better orbits are mainly needed for interefometry, that’s correct. Still, I would use restituted orbits to ensure that geocoding goes well even when the predicted orbits are off.