I’m dealing with a problem using GPT.
My chain is an interferometric one, producing DEM from S1 data. The first one was built with only back geocoding, but i wanted to rise the geometric accuracy and use ESD.
Here is the problem : when the chain is launched on Snap graph builder there is no problem, but when i call the xml with gpt (what I normally do, I nearly never use snap on graphic mode) it stops due to a “Java heap space” error.
What can I do to override this ? I tried to use my swap (I’m on linux OS) of 120GB with a 64GB RAM basis but I got the same error. I tried to split the sub-swath and also split the sub-swath of the IW into multi xml but it didn’t work.
I am getting the same problem with GPT and ESD. Any help will be appreciated.
A graph with ‘Back-geocoding’ + ‘ESD’ runs well on the SNAP Desktop graph builder but not with GPT.
The reported error is ‘GC overhead limit exceeded’.
If I remove the ‘ESD’ step, then the graph runs well on both the graph builder and GPT.
More generally, some graphs that run on the graph builder don’t run with GPT.
The simplest graph I have that will not run properly with GPT is the assembling of two S1 IW SLC products. In most attempts, in at least one of the swaths the assembling will not be done. No error message is reported on the terminal. The graph works well on the graph builder.
I have followed the suggestions on those threads.
I use -Xmx17015m on gpt.vmoptions, and add ‘-c 8192M -q 80’ to the GPT command.
Fedora 25 with 24GB of RAM.
SNAP 5.0.1 and S1TBX 5.0.2, updated a couple of hours ago.
working xml up to BC with ESD for IW3
input example
gpt BC_tallinn.xml -Pinput1=S1A_IW_SLC__1SDV_20150316T043329_20150316T043357_005052_00657E_927F.zip -Pinput2=S1A_IW_SLC__1SDV_20150328T043330_20150328T043357_005227_0069A1_3576.zip -Ptarget1=.\Tallinn\BC\5-6_BC.dimBC_tallinn.xml (4.6 KB)