Victoria Sentinel-1 ARD product processing failures

[mcgarth]

I am using some of the prototype products generated from Victorian Sentinel-1 tiles in FY18/19. These are being used as an input for the Data61 virtual lab for the time being, until the next round of processing is undertaken.

I started with tile T045D F21. Data is located at: /g/data/dz56/INSAR_ARD/VV/INSAR_ANALYSIS/VICTORIA/S1/GAMMA/T45D_F21/

Here is an example unwrapped interferogram from this tile:

Clearly the processing has failed here, possibly this could be related to the fact that this tile has a lot of sea (~>50%?) and therefore the fine co-registration and/or patch based unwrapping hasn't worked.

QUESTION: what is causing this failure @tfuhrmann @chandra2ga @adeane-ga ?

This highlights the importance of:

• validation (automatic or manual) of ARD products generated by the workflow
• trying to maximise the land coverage of coastal tiles in the new frame definition

[tfuhrmann]

It's only the interferograms generated from scenes before December 2015 which have the problem. Just download the sub-directory ./INT/unw_ifg_pngs and click through the images. All interferograms from 2015-12-02 are fine. That's why I've started the StaMPS processing for this stack from 2015-12-02. Issues with Sentinel-1 scenes observed before 2015-11-27 have also been observed in other data stacks I've processed (e.g. Camden). Other observation: some of the unwrapped interferograms have visible artifacts due to the IFG_PATCHES setting in the .proc file. This is an issue which we had observed at other stacks as well and requires some investigation. A working solution would be to use one patch only and increase the memory for the IFG processing step.

[chandra2ga]

Another possible solution if your area of interest is not over the entire frame then choose only certain number of bursts (<5) covering only your AOI, and then can go for co-registration and interferogram generation. That will work for those images acquired during 2015.

[mcgarth]

@chandra2ga The idea behind the ARD InSAR workflow is to automate this processing as much as possible, and produce reliable results over large areas (not specific AOI's). For that reason, things like number of bursts (in a frame/tile) will be standardised. @sixy6e and @Oceancolour-RG are working on that frame definition right now. @tfuhrmann is there no solution to 'fix' the pre-December 2015 Sentinel-1 images?

[chandra2ga]

@mcgarth you may try two ways to fix the solution for pre-Decemeber 2015 data: 1) Manually work on individual images pre-Dec. 2015 using iterative refine co-registration process. This works for several images excluding few months of data. 2) Not always images pre-Dec 2015 have registration issues, but mostly months from March-May data have co-registration problem. You can discard only those month of images for intereferogram generation by increasing temporal baseline and can proceed considering others.

[sixy6e]

Another test option and verification is process bursts from a single pass/track. It'll create a big file, but should be able to act as a baseline test for the coregistration. Assuming that more land located within the frame will yield a better coregistration.

[sixy6e]

Any idea of the acquisition date that this image came from?

[mcgarth]

This is too old to be worth trying to reproduce and fix