About coherence and multilooking

[Malvas]

Hi everyone,

I'm working on a short (one year) InSAR time series for a volcanic region. I processed the stack with stackSentinel in ISCE. Now I'm analyzing the results obtained after the processing with MintPy. As you can see in the attached unwrapping phase-plot, it seems that the phase unwrapping was not well resolved during the stack processing. I have to say, that this region presents a lot of decorrelation because of atmospheric conditions (proximity with the sea), loose material (erosion/deposition of volcanic material), snow, among others.

For the stack processing, I defined an interferogram network with 3 sequential connections, a filter strength of 0.6 and a multilooking of 5 in range and 1 in azimuth (5x1) based on the annotations of the slc images for this region (to maintain the full ground resolution (11x13)):

      <rangePixelSpacing>2.329562e+00</rangePixelSpacing>
      <azimuthPixelSpacing>1.393230e+01</azimuthPixelSpacing>

For the small-baseline time series processing, I set the run with a temporal coherence threshold of 0.6 (risking quality) and used the bridging method for unwrapping error correction. As can be seen from the temporal coherence plot and network plot, I have problems with the coherence. Naturally, working with few looks for the stack processing implies an increased noise level. However, because of the region I'm trying to keep the full ground resolution, as I said before. But now I'm considering to redefine my stack by increasing the number of looks and trying to find a compromise/tradeoff.

So, my question (maybe for Yunjun or Eric) is what do you recommend in this case to improve coherence? Or should I definitely try to solve this by applying more multilooking?

I would appreciate it if you would also take a look at the connected components plot and the T_int plot, which I'm also attaching.

Cheers,

Alejandra

[Zhang Yunjun]

Hi Alejandra,

First, your temporal coherence looks not bad at all. Below are my suggestions:

+ It seems that you applied a network modification with a spatial coherence threshold of 0.6, which is pretty high; I would 1) use a proper water mask is generated, to ensure the average spatial coherence used in the network modification is representative; 2) try lower the threshold to 0.4 or even unset it, to let the weighted inversion taking care of the low coherent pixels; 3) if the peak of the volcano is your area of interest, try using the mintpy.network.aoiLALO option to further remove pairs with low coherence around the peak; 4) generate more pairs/connections during the isce stage (5 or more), it's better to have low coherent pairs and discard them than to miss potentially high coherent pairs.

+ as you have said, there is a tradeoff between filtering, multilooking and spatial coherence; it's really a try and error process. FYI, there is a ~0.5 scaling factor between the (slant) range pixel spacing and ground range; and 0.9 scaling factor between (orbit) azimuth pixel spacing and ground azimuth, thus, a rough ratio of 3:1 is usually used to give a square shape. You may find this notebook helpful for this (https://nbviewer.org/github/insarlab/MintPy-tutorial/blob/main/applications/calc_multilook_number.ipynb).

+ Your T_int plot looks good: no peaks for T_int > 0, which means no massive unwrapping errors. I would check the performance of the unwrapping error correction (bridging, phase closure), via the temporal coherence (without vs. with the correction), and see if there is noticeable improvement, otherwise, it's not worthy to turn it on.

Cheers,

Yunjun

[Alejandra]

Hi Yunjun,

Thank you for your very helpful reply!

I ran a new interferogram stack with more connections (5), with a multilooking of 8x2 (the notebook was really helpful!) and unsetting the coherence-based network modification. The results look much better. However, this time there is a peak for T_int > 0 (see attached plots).

Now, I'll discard low coherent pairs (using mintpy.network.excludeIfgIndex) and process the small-baseline time series again. And here there is something I would like to understand: if I define some low coherence interferograms to exclude, should I also set mintpy.network.keepMinSpanTree = no ? Or does the Minimum Spanning Tree network work only in case of a data-driven network modification (which in my case is unset)?

One last question I have is, in case that I set the the mintpy.network.aoiLALO option, should I therefore also set the coherence-based network modification with a threshold of (e.g.) 0.4?

I would appreciate your comments!

Cheers,

Alejandra

--
You received this message because you are subscribed to the Google Groups "MintPy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mintpy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mintpy/b9a92efb-427b-43d7-8c1a-d1350c279197n%40googlegroups.com.

[Zhang Yunjun]

Hi Alejandra,

