is it a problem when the bursts are shifted along-track?
I get the message at step three, coregistration:
Error: [NodeId: Back-Geocoding] Same sub-swath is expected.
Hi @ABraun,
Actually I do not think so. Just ensure that your data covers your AOI.
What you shows it is an error message from the SNAP Back-Geocoding Operator and not from the snap2stamps scripts. But from the image I think that one of more your slaves images do not cover the entire master, and probably, there are burst in the master with no correspondence with your slaves.
Can you check that? If so, could you put the slave image with the missed burst in the slave folder to be assembled?
In addition, if you could check the content of the coreg_ifg2run.xml produced and used by SNAP we can have a better overview of what it is happening.
1 Like
now I feel dumb…
I had written the wrong IW in project.conf and therefore, all slaves were outside the master.
Things like that happens to everybody. It is fine to keep checking the scripts to verify that everything works.
In such case just need to correct it in the project.conf and launch the commands. Snap2stamps will do the rest for you! 
1 Like
I have completed the analysis for the Ruhr area in Western Germany which heavily sinks due to mining activities.
I used 36 Sentinel-1 images which produced over 400000 PS. After strong weeding (std=0.5) 150000 remained which give a nice picture of the pattern. The only strange thing is that the values and the colour ramps are inverted. The largest displacement should actually be in the middle of the image.
But this is rather a StaMPS configuration issue and not related to the preprocessing, this works very well - congratulations and thanks again!
This is ps_plot(‘vs’,4)
6 Likes
Thanks @ABraun for sharing with us the results and for testing snap2stamps ! 
Just note that you have plotted the standard deviation of velocities ps_plot(‘vs’) and not the LOS deformation velocities ps_plot(‘v-d’) (minus DEM error). Maybe that plot is more likely what you are looking for.
Really glad to help users in making easier PSI using SNAP and StaMPS.
Still many things to be done and improved!
3 Likes
you were right… 
You see, I didn’t come to the plotting part very often. But this will change in the future, now that your tool helps me to get through more quickly.
looks better!
4 Likes
I’m testing again at another site and found that the lat/lon bands and the dem bands are written for every coregistered pair. Probably because it was easier to implement, but it could potentially save a considerable amount of disk space (and a little computing time) if this was done only once.
Just a thought, you probably have your reasons.
The dem band is needed in the StaMPS export operator (I believe it is the same for lat/lon but I am not sure as in previous version of the operator it was not). Maybe @marpet can say something more precise than me in that regard.
Indeed having dem and lat/lon in all the pairs is wasted time and disk space.
We could think in a solution for that in the python scripts to remove non-necesary data.
Thanks for the comment! Indeed I should start thinking in optimizing and improving them.
It is indeed needed for the StaMPS export, but as you say, not in every product.
1 Like
Unfortunately it is a trade-of between RAM and HDD needed for the processing.
Orginally, you could do the stamps export of stacks of interferograms 1 master with several slaves, for which only one band of lat/lon and dem was saved.
Unfortunately, this solution requires a very powerful computer, able to load in RAM all the stack (specially difficult when working with large S-1 series), so I adopted the solution of working single pair master-slave, but then incrementing the extra info as the lat/lon and dem.
Maybe in the future StaMPS operator could be modified for accepting also the export without lat/lon and dem, so our solution would not have to keep them until the end.
Or another solution could be trying to change this extra bands by soft-links of the real information that could be saved in only one pair. It must be worth trying as at the end 3 bands for 150 pairs… could be removed from the space needed. But again, repercusions should be analysed.
For the moment the important fact is as it is, SNAP+snap2stamps+StaMPS PSI works perfectly, and it should be a bit deeper analysed how to optimise the resources needed for such kind of processing
that is true. It is good as it is now, because RAM is surely the more important factor, I would say.
1 Like
Hi, mdelgado
Could you please help with some proccesing errors in snap2stamps.
I have the following errors:
Java heap space (java.lang.NullPointerException)
GC overhead limit exceeded
Cannot construct DataBuffer
I use an ubuntu workstation with 12 cores and 24 Gb memory for processing a stack of 17 sentinel slc.
A full log from terminal and coreg_ifg2run.xm included.
Thanks in advance.
snap2stamps.txt (26.8 KB)
coreg_ifg2run.xml (7.0 KB)
that means not enough RAM was available to this process. Did you adjust the memory variable in project.conf?
According to your system I would suggest:
# COMPUTING RESOURCES TO EMPLOY
CPU=12
CACHE=20GHi ABraun,
I have the following settings:
CPU=24
CACHE=20G
As I understood it is necessary to specify logical cores (hyper-threading) of the processor instead of physical, or not?
you’re probably right. But then I wonder why SNAP returns this error…
Very interesting but in SNAP GUI all procedures are processed (in manual) without any errors.
Hi @Stoorm,
Probably you forgot to set up the maximum memory for SNAP GPT, found in different file that SNAP GUI.
Please check the -Xmx memory assigned on the $SNAPFOLDER/bin/gpt.vmoptions (maybe I should include this in the user manual)
Let me know as the errors you mentioned are directly SNAP logs saying, as @Abraun mentioned, that you need more memory (or the memory specified in the gpt configuration is not enough).
I guess this may help you to solve your issue but please keep me posted
Hi @mdelgado, thank you for reply.
My gpn.vmoptions settings:
-Xmx15G
Is it bad that the size of the allocated memory does not match with project.conf file?
In fact there are 2 types of memory. The -Xmx is the one allocated for the Java Virtual Machine that SNAP uses, and the one on the project file for the cache memory.
Thank for the comment. In the future we can include also this one on the project.conf.
Please put more for the JVM than for the cache memory. I use normally 16G for the cache and 25GB for the Xmx (JVM) and it worked ok, but I normally use few burst interferograms
1 Like