Help, I have never been able to process a S1 SLC to anything (SNAP/GPT), is it my PC?

Dear all

I am currently processing S1s to displacement with Gamma on a strong ubuntu server and would like to see if I can move over to SNAP GPT, in a docker.
I have actually managed to build an ubuntu docker on my windows PC with SNAP 5 or 6 pre-releases that I will run on the server once it works.

My problem is I have never been able to processes any S1 scenes with SNAP (GUI or CL) successfully for various reasons.
I have exhausted the forum but I refuse to give up, so can someone tell me at least if my PC is good enough? I am sure it should be able to generate results.
I have tried on 2 windows pc’s (Win10: i5, 12Gb RAM and Win7: i7, 8Gb RAM). I have tried SNAP5 and now 6pre5.

I have not been able to do even the most simple processing, I typically just try and test “gpt read -Pfile=s1…zip)” or Apply-Orbit-File in the GUI. It has never worked. It normally starts, creates a file (BEAM or TIFF format) that never increases past 13mb and fails.
With GPT (in or out of docker) on my Win pc’s I generally get Java heap space errors, even if I set my Xmx to 4/6G on all the conf files I can find.
SNAP is generally the same but with SNAP6 I seem to get a SNAP error “Operator exception” “Waiting thread recieved a null tile”.

The most recent report being:
Java.lang.RuntimeException: Waiting thread received a null tile.
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:963)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.cobbleShort(PlanarImage.java:2951)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2172)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:73)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
Caused: org.esa.snap.core.gpf.OperatorException: Waiting thread received a null tile.
at org.esa.snap.core.gpf.internal.OperatorExecutor$GPFImagingListener.errorOccurred(OperatorExecutor.java:376)
at com.sun.media.jai.util.SunTileScheduler.sendExceptionToListener(SunTileScheduler.java:1646)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:921)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
[catch] at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)

Should I be able to process a S1…zip file to anything using a 8GB RAM i7 PC (I clear all the RAM I can before starting leaving ±7Gb free)? Could there be something wrong with my pc environment?
What operator uses the least amount of RAM so that I can test the program at least?

Hello
I do not know if this will solve your problem but for the images of S1 it is preferable to reduce the area to be studied by the function raster / subset

Can this be done before reading the S1 SLC data?
I finally managed to deburst a scene.
The trick was to increase the java heap space in gpt.vmoptions to double my available physical memory (16G-I only have 8G), this allows the processing to continue using windows virtual memory. It is slow, but it works at least.
This has not been suggested before I think, so I will not delete the question yet.

how to get subset from the SLC data?can you share your detailed steps and the lowst requirements for computer?

1 Like