After opening 1 product and displaying the band (or subswath), I drew a rectangle (using the Rectangle drawing tool), then right-click on the blue rectangular box, and selected WKT from Geometry. It is ‘Please select a geometry’ as shown below.
is this the area of interest? Because the coordinates are quite differrent to those you posted above…
It’s just a random area I selected but in the same region of interest.
I’m just providing ideas on where to look for potential error sources…
Is the correct sub-swath selected in the config file?
Yes. I always checked the subswath where the AOI is located in SNAP (Quicklook).
I will triple check everything and update you.
I thought before that the LON MIN and LON MAX (since it’s my first time having an AOI in US) could be the source of error but I think this is really the correct one and not the opposite.
LON MIN=-123.393917
LON MAX=-123.350054
Hi, Everyone.
I have encountered an error during the coregistration and interferogram formation using snap2stamps. Please see script and image below. I would like to ask what might be the problem and how to solve it.I would appreciate if give me some ideas.
[1] Processing slave file :20200105_IW3.dim
SNAP STDOUT:INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
SEVERE: org.esa.s2tbx.dataio.gdal.activator.GDALDistributionInstaller: The environment variable LD_LIBRARY_PATH does not contain the current folder ‘.’. Its value is ‘/service/local64/subversion-1.6.16/lib64:/usr/X11R6/lib:/usr/X11R6/lib64:/lib:/lib64:/usr/lib:/usr/lib64:/service/local/lib:/service/local/lib64:/service/local64/octave-3.4.0/lib/octave-3.4.0:/service/local64/lib:/service/local64/readline-4.3/lib:/service/local64/db-4.4.20/lib:/service/local/maple/maple13/lib:/dsk/igsoftlocal/ncl_ncarg-6.2.1.Linux_SL6.5_x86_64_nodap_gcc447/lib:/misc/gamma/GAMMA_SOFTWARE-20200713_ubuntu1804/lib:/service/soft/local/cern/2006b/i686-slc5-gcc43-opt/lib’.
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
…10%…Java heap space
Java heap space
java.lang.NullPointerException
90% done.
org.esa.snap.core.gpf.OperatorException: Java heap space
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.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:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:461)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileInOneSwathFloat(TOPSARDeburstOp.java:895)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileStack(TOPSARDeburstOp.java:802)
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:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:461)
at org.jlinda.nest.gpf.SubtRefDemOp.computeTileStack(SubtRefDemOp.java:499)
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.datamodel.Band.readRasterData(Band.java:311)
at org.esa.snap.core.dataio.ProductSubsetBuilder.readBandRasterDataRegion(ProductSubsetBuilder.java:395)
at org.esa.snap.core.dataio.ProductSubsetBuilder.readBandRasterDataImpl(ProductSubsetBuilder.java:332)
at org.esa.snap.core.dataio.AbstractProductReader.readBandRasterData(AbstractProductReader.java:253)
at org.esa.snap.core.gpf.common.SubsetOp.computeTile(SubsetOp.java:288)
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: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: Java heap space
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:415)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computeTileStackForTOPSARProduct(InterferogramOp.java:1266)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computeTileStack(InterferogramOp.java:857)
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)
… 45 more
Caused by: org.esa.snap.core.gpf.OperatorException: Java heap space
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:415)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computePartialTile(InterferogramOp.java:1434)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computeTileStackForTOPSARProduct(InterferogramOp.java:1262)
… 49 more
Caused by: java.lang.OutOfMemoryError: Java heap space
at org.jblas.ComplexDoubleMatrix.(ComplexDoubleMatrix.java:82)
at org.jblas.ComplexDoubleMatrix.(ComplexDoubleMatrix.java:123)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computePartialTile(InterferogramOp.java:1348)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computeTileStackForTOPSARProduct(InterferogramOp.java:1262)
at org.esa.s1tbx.insar.gpf.InterferogramOp.computeTileStack(InterferogramOp.java:857)
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:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:461)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileInOneSwathFloat(TOPSARDeburstOp.java:895)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileStack(TOPSARDeburstOp.java:802)
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:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:461)
at org.jlinda.nest.gpf.SubtRefDemOp.computeTileStack(SubtRefDemOp.java:499)
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)
Error: Java heap space
– org.jblas INFO Deleting /tmp/jblas623249407796249456/libjblas_arch_flavor.so
– org.jblas INFO Deleting /tmp/jblas623249407796249456/libjblas.so
– org.jblas INFO Deleting /tmp/jblas623249407796249456
[1] Finished process in 95.0124218464 seconds.
I just solved this problem. Just reduce CATCH number. but need a little longer time.more 500 seconds.
Hi! Are you guys having some issues using the snap2stamps tool lately?
Specifically, executing the “python stamps_export.py project.conf” command.
For the past 2 days, after successfully completing coregistration and interferogram formation, the subsequent stamps export process does not progress and stuck in the first pair.
I am using SNAP 7 and not SNAP 8.
I specifically want to ask @ABraun and @mdelgado about this.
Thank you.
please have a look here:
1 Like
Hi, Abraun! Thank you for the quick reply. I will try the solutions stated on this separate topic.
Thank you again! 
yes, feel free to report.
I am still not entirely sure if this also applies when the inteferogram was calculated before the location of SRTM 3Sec changed. But I experienced the same error and do not have another explanation (neither do the developers at the moment)
Thanks @ABraun!
Still… it sounds funny that the SNAP operator StaMPSexport is not taking the dem band directly and convert its format, but it tries somehow to get access to the dem again.
Is it that? Or am I still missing anything else?
can this be seen by developers so that they can update the operator for more efficient and logical processing?
that’s what I wonder, yes. Doesn’t make sense, but I talked to the developers and using SRTM 1Sec or changing the SRTM 3Sec path is what they suggested.
Anyhow, this will be fixed when the new location of SRTM 3Sec is implemented, but still strange.
1 Like
hi i got the same problem but in version 8 updated today.
I saw that the file had to be modified:
but mine was updated today and I sensed that nothing had to be modified, because it was not the same as the indications previously offered.
So, some solution @ryeramirez @ABraun
if you have processed the interferograms with SRTM 1Sec, there should be no problem at all, because the download only affected SRTM 3Sec.
So the export still stops with SRTM 1Sec?
How do I know with which of the options the images were processed?
I did not modify any files, nor instructions.
In my ignorance, I think it used SRTM 1Sec, since if there are self-discharge problems, it is logical to think that it directly downloads SRTM 1Sec
In that case I would say yes, despite using SRTM 1Sec, snap2stamps stopped.
In this case SRTM 1Sec was used (line 69 of this file)
Very strange indeed, your screenshot also indicates that SRTM 1Sec was used. So the problem with the export is not related to the changed availabiltiy of SRTM 3Sec. You did nothing wrong, don’t worry - we just haven’t found the reason for the error in general.
Can you try with the SNAP GUI exporting a single pair using the StaMPS export operator?
Can you tell us if this works?