Yes, indeed, Please take a look at the following post,
But for long time running, Please check up the following things,
SNAP update,
The RAM of your Machine
The processor might also affects,
The memory saving of your Machine
Continuing the discussion from SNAPHU Unwrapping:
E:\SNAPHU\snaphu-v1.4.2_win64\bin>snaphu
snaphu v1.4.2
usage: snaphu [options] infile linelength [options]
most common options:
-t use topography mode costs (default)
-d use deformation mode costs
-s use smooth-solution mode costs
-f read configuration parameters from file
-o write output to file
-a read amplitude data from file
-c read correlation data from file
-b perpendicular baseline (meters)
-i do initialization and exit
-l log runtime parameters to file
-v give verbose output
âmst use MST algorithm for initialization (default)
âmcf use MCF algorithm for initialization
type snaphu -h for a complete list of options
E:\SNAPHU\snaphu-v1.4.2_win64\bin>snaphu -f snaphu.conf Phase_ifg_VV_18Oct2014_01Jan2019.snaphu.img 17618
snaphu v1.4.2
27 parameters input from file snaphu.conf (84 lines total)
only one tileâdisregarding multiprocessor option
Logging run-time parameters to file snaphu.log
Reading wrapped phase from file Phase_ifg_VV_18Oct2014_01Jan2019.snaphu.img
No weight file specified. Assuming uniform weights
Reading correlation data from file coh_IW2_VV_18Oct2014_01Jan2019.snaphu.img
Calculating deformation-mode cost parameters
Building range cost arrays
Building azimuth cost arrays
Initializing flows with MCF algorithm
Setting up data structures for cs2 MCF solver
it stucks at here for 1 day. im using i5 8400, 8gb ram running on windows 10. where did i get wrong?
The RAM 8 GB , is not enough, Also the processor might be causes a problem, but coming back to the RAM issue, there are two solutions, first one you could subset your AOI, second one is , increasing the SNAP RAM as explained below by @marpet
Or you could try up both solutions,
For the SNAP Desktop application, you can increase the amount of memory available to SNAP.
In the âetcâ folder of the SNAP installation directory, youâll find a file named snap.conf. Open it in a text editor.
There is the line which starts with âdefault_options=â
In this line youâll find an option like -J-Xmx5G . Increase the value. You could use something like -J-Xmx13G , if you have enough memory in your computer. By default, it is set to ~75% of the maximum value. This is usually a good choice.
Problem solved!! I just multilook the image before unwrapping. Does multilook cause the result to be different? Im just curious since my system cant run the non multilook image. So i cant tell the difference.
@fakhrul
Multilook decreases the image size quite drastically (depending on your parameters) and also increases the phase quality (lower speckle). In general, it results in Multilook increasing the quality of the unwrapping process while decreasing a lot the processing time.
Except if very high fringe rate, I recommend always multilooking before unwrapping. With low amount of RAM (which is your case), this recommendation becomes a requirement.
2 Likes
as @qglaude answered your question
in here,
Thatâs mean, the source of your problem in your machine is the RAM, and the processor, So, subset, multilook, increasing the virtual RAM, should be taken in account in your future processing.
Iâve been experiencing a strange error with the unwrapping process that I hope someone can help with. No matter how small I subset and/or use heavy multilooking I keep getting this âUnexpected increase in total cost. Breaking loopâ error. Iâve also gone through the trouble doing fresh workflows w/new product downloads on three different machines.
Using the following product pair I took the following steps.
S1B_IW_SLC__1SDV_20190628T014958_20190628T015025_016890_01FC87_FC0D
S1B_IW_SLC__1SDV_20190710T014959_20190710T015026_017065_0201B8_069B
- S-1 TOPS ESD Coregistration
- Interferogram
- TOPSAR Deburst
- Subset*
- Goldstein Phase Filter
- Multilooking*
- Unwrapping error occurs after SNAPHU constructs tiles
*Tried process with & without these steps
Thank you~
have you tried switching between the unwrapping methods (MST/MCF)?
You can delete the temporary products (tiles folder and any data with a cryptic file name) in the snaphu folder, then modify the config file (select MST or MCF) and run the command again. Also slightly increasing the number of tiles could fix the error.
1 Like
ABraun,
Appreciate the quick reply, and thank you for pointing out a much quicker way to retry the unwrapping process! Iâve tried a lot of different unwrapping parameters, but will try more.
Another thing I wanted to bring up, that I only noticed recently, is the bursts looked distorted in the S-1 TOPS Split preview only(IW 2&3 burst 9 were distorted). Just now I went back to see if other granules in the same path/frame were also like this, and they were not. Going to try using a different pair of granules for now and probably try downloading the first pair from scihub.copernicus too. (I normally get everything from ASF, being in California itâs significantly faster. ~10mins vs ~2-5hours)
Thank you again,
Dake
the previews are just a rough estimate of the single bursts. They are more or less equidistant in all SLC products but the single imageâs frames can be shifted along-track between images of different acquisition dates.
Hope you manage to complete the unwrapping without errors.
I did just have to sit down and bang my head against the snaphu export parameters. Looking for any advice on attached output, curious if I can avoid some of the tiling distortions even with my limited hardware.
Hope itâs alright to share kmzâs: https://drive.google.com/open?id=1EcH1Oig46QJdwlv6XYMREXEUKlNnV2T7
Thank you again for your help.
they look quite strange (but nice result overall!)
What did you select for
- statistical cost mode
- initial method
- number of tile rows / columns
- row / column overlap
- tile cost threshold
?
Statistical cost mode: DEFO
Initial method: MCF
Tile rows / columns: 80/80
Row / column overlap: 0/0
Cost threshold: 500
I would recommend to reduce the number of tiles to 12/12 and increase the overlap to at least 100. More is advised but it depends on the size of the single tiles (total number of rows divided by the number of tiles) how large you can make the overlap variable. If your tiles are only 50x50 pixels, the overlap cannot be larger and should be in relation to the total size.
1 Like
I would like to see the coherence estimation carried through snaphu unwrapping to the terrain corrected product in SNAP. The coherence image is a useful supplement to the deformation map in assessing data quality and emphasizing discontinuities in the data (faults in the case of seismic deformation.
Did the direction of interferomic displacement reverse between Snap versions 6 and 7? What was up in 6 is now down in 7? Other than installing 7, I had changed coherence window in interferogram formation from 20/10 to 10/3
Maybe has to do with this issue https://senbox.atlassian.net/browse/SITBX-640 ?
Does the processing sequence for radar interfermetry change between v6 and 7? Around the deramp and demod processes?
In v6 I was using the menu steps. In v7 I changed to the Graph Process Tool. Maybe there are difference in default parameters between GPT and the menu steps?
Hi, I had have problems for download the images that are of the last year. I Donât know what is the reason. but I want know how Ican download it now?.
Please use the search function of this forum. This has been answered here:
ESA Copernicus data access - Long Term Archive and its drawbacks
qglaude explains why this is the case and how you get the products. There are also some alternatives discussed in the topic.
Hi!
I am having some trouble with unwrapped interferogram (Please see the image).
First interferogram is between July 1 and July 13. Second interferogram is between July 13 and july 25, and third is between July 25 and August 6. First and third interferograms look fine, however, second interferogram has a big line that does not make sense to me. Since more than one interferograms are made from same date, I think the image does not have any problem. So, what do you think the cause of error? Is it unwrapping problem, memory error or something different? Can you please suggest the remedy? Thank you for help!
it is probably related to the tiling of snaphu.
Please make sure you add some overlap between the different tiles in the snaphu.conf file
Some comments on this (and a suitable tile size) are given here: SNAPHU parameters
Hello again!
Thank you for help. However, I am still getting the line, plus the image has become even worse. Previous image was better than this. I think this is the problem related to deburst process, since all the lines are seen at perfect definite intervals (Please see image). This happened after I gave tile overlap of 200 pixels. Anything else that I can try?
List item