GPT slc convert to GRD by xml

thanks for your reply, i 'll try this method.
By the way, we will use the SLC data to do some InSAR work one day, so …

then why are you calibrating to Beta0 and apply Multi-Looking?

hello, I want to convert to grd. But i get error information.
data : 143/S1B_IW_SLC__1SDV_20180708T114131_20180708T114201_011719_0158E8_E1EC.zip

SLC_to_GRD_part1.xml (2.9 KB)
SLC_to_GRD_part2.xml (2.8 KB)

Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
-8
-8
-8
-8
90% done.
org.esa.snap.core.gpf.OperatorException: -8
at org.esa.snap.core.gpf.graph.GraphProcessor$GPFImagingListener.errorOccurred(GraphProcessor.java:363)
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 javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
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)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)
Caused by: org.esa.snap.core.gpf.OperatorException: -8
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:432)
at org.esa.s1tbx.sar.gpf.geometric.SRGROp.computeTile(SRGROp.java:290)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:80)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
… 11 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: -8
at org.esa.snap.core.datamodel.ProductData$Float.getElemDoubleAt(ProductData.java:2437)
at org.esa.s1tbx.sar.gpf.geometric.SRGROp.computeTile(SRGROp.java:260)
… 14 more

Error: -8

please use only one topic: GPT slc covert to GRD by xml

I’ve moved the posts

because we need Beta0 to do the Terrain Flattening, so …

hello ABraun,
i have changed the
false
to
true
in my xml, and it does work! thank you so much! while, when i do the Multi-Look process, i get another issue…
please check:
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
-24
-24
-24
90% done.
org.esa.snap.core.gpf.OperatorException: -24
at org.esa.snap.core.gpf.graph.GraphProcessor$GPFImagingListener.errorOccurred(GraphProcessor.java:363)
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 javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
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)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)
Caused by: org.esa.snap.core.gpf.OperatorException: -24
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:432)
at org.esa.s1tbx.sar.gpf.geometric.SRGROp.computeTile(SRGROp.java:290)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:80)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
… 11 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: -24
at org.esa.snap.core.datamodel.ProductData$Float.getElemDoubleAt(ProductData.java:2437)
at org.esa.s1tbx.sar.gpf.geometric.SRGROp.computeTile(SRGROp.java:260)
… 14 more

Error: -24

But terrain Flattening destroys the inteferometric information. It is intended to correct the backscatter intensity, not the phase.

This seems to be a problem either of the implementation or of the input data.
Do you get this exception also on other products?
Oh. I see you reported it already

And here it was reported too.

@lveci Have you seen this before?

hi, ABraun,

thanks for your reply.
actually, we are working on the water extraction, the TF process will remove the mountain shadow, then we can get water mask directly from the Gamma0 band, so …

Hi, ABraun,
By the way, the reason that we download the SLC product is because we want to keep this origin data to do InSAR work in the future, while, now, we just do water extraction, so we convert SLC to GRD, and do TF process as well.

hi, Marpet,
actually, i get this exception also on other s1 products, and sometimes the Error is -8, sometime it is -7, or -9, i’m quit confused about the error message, would you mind to explain it or is there any doc that i can find the answer.
thanks a lot!

The error results from a wrong access to the data. But you don’t have an influence on this.
I can’t help further. I just had quick look at the code where the error happens.
I’ve asked @lveci in the previous post already if he can help. He might know more about it.

thanks for you so much, marpt. i’ll try to find other method.
have a good day!

Luis created a ticket in the bug tracker for your problem. So I guess it is a bug.

hello, these day I process by xml like above. I always find that processing is often wrong in some regions.

The picture is an example and data is 41/S1A_IW_SLC__1SDV_20171203T115102_20171203T115131_019538_0212A5_F07D.zip

hard to say where the error occurs. My guess is that the file size for a kmz is exceeded. Does the data look alright in SNAP?

I think the GRD production is from the SLC. I wonder that this production can be successful but using gpt failed.

Sorry, I don’t get it.
Of course producing a GRD product from the SLC should always work but if you are applying a graph you lose control over the results of the intermediate steps.
Again, if your intention is water mapping, downloading GRDs directly should be the quicker way. And for all InSAR tasks you use SLC.

hello , I process the slc data to grd using xml above.
but find one data(164/S1A_IW_SLC__1SDV_20160911T230323_20160911T230350_013011_0149AC_E4AD.zip) process error.
so I using the GRD data (/164/S1A_IW_GRDH_1SDV_20160911T230324_20160911T230349_013011_0149AC_4759.zip) to instead the slc data . this GRD i process by other xml as attachmentsGRD_post_process.xml (4.1 KB)

At last, I want to merge all data to one tif and I find some gaps, I think this may can help you to find why slc to GDR by xml is falied.