New StaMPS release (4.1-beta)

Hi, do you have one for Small_baselines, sb_load_initial_gamma.m?
I have the following error when I used the current sb one after it calculates the baselines for each of the interferograms, I think it is trying to sort local coordinates?

READPARM: initial_baseline_rate:=0.0000000 -0.1139888 -0.0192730
Index in position 1 exceeds array bounds (must not exceed 2).

Error in sb_load_initial_gamma (line 146)
bl=mean(sort_x(1:n_pc,:)); % bottom left corner

Error in stamps (line 221)
** sb_load_initial_gamma;**

1 Like

How are you?
First of all, thank you very much for dedicating so much to the stamps so that we can all work with them today.
I’m processing Sentinel 1 images, and I’ve done, I guess, all the steps before exporting to stamps correctly.
After running the mt_prep_snap routine without problems, I execute the steps of stamps (from 1 to 8) without problems, however when visualizing the results I find that the first 6 interferograms look good and the remaining ones present failures. It seems that the values are “out of order” or something like that.

If we look at the interferograms (.diff) in snap, for example 6 (02032017) and 7 (04042017) , we see that apparently there is no problem, however in the graph of w (above) the first one has been imported to the stamps correctly and the second one has not.

When obtaining the average speed graph (v-do), the result seems quite consistent, which also calls my attention.

I have exported the data to stamps again from snap, and run mt_prep_snap again, and I still have the same problem. I have checked every file in the geo, diff, dem and rslc folder. I’m using 35 patches, with an ad of 0.4. I don’t know at this moment what could be the source of the error, any idea?
Thank you very much.

Interesting case, I have never seen such an error. The only thing which sounds a bit odd to me is the 35 patches. Whatever you enter at the end of mt_prep_snap should result in an even number of patches. e.g. ...2 3 results in 6 patches. 35 sounds way too high to me, especially with an overlap of 50 to 200 pixels, as suggested in the manual. Could be the reason for the strange pattern, but does not explain why it does not affect the first few.

1 Like

Hi, @ABraun
I never thought about the number of patches as a problem with this.
I already tried it with 6, 15 and 20 patches, and the problem is still there.
In all cases, I get almost the same number of PS candidates.

Please try to make the plot ps_plot(‘u-dmo’,1), I would like to see if there is anything on the scripts… as the ps_plot(‘v-do’,1) looks fine to me.

Hello, @mdelgado
Sorry for the delay.
Here is the result for the u-dmo with 35 patches.

The process with 6 patches gave the same results.
I’d rule out that the number of patches is the problem.

One thing that strikes me is that in the center of the deformation observed in the first ifgs, there is a lake (black dots) and that remains in all ifgs.

This could be due a non-PS on those positions. Hence, no data, black or white depending on the background color selected.

Here the strange effect on the lines seems not be present or not that strong. Do you agree?

Yes, I know. But somehow the location of those non-PS is repeated throughout all the ifgs and the PS are the ones that look messy.
I think that for example the December 31st 2018 motif, should look similar to some of the first 7 graphs. Although the ifgs don’t look similar, in the above chart, but they do in the corresponding .par files.

It seems to me that the unwrapping smooths the effect, will it be by the unwrapping process itself?

if there is water in at least one of both images used for the interferogram, no PS are detected here. Is it a permanent lake?

Yes, it is, @ABraun.

It seems that the PS points are not in order, so if you look at the 7th ifgs (the image of w_stamps above), you can see a feature similar to a stripe, but displaced. It seems to me that they are diagonal stripes with a sw - ne direction or similar.

A small hint for those running into errors such as Error opening file ../INSAR_20191215/rslc/20191004.rslc or Error opening file pscands.1.ij as mt_prep_snap executes the mt_extract_cands command: mt_prep_snap expects the path to be absolute.

For those inisting on relative paths, this can be solved by using mt_prep_snap 20191215 $(realpath ../INSAR_20191215) 0.35 instead.


I have completed steps till 6. When I try to view the results I am getting this error.

1 Like

Somehow the variable is not recognized by stamps. Maybe you can set it manually
setparm('small_baseline_flag', 'n')

Now I am getting like this. Matlab got closed while I am processing, then I had to call again from stamps. Is the error happening because of it?

Please check the permissions of your working directory.

Solved the permission issue by rerunning all the processes in a different folder.Still the old issue persists…

this is strange. Are you sure you are using the latest versions of StaMPS and sourced it correctly?

Although I have never seen this error, it looks like some scripts of previous versions are mixed with more updated ones . I’m afraid I run out of ideas.

1 Like

Yeah may be, I think I may have messed up the scripts. I will reinstall the stamps, how do I completely remove the stamps installation?
Before starting the matlab process I have sourced the stamps in terminal using the stamps_config.bash given below.

the most important line is the first: export STAMPS
This is the directory where all scripts are taken from.

If there is any other version, you can delete it. But as your processing has some issues, you can also consider removing all StaMPS files completely and install StaMPS again.
TRIANGLE and SNAPHU should not be affected.

1 Like

I will uninstall and start again. How do I uninstall stamps from ubuntu? I tried sudo make uninstall from the current directory but it didn’t work.