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)
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.
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.
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.
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 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.
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.