if one patch is smaller than 200 pixels, it might be a problem. But I am not sure if this is the case here. Maybe you run mt_prep_snap again with only 6 patches (3 2)
Same results with 6 patches (tried the same parameter settings as above again).
Would continuing to reduce the number of patches do anything at this point?
I’ve also been considering re-processing using 3 or 4 bursts, although I had hoped to process this dataset to all the way through to obtain preliminary results. Could that potentially resolve this?
if 9 or 6 make no difference, I’m afraid this is not the reason for the error, but it could be worth a try with 4 patches (2 2) and less overlap (20 100) to go 100% sure. I was suspecting that the overlap is larger than one patch located at the edge.
The results are the same; after adjusting the density parameters (density_rand = 90) and applying setparm(‘filter_grid_size’, 10) Matlab seemed stuck on step 2 (my hard drive even went to sleep), so I reset filter_grid_size and kept the same density- step 3 continued to select 0 PS for all four patches.
Any other possible solutions? Is it at all likely at this point I’ll need to re-process with more bursts?
This so far is the most I’ve been able to find, in the mainsar group:
I checked the ps_select.m. I noticed that the raison causing this problem is the “ok_ix” is empty, which means the “percent_rand” values are all bigger than “max_percent_rand” value. one thing not normal is that the “percent_rand” values are too big like hundreds , thousands, which make it impossible to get through this no matter what “max_percent_rand” value we set.
this"percent_rand" values are depending on the “Nr”. does anyone know what kinds of Nr is correct and what is not?
what is the source of this problem?
thank you
Yu
https://groups.google.com/g/mainsar/c/JPibrQx4yB8/m/rXPEPwMjKh8J[ps_select.m|attachment]
ps_select.m (15.2 KB)
That doesn’t seem to be the case as far as I can tell, but I’ve uploaded my ps_select.m just in case.
This is saying the key!
Please check all interferograms as you may have some of them not successfully written or corrupted.
I have checked many throughout the dataset (not all, but I will now), examined RGB and elevation images- nothing so far has seemed erroneous. What sorts of indicators should we look for?
.
Hi @danm
I had the same error yesterday. I don’t know why this fixed it, but it occurred with (3 2) and (3 3) patches, but when I changed it to (2 2) it worked. I also made small adjustments to the amplitude dispersion threshold when calling mt_prep_snap, but I don’t think this was the reason.
So I guess it is somehow related to the size of the patches, but I cannot tell exactly.
Should reprocessing with more bursts resolve this then?
I used 3 bursts in my example and haven’t changed it while trying.
So depending on how large your exported rasters are, you could try
- using only two patches (2 1) or (1 2)
- transpose the patches (2 3) instead of (3 2)
Had you used the mt_prep_snap or mt_prep_gamma?
can you paste the calam.out file?
I would expect that either input data is corrupt or wrongly interpret or NaNs or 0s values in lat/lon bands.
If non of them, maybe partial ifgs or empty ones.
mt_prep_snap
Attached calamp.out- still have not reviewed all ifgs (multiple projects currently)
calamp.out (13.0 KB)
Hello @danm,
How did you solve your problem?
I am facing the same problem. Step 3 gives me ‘0 PS selected’.
Since I have almost 60 interferograms, it’s quite hard to check them all.
By size, they are all the same - 26MB.
Thanks,
Oded
Calamp file looks fine.
Had you had the change to visualise the interferograms?
I bet that at least 1 ifg is full of zeros…
Let me know
By enlarging the study area to include more stable (e.g. urban) objects.
1 Like
I’m pleased to report I’ve managed to obtain an end product from the finished StaMPS process (with a partial data set of 40 images; I’ll be re-attempting it now with a 120+ image set).
That is the output from running ps_plot(‘v-d’,1,0,0) after the last StaMPS step finishes, which if I’ve interpreted the manual correctly, displays mean displacement velocity at each point?
I used the latest SNAP 8 with Ubuntu 18.04 LTS (computer specs in OP) and a 32 GB ram. All processing (from start to end) was carried out on a WD easystore 8 tb external hard drive, following almost exclusively the workflow referenced here How to prepare Sentinel-1 images stack for PSI/SBAS in SNAP - #514 by thho (except I configured SNAP for python2.7 using the installer, not manually).
These are the project.conf, stamps_config.bash, and gpt.vmoptions files
All images were Sentinel-1a ascending; I used IW2 and three 3 bursts (still had to edit the coreg_ifg xml files, as described here How to prepare Sentinel-1 images stack for PSI/SBAS in SNAP - #514 by thho )
Thank you @mdelgado, @marpet , for providing these products which will be of great use! And thank you especially @ABraun for all the help!
Are there any further details I should look into at this point, to further validate quality?
I just realized this message appeared when I ran mt_prep_snap. Any major issue?
3 Likes
Good job, congratulations!
Now you can try to tweak the variables most suitable for your case. There are some great explanations given here: StaMPS/2-4_StaMPS-steps.md · master · Matthias Schlögl / gis-blog · GitLab
At the end, variable configurations are recommended for different use cases.
It is always good to plot the time series of a local area to check if the temporal displacement makes sense.
Ok, thanks.
I’ve managed to successfully repeat the process for a different location, but I’ve still not been able to run plot_v.gmt - I copied it into the INSAR processing folder, but upon attempting to run it at the end of stamps I receive the error
Unable to resolve the name plot_v.gmt
I ran ps_output and ps plot(‘v-d’,-1) beforehand to see if those help, but not change.
Couldn’t find any posts here or on MAINSAR regarding the issue. Any suggestions?
All of my interferograms contain data values and this error has occured after changing the da threshold in mt_prep_snap from 0.4 to 0.42 and while keeping the same number of patches as before. In patch 1 for example, when the da was 0.4, step (3) worked like a charm, but the same patch with da 0.42, this error message appeared. I only had to change the da value because some patches didn’t have sufficient PS pixels after step 3 to get weeded
This is really weird but I figured out what’s causing this error.
Type:
setparm(‘density_rand’, 50)
instead of
setparm(‘density_rand’, ‘50’)
Drop the quotes from the number
1 Like
