Everything goes ok for the first and second graphs, while an error occurs in the third processing, in particular on the Topsar-Merge part. The following error message (only a log extract) is shown:
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Loading external tools...
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Scanning for external tools adapters: /usr/local/snap/s2tbx
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Scanning for external tools adapters: /usr/local/snap/s1tbx
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Scanning for external tools adapters: /usr/local/snap/s3tbx
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Scanning for external tools adapters: /root/.snap/auxdata/tool-adapters
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Scanning for external tools adapters: /usr/local/snap/rstb
WARNING: org.esa.snap.core.util.ServiceFinder: Can't search for SPIs, not a directory: /root/.snap/snap-python
java.lang.NullPointerException
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:397)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:392)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
at org.esa.s1tbx.sentinel1.gpf.TOPSARMergeOp.computeTileInOneSwathFloat(TOPSARMergeOp.java:729)
at org.esa.s1tbx.sentinel1.gpf.TOPSARMergeOp.computeTileStack(TOPSARMergeOp.java:646)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:85)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.cobbleFloat(PlanarImage.java:3254)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2181)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:406)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:392)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
at org.esa.s1tbx.insar.gpf.GoldsteinFilterOp.computeTileStack(GoldsteinFilterOp.java:236)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:85)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.cobbleFloat(PlanarImage.java:3254)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2181)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:406)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:392)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
at org.esa.s1tbx.sar.gpf.MultilookOp.computeTile(MultilookOp.java:182)
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)
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:406)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:392)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:934)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:85)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
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:406)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:392)
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)
I’m quite sure that such error is related to the Topsar-Merge, since I’ve created another graph with only the Topsar-Merge operation obtaining the same error.
This is not a blocking error, since the processing (after hundreds of “java.lang.NullPointerException”) ends successfully, but the resulting data has not any meaningfulness.
Could you please help me to understand where I’m doing it wrong?
Thank you in advance
Kind Regards
Details on the working environment:
OS: CentOS release 6.7 (Final)
16 GB RAM
4 QEMU Virtual CPU version (cpu64-rhel6) @ 3491.912 Mhz
co reg…(the out put should be deramp and dmod)…> s-1 range shift
…> s-1 azimuth shift…>deburst…>subset…>infgram
formation …> Topographic removal …>Filtering Goldstein …>
Unwrapping
Dear falahkhri,
Thank you for your answer.
The processing chain that you suggested is very similar to the one that I’m currently implementing (except for the subset and unwrapping).
I think that such error is not due to the processing chain, since the same processing works very good with SNAP 3 with a couple of S1A data.
My issue is probably more related to some strange behavior TOPSAR-Merge that happens with such interferometric couple + SNAP 4.
Maybe some developer could be very useful for this
Dear All,
The error during the TOPSAR-MERGE processing still occurs.
Other attempts have been done also with a dataset different from the one listed above, with both Windows and Linux (Linux through gpt), and with SNAP 4 and SNAP 5.
Attached there are the graph files that have been used to perform the interferogram.
The run order is:
splitMasterIW1_3burst.xml
splitMasterIW2_3burst.xml
splitMasterIW3_3burst.xml
splitSlaveIW1_3burst.xml
splitSlaveIW2_3burst.xml
splitSlaveIW3_3burst.xml
ifg_core_IW1.xml
ifg_core_IW2.xml
ifg_core_IW3.xml
merge_filter_multilook.xml
Could you (maybe @lveci ) please provide me help on this?
Hey rss_user,
I have also an error with TOPSAR-Merge.
I get the error: [NodeId: TOPSAR-Merge] String Index out of range: -1
in the command line I get further information for that:
UTC parse error:2015–5-41595.03821950784:java.text.ParseException: Unparseable date: “2015–5-41595”
UTC parse error:2015–5-41607.61205848394:java.text.ParseException: Unparseable date: “2015–5-41607”
UTC parse error:2015–5-41595.03821950784:java.text.ParseException: Unparseable date: “2015–5-41595”
UTC parse error:2015–5-41607.61205848394:java.text.ParseException: Unparseable date: “2015–5-41607”
UTC parse error:2015–5-41595.51099801902:java.text.ParseException: Unparseable date: “2015–5-41595”
UTC parse error:2015–5-41608.09202701785:java.text.ParseException: Unparseable date: “2015–5-41608”
UTC parse error:2015–5-41595.51099801902:java.text.ParseException: Unparseable date: “2015–5-41595”
UTC parse error:2015–5-41608.09202701785:java.text.ParseException: Unparseable date: “2015–5-41608”
UTC parse error:2015–5-41594.611690989404:java.text.ParseException: Unparseable date: “2015–5-41594”
UTC parse error:2015–5-41607.19991751539:java.text.ParseException: Unparseable date: “2015–5-41607”
UTC parse error:2015–5-41594.611690989404:java.text.ParseException: Unparseable date: “2015–5-41594”
UTC parse error:2015–5-41607.19991751539:java.text.ParseException: Unparseable date: “2015–5-41607”
String index out of range: -1
In- and Output format is GAMMA. I also figure out, that in the SNAP GUI the S-1 TOPS Merge ProductSet Reader is not reading the information in the right way: Acquisition, Track and Orbit are wrong.
I also split each IW processing into a seperate xml and want to combine them in a forth xml file.
I run this on CentOS7 and with SNAP5 through gpt.
I found a solution for my problem. TOPSAR-Merge can not read Gamma products properly. Master-,Slave-Date, Orbit-information are shown as 99999. They are correct if I give TOPSAR-Merge Beam-Dimap Files. Then the process of merging works good.
Dear HHVice,
I’m happy about the resolution of your problem, even if mine seems different.
I always used Beam-Dimap files as input of TOPSAR-Merge operator, and the command line shows (linux - gpt case) the error java.lang.NullPointerException hundreds of times.
Hey HHVice,
Even in my case the deburst operation is performed just after the interferogram generation (and before the TopoPhaseRemoval), as reported in the ifg_core_IW*.xml graph files.
The problem is in the order of the operators in the graph. The Topo Phase Removal doesn’t account for TOPS subswaths. If you deburst and then merge then the output of merge is fine. After the merge you can apply the topo phase removal.
I’ve added better error checking to catch this problem better in the future.
I just want to ask if it’s possible to merge two ‘debursted’ Sentinel-1 products?
I wanted to merge two ‘debursted’ products both from S1B-Descending (same path 61 but with different frames 470 and 475). I do get the error as shown in the image below.
Hi Mr. Iveci.I have a question about the *splitting_master_multi_IW.py * script of snap2stamps workflow… if we want to use it, all subswathes will be split at the same time? so how we can set IW1=… in the project.conf file?
since my interset area is located on the 2 subswathes, I want to split IW2 and IW3 simultaneously… so is it possible based on using splitting_master_multi_IW.py?
The script that you are pointing out does not form part of the processing workflow suggested in the manual.
Obviously you can use it, but then you need to develop your own solution (which would not be much complicated) as today it is not included in that package.