Now your result looks great! The T_int peak at 0 (and not peak for T_int > 0) is a good thing.

>  if I define some low coherence interferograms to exclude, should I also set mintpy.network.keepMinSpanTree = no ? Or does the Minimum Spanning Tree network work only in case of a data-driven network modification (which in my case is unset)?

The MST network works only for data-driven modification, as you may have seen it in the comment here (https://github.com/insarlab/MintPy/blob/386ff9b3ee9f20411e4c621da4b42532094971b6/src/mintpy/defaults/smallbaselineApp.cfg#L106-L110).

> One last question I have is, in case that I set the the mintpy.network.aoiLALO option, should I therefore also set the coherence-based network modification with a threshold of (e.g.) 0.4?

The *aoiLALO option works only for data-driven modification as well. If you set *aoiLALO and unset *coherenceBased option, the coherence-based network modification will not run.

I hope this helps,
Yunjun

[Alejandra]

Hi Yunjun,

I'm still working on this processing (this time with the ascending pass). The volcanic region I'm working on is characterized by high topography. The contribution of tropospheric delay is therefore proportional. I initially tried to correct tropospheric delay using pyaps with ERA5 but the results didn't convince me (see attached file "asc_pyaps" - Mean LOS velocity). Then I used the height correlation method to correct tropospheric errors (see attached file "asc_hc" - Mean LOS velocity) with this configuration:

########## 6. correct_troposphere (optional but recommended)

mintpy.troposphericDelay.method = height_correlation  #[pyaps / height_correlation / gacos / no], auto for pyaps

mintpy.troposphericDelay.polyOrder         = 2  #[1 / 2 / 3], auto for 1
mintpy.troposphericDelay.looks                = auto  #[1-inf], auto for 8, extra multilooking num
mintpy.troposphericDelay.minCorrelation = auto  #[0.0-1.0], auto for 0

########## 8. correct_topography (optional but recommended)
mintpy.topographicResidual                                = auto  #[yes / no], auto for yes
mintpy.topographicResidual.polyOrder               = auto  #[1-inf], auto for 2, poly order of temporal deformation model
mintpy.topographicResidual.phaseVelocity         = auto  #[yes / no], auto for no - use phase velocity for minimization
mintpy.topographicResidual.stepFuncDate         = auto  #[20080529,20190704T1733 / no], auto for no, date of step jump
mintpy.topographicResidual.excludeDate           = auto  #[20070321 / txtFile / no], auto for exclude_date.txt
mintpy.topographicResidual.pixelwiseGeometry = auto  #[yes / no], auto for yes, use pixel-wise geometry info

Although the results with the high correlation method seem to be better, there is a positive signal on the west and north-west borders that very clearly correlates with the topography. I used the DEM obtained with the ISCE DEM download script. What do you recommend to overcome this issue?

Cheers,

Alejandra

To view this discussion on the web visit https://groups.google.com/d/msgid/mintpy/ce134d4e-9721-4a15-ae55-d6ea9f6c2b4dn%40googlegroups.com.

[Eric Fielding]

Hi Alejandra,

The height-correlation method for tropospheric delay estimation may not work well for this case because you have loss of coherence at the higher elevations and also the topography away from the volcano is much lower than the volcano. The height correlation method may find some correlation with height that is not due to the troposphere but is actually a surface displacement signal beneath the volcano. You should not use both the height correlation tropospheric estimation and the topographic residual correction at the same time, as they might combine in strange ways.

All the best,

    ++Eric

[Zhang Yunjun]

Hi Alejandra,

The height correction method estimates and removes phase (tropo delay or deformation) correlated with the topography, thus, one should be very careful if the deformation signal is also correlated with the topography, which is very common for volcanoes. My student and I are working on a new method to help with this scenario, but it's still a work in progress. Hopefully we will implemented into mintpy in the future. 

ERA5 uses external datasets, thus, no need to worry about the correlation between deformation and topography, thus, I am mostly using that for volcanoes myself, even though the performance is far from ideal. Higher resolution atmospheric models as implemented in Raider (https://github.com/dbekaert/RAiDER) might give a better performance, but it's not integrated with mintpy yet.

In short, the easier path to get a InSAR result with less impact from troposphere could be simply processing a longer time-series, to average the temporally stochastic tropospheric delay, as shown in Fattahi & Amelung (2015, JGR)

Yunjun