according to this topic (EAP phase correction not possible) the error on EAP Phase correction only occurs in old versions of SNAP. Are you sure you are using the latest version?
Could it be that I was confused on the update?
Should I have downloaded the program again and installed it instead of updating it directly?
yes, absolutely. The internal updates only cover updates within one version, but will not update from version 6 to version 8.
Hi, I finally reinstalled 8. But once again an error has occurred, in this case:
I know there is a solution from Error in SAR image corregistration: Error: [Nodeld: CreateStack] org.jblas.NativeBlas.dgemm(CCIIID[DII[DIID[DII)V) by @thho, but in this case for version 8 of SNAP with Ubuntu 18.04.5 LTS, I am not getting results with the libgfortran3 library
hi, I had the same problems as in this recent post: Error in SAR image corregistration: Error: [Nodeld: CreateStack] org.jblas.NativeBlas.dgemm(CCIIID[DII[DIID[DII)V)
even if you install libgfortran3 it doesn’t work for SNAP 8
The solution that does work is to go back to previous versions.
However, this conflicts with the idea of updating to the latest version to avoid conflict with SRTM.
So. Any guidelines on which version to use for SNAP-Stamps?
At this point I feel frustrated that I cannot go any way.
please also install libgfortran5, this has reportedly solved the issue here: Please test the SBAS_snap2stamps
Thank you very much for the answer, this easily solved the problem.
One question, I am using Ubuntu 18.04, but I think it is time to update it to Ubuntu 20.04.1 LTS, however I am afraid that the whole set of programs (SNAP, snap2stamps, matlab, train, etc) is not yet ready for it. Therefore, do you think it is feasible or advisable to do this update already?
sorry, I haven’t tested different settings - maybe someone who has updated Ubuntu can report here?
STAMPS: Will process patch subdirectories
STAMPS: ########################################
STAMPS: ################ Step 1 ################
STAMPS: ########################################
STAMPS: Directory is PATCH_1
PS_LOAD_INITIAL_GAMMA: Starting
PS_LOAD_INITIAL_GAMMA: Loading data into matlab…
master_master_flag =
'0'
READPARM: heading:=190.26904863170714
SETPARM: heading = 190.269
READPARM: radar_frequency:=5.40500045433435E9
SETPARM: lambda = 0.055466
READPARM: sensor:=SENTINEL-1A
SETPARM: platform = SENTINEL-1A
READPARM: range_pixel_spacing:=2
READPARM: near_range_slc:=901175.0317591032
READPARM: sar_to_earth_center:=7073347.970017257
READPARM: earth_radius_below_sensor:=6367489.32120738
READPARM: center_range_slc:=901175.0317591032
READPARM: azimuth_lines:=6882
READPARM: prf:=1717.128973878037
Index in position 2 exceeds array bounds.
Error in ps_load_initial_gamma (line 108)
rg=rgn+ij(:,3)*rps;
Error in stamps (line 263)
ps_load_initial_gamma;
Still i’m getting this error after re-installation of Matlab
And i replaced the ps_load_initial_gamma.m file also.
Please tell me is there any solution for this error?
hi,
I did the snap2stamps preprocessing and stamps processing using Ubuntu 20.04, and it worked well. i used SNAP version 8, executed snap2stamps with python 2.7 and used stampsV4.1 . i don’t recall having major problems with the processing.
Good luck
1 Like
Hello,
I think you have this error cause your working directory on matlab should be the “INSAR_…” folder not the “PATCH_1” folder. try to re-lunch matlab from your INSAR folder and re-run stamps.
I hope this was helpful.
Good luck
ABraun solved my error. Thank you for your response.
Software will calculate the values according to yearly basis. If you have imagery for 5 years then software will divide the result by 5 to get yearly value and if you work on 6 month then it will divide the value by 0.5 so it gives the results in yearly basis.
I hope it helped.
this is an approximation for shorter periods but based on the assumption that the deformation rate is constant over the investigated period.
1 Like
Hi @ABraun,
Regarding your answer to @Giova - I was just processing a small area (city of about 300,000 citizens).
I took one burst only - IW1 - and splitted out strips 4-6 for coregistration, then applied subset fot the AOI.
I wanted to go on with deburst, but I get the following error -
I though that the reason is that there is nothing to deburst since the AOI lies in single burst and strip, so I continued and created interferogram.
When I tried to StaMPS export it, I got the following error -
So since I cant deburst - what is happening here??
Thank you,
Oded
first you deburst, then you make a subset. But be careful - the subset of the coregistered stack and the subset of the interferograms need the exact same dimensions for the StaMPS export
Oh, it matters?
It would take a lot of time for nothing, I thought I can avoid it…
Why do I HAVE TO deburst?
So, the process have to be coreg - ifg - deburst - subset in this order?
Thank you,
Oded
yes. SLC data ist stored in separate sub-swaths and bursts, there is no way to avoid TOPS Deburst.
But as I said, the extent of the subset of the coregistered stack (first input of the StaMPS export) and the subset of the interferogram stack (second input) must be the same.
@ABraun
May I know what was the solution? I’m currently encountering the same error- I replaced the ps_load_initial_gamma.m and restarted matlab; Patch 1 seems to have been processed this time, but the error now has occurred for Patch 2.
This error message (index exceeds bounds) can have many reasons. When I got it in step 2, it was caused by a missing elevation band.
Please open one of the products from the ifg folder and check if all bands are valid.