"hole" artifact between adjacent burst

[renierlgv]

I am processing an area just at the intersection between two burst and for some reason there is a "hole" effect for all the estimated parameters, ie, amplitude dispersion (attached), ps pixels, etc. Any idea on how to solve this issue?

[scottstanie]

can you give more detail about how you got here?
my initial guess is that some bursts can shift over time, and occasionally in 2025+ data, there were bad bursts that need to be removed.

[renierlgv]

Hello. Yes. I did a visual inspection on the .png files as the .h5 have all the same size and found that the culprit was a shift in 20250501 (time problem in the state vector???). for such an small project is doable but Im wondering if there is amore robust way to figure our this before starting dolphin as the processing doesnt warn of any issue and it could be days of processing before finding out.
Following up on my previous discussion. Will be possible to add los_ east, north and up to the timeseries folder outputs for the area of interest?

[scottstanie]

ah I almost was able to guess "does this include early may, 2025"?

Im wondering if there is amore robust way to figure our this before starting dolphin as the processing

This is a tough one... on one hand, yes having nice user-friendly warnings that something is wrong is always nice to have. But even for this specific case, it's difficult to know what a "robust automatic exclusion" threshold would look like. We had some discussion with ASF about entirely removing this.
I'm failing to find it now from poor search results, but ESA puts out QA reports where they report "degredation of data products". there is one for May 2025, but it's only "partially degraded", as the amplitude is usable for some cases even if the phase is useless from missing the burst synchronization

[renierlgv]

I did manage to process the ascending orbit data. yet, differently from the descending, the velocity field is have several offsets and clusters (attachment). the offset values are not consistent with unwrapping errors, so, probably some parameter need to be tuned for better results. I an using spurt and default processing paramaters. do you have any suggestion to improve the stability of the estimated velocities ?

[scottstanie]

what was the number of tiles that spurt used? we've found that when there are big gaps in the coherent pixel pattern, the tiling mechanism in spurt often gives artifacts unfortunately. single-tile spurt does work pretty well in most of my testing, but can require a bunch of ram for big areas.

Another option is to try using SNAPHU- the OPERA DISP-S1 settings for unwrapping (using a 32cpu/64 GB machine) are here

[renierlgv]

Thank you. I confirm this approach improved the results. Regarding snaphu, in your experience does mst initialization yields comparable results to mcf?

[scottstanie]

I have found that

• MST can be a bunch quicker for "easy" big interferograms, where the optimization is not challenging and the result takes ~1 minute or less
• but MCF can be a bunch faster for harder interfergrams with decorrelated areas, since MST may start off with a poor initialization for there

I think the final quality is usually very similar, but the runtimes can be very different