Snap2stamps package: a free tool to automate the SNAP-StaMPS Workflow

@GijsIi checked .snap/auxdata/dem directory, hgt1sec files is downloaded and cover my ROI. what is wrong do you think?

external geotiff dem must be put in aux/dem directory?

you can put the dem wherever you like as long as you supply the full path to it.

if you have no error during coreg_ifg_topsar.py but do have empty results there is probably something wrong with the data. so as i said this can be the dem, or you are combining ascending an descending tracks or different relative orbits or maybe even the same data day?

hard for us to judge without any error log.

Dear Gijs
thanks, i will run again and let you know about my results

Hello All
I am sorry for disturbing again, I ran snap2stamps from the first step, it didn’t return any error, slaves directory prepared well, split files have good size,dem and orbit files have been downloaded , but when command python coreg_ifg_topsar.py project.conf has been run, it seems locked in the first slave splitted directory and didn’t show progress. is there any solution?

You should check:

  1. how much memory you had set up for cache
  2. how busy is your system (htop or similar commands)
  3. whether is doing something… normally this depend on how many bursts has your master image.

Let us know

Hello dear mdelgado
my cache is 12G, it took more than 6 hours, I only processed a snap2stamps and only 3bursts has been selected.

What about the computer resources?
Could you monitor the processing?

For me similar processing 3 burst with 16G cache on a 8vCPUs and 32GB RAM computer that process took 3min per interferogram pair.

So I can only suggest to check the snap (snap.conf and snap.properties) and system parameters

Hello All
I had a problem when i ran the stamps_export.py like this one… is there any solutions for this problem? thanks…

Where is the problem?
it seems successfully completed to me

i have problem when i ran python stamps_export.py project.conf, aftering running it, it seems locked in the first master-slave pair and didn’t show progress. is there any solution. this is my project.conf.

PROJECT DEFINITION

PROJECTFOLDER=/media/mzf/0A9AD66165F33762/work/PROC
GRAPHSFOLDER=/media/mzf/0A9AD66165F33762/work/GRAPH
##################################

PROCESSING PARAMETERS

IW1=IW2
MASTER=/media/mzf/0A9AD66165F33762/work/PROC/MASTR/S1A_IW_SLC__1SDV_20190820T230320_20190820T230347_028659_033E4A_AFB6_Orb.dim
##################################

AOI BBOX DEFINITION

LONMIN=104.95
LATMIN=34.85
LONMAX=105.25
LATMAX=35.15
##################################

SNAP GPT

GPTBIN_PATH=/media/mzf/0A9AD66165F33762/snap/bin/gpt
##################################

COMPUTING RESOURCES TO EMPLOY

CPU=6
CACHE=16G

I see your master product ends with “_Orb.dim”. I think you should apply TOPS Split to your master as well, because the naming convention as @mdelgado described here:

If you need all bursts, I still recommend adding “_Split” to the product name just to go sure, because the script expects this structure to correctly extract the date from the master image’s file name.

1 Like

I am sorry for disturbing again,i applied TOPS Split to my master before, and i added “_Split” to the product name just now, and try it again, but it also doesn’t work. Is there any other solution?

How many bursts did you use?
Coregistering is a quite computationally intensive task, it is usually taking several minutes to hours, depending on the size of the data.

Or do you get a different error message now?

Hi mdelgado ,
I check this error when using the command “python coreg_ifg.py project.conf”

WARNING: org.esa.snap.core.gpf.common.SubsetOp: No intersection with source product boundary S1A_IW_SLC__1SDV_20180724T060252_20180724T060319_022932_027CF4_3860_split_Orb_Stack_Deb
IFG: isTOPSARBurstProduct = true
WARNING: org.esa.snap.core.gpf.common.SubsetOp: No intersection with source product boundary S1A_IW_SLC__1SDV_20180724T060252_20180724T060319_022932_027CF4_3860_split_Orb_Stack_Ifg_Deb_DInSAR

is there any solution to resolve it ???
cheers.

Well… my first guess when seeing the error you pointed: SubsetOp: No intersection with source product boundary is that you have not correctly defined the LATMIN, LATMAX, LONMIN and LONMAX coordinates in the project.conf file.

Please check it out and let us know

Good Morning ,
i think the problem in Splitting , what do you think too ??
[6] Folder: 20190929
/home/miloudi/software/chlef/slaves/20190929
[’/home/miloudi/software/chlef/slaves/20190929/S1A_IW_SLC__1SDV_20190929T060301_20190929T060328_029232_03521C_8885.zip’]
FILE(s) : /home/miloudi/software/chlef/slaves/20190929/S1A_IW_SLC__1SDV_20190929T060301_20190929T060328_029232_03521C_8885.zip
[’/usr/local/snap/bin/gpt’, ‘/home/miloudi/software/chlef/graphs/splitgraph2run.xml’, ‘-c’, ‘6G’, ‘-q’, ‘4’]
SNAP STDOUT:SEVERE: org.esa.s2tbx.dataio.gdal.activator.GDALDistributionInstaller: The environment variable LD_LIBRARY_PATH is not set. It must contain the current folder ‘.’.
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
…10%…20%…30%…40%…50%…60%…70%…80%…90% done.

[6] Finished process in 95.3614559174 seconds.
Split slave [’/home/miloudi/software/chlef/slaves/20190929/S1A_IW_SLC__1SDV_20190929T060301_20190929T060328_029232_03521C_8885.zip’] successfully completed.

thanks in advance

It seems to me that this had not any issues.

it seems that the problem is here ??? what do you think??
SNAP STDOUT:SEVERE: org.esa.s2tbx.dataio.gdal.activator.GDALDistributionInstaller: The environment variable LD_LIBRARY_PATH is not set. It must contain the current folder ‘.’

This is not causing a problem at all…
please not that is a WARNING and related to sentinel-2 toolbox, which is not used on S1 processing.

If you wish, add the LD_LIBRARY_PATH to the current environment to avoid this WARNING message, and you could check that the output is exactly the same.

Your problem, as said some posts before, is due to the SubsetOp that is used only in the coregistration/interferogram step, and not before. Probably you defined the LAT/LON coordinates wrong in the project.conf (PLEASE CHECK THIS)

Maybe you splitted the wrong IW… this is my last guess… (but this is not related to the severe warning you are pointing out)

I hope this helps.
Good luck!