I run the command in the shell as you see,
Then I tried to get started in matlab, I got this error,
I’m in the directory in matlab
I run the command in the shell as you see,
Then I tried to get started in matlab, I got this error,
I’m in the directory in matlab
your PSI folder doesn’t contain PATCH_1 or all the other files created by mt_prep_snap.
This is how it should look like after the execution of the script.
This is the folder which must be used in matlab. Type getparm to see if all data is loaded correctly.
I also suggest not to run steps 1-8 with one command. Execute them one after another to be able to read the output and change the parameters accordingly.
stamps(1,1)
stamps(2,2)
ect.
It has but the command was running out of the folder, But now it runs
I totally agree with you, but it was only test.
the same was recently reported here: StaMPS processing error
I don’t have a solution for it. How many images are you using?
Please also have a look at mdelgado’s comments here: Error in SNAP - StaMPS processing of RS2 data: "Index in position 1 is invalid"
I’m using 27 images.
You may try with this function I have modified time ago. I hope it works for you.
ps_load_initial_gamma.m (7.2 KB)
It should be used on the stamps step 1. So before you override the current one on the stamps_v4.1b/matlab/ please make a backup.
Then please run again the command stamps(1,1) so you re-run step1 to use this function
Let me know if this helps
Hello Jose,
Thanks a lot, I followed your instructions, and so far ‘stamps (2,2)’ works fine, I removed all the results and rerun ‘mt_prep_snap’ again, then I run ‘stamps (1,1)’ later on ‘stamps (2,2)’ .
Your modified function worked and solved the issue,
Now I’ll continue, I’ll let you know,
Hello
I had been processing with StaMPS 3.1b1 but now I have installed StaMPS 4.1-beta. Is mt_prep_snap the official file or is there another modified one?
Thank you.
Thanks for the information. I will send it to the github distribution so they will have the updated version.
@CFEgildan71 the mt_prep_snap version comes along in the stamps 4.1beta version.
This is the first results wrapped phase, I used (StaMPS 4.1b) I didn’t change any of parameters, the goal is to overcome all the technical issues, thanks go to @mdelgado and @ABraun for their efforts and opinions.
ps_plot(‘w’)
good job! Congratulations on sticking to the issue and thanks to @mdelgado for his contribution here. Can you shortly describe what you changed in the matlab script - was it a bug or just covering an exception?
Thanks Andy, I do think there were three bugs, because, when I run debuging and put up break points, the processing was running until the line of bug.
It seems other issue in StaMPS release (4.1-beta),
To drop unwanted infgms, this function is applied setparm(‘scla_d’,[1:2]) it has the following error,
Any suggestions to reach the final step,
Please check how to use the function. scla_deramp can only get values ‘y’ or ‘n’ so use it accordingly.
Use the command such as
setparm(‘scla_deramp’,‘y’) If you want to apply it, or
setparm(‘scla_deramp’,‘n’) if you do not want to apply it
Cheers
Hello @falahfakhri
How did you select the master to be the first image of the year?
How many images process?
I have duplicated David Bekaert’s strategy identify NaNs (so I include the case where pixels have 0’s) to not include them in the analisis on next steps. As index with 0’s and NaNs gives problems while indexing ij or latlon into matrixes.
No bug! This is not somthing introduced by StaMPS, but SNAP, which saves pixel valuess with 0 or NaNs (to be investigated why exactly this happens). Before SNAP saving 0s and NaNs values on matrix or geological coordinates, non DInSAR processor compatible with StaMPS was doing that before, so StaMPS scripts had not included such verification commands.
But now StaMPS does solve this problem.
Another alternative to handle this could be not to save those values directly from SNAP, but also SNAP currently does not do anything special for these cases.
I can see trends in many of the interferograms. If I were you I would try to remove them before publishing results in other sites.
In my opinion, these trends could be either orbit related error or troposphere related artefacts (but still other people believe that S1 does not introduce orbit errors while using Precise Orbits, so it could be a point for discussion)