aria-tools / ARIA-tools

Tools for exploiting ARIA standard products
Apache License 2.0
99 stars 36 forks source link

[BUG] #416

Closed EJFielding closed 6 months ago

EJFielding commented 6 months ago

Describe the bug ariaTSsetup.py does not correctly stitch frames for GUNW v3_0_1 datasets over Los Angeles.

To Reproduce Steps to reproduce the behavior:

  1. Download
  2. ariaDownload.py --num_threads 16 -b '33.4 34.5 -119.0 -117.4' -s 20190101 -e 20211231 -t 64 --version 3_0_1
  3. Command used
  4. ariaTSsetup.py -f "/scratch/nisar-st-calval-solidearth/ARIA_S1/Secular/LA_A64_3years/fielding/20240515/v1/products/*.nc" -b '33.6 34.3 -118.5 -117.5' --mask Download --croptounion --verbose
  5. Error Output
    2024-05-17 19:32:21,555 - ARIAtools.product - WARNING - 81 out of 663 interferograms rejected since stitched interferogram would have gaps
    2024-05-17 19:32:52,875 - ARIAtools.util.dem - WARNING - Cannot proceed with VRT format, using ENVI format instead
    Downloading glo_90 tiles: 100%|██████████| 26/26 [00:48<00:00,  1.85s/it]
    Reading tile metadata: 100%|██████████| 1/1 [00:00<00:00, 2065.14it/s]
    Reading tile imagery: 100%|██████████| 1/1 [00:04<00:00,  4.09s/it]
    /home/jovyan/.local/envs/solid_earth_atbd/lib/python3.11/site-packages/ARIAtools/util/stitch.py:394: RuntimeWarning: Mean of empty slice
    comb_data = np.nanmean(comb_data, axis=0)
    2024-05-17 21:45:40,873 - ARIAtools.util.vrt - WARNING - Extraction of raider-derived troposphere layers is not possible as specified tropo model name(s) "-tm None" is not valid.

The run completed without further errors and I loaded it into MintPy, but many of the interferograms have incomplete stitching. Output from MintPy with views of the interferograms are attached below. unwrapPhase_wrap_1 unwrapPhase_wrap_2 unwrapPhase_wrap_3 unwrapPhase_wrap_4

Expected behavior I expected complete interferograms.

Desktop (please complete the following information):

Additional context

This was running on the NISAR On-Demand System.

sssangha commented 6 months ago

@EJFielding , I took a look at your case example and this appears to be the expected behavior since there are a mix of short scenes here (i.e. IFGs with just a single frame available, which only partially overlaps with the specified AOI), e.g. 20190210_20190123 below: Screenshot 2024-05-20 at 7 57 01 PM

To kick out such scenes, you would need to omit the -croptounion option to strictly enforce a cutline from the provided AOI (i.e. clip scene extends that span beyond this footprint) and leverage the minimum overlap option (-mo) to kick out scenes that have below X km^2 of overlap WRT to the specified AOI.

For the latter, please refer to the help print screen (i.e. ariaTSsetup.py -h) for a detailed description of its purpose. Generally I specify a value that represents ~90% of the area in km^2 of the AOI of interest, which in this case I manually estimated from QGIS to be 5800 km^2 (i.e. -mo 5800). By specifying this as an argument, I am able to kick out "short" scenes such as 20190210_20190123 above, and only pass scenes such as 20190123_20190117 that span the AOI:

Screenshot 2024-05-20 at 8 02 36 PM

Please let me know if you'd like me to clarify anything here. Thanks!

EJFielding commented 6 months ago

@sssangha Thanks for investigating. It seems that the new v3_0_1 processing must have a lot more missing scenes than the older v2 processing. I will use the -mo option then. My AOI seems to mostly fit in one frame, but then catches the edges of the frame above and below, so I get all those little pieces of interferograms.

EJFielding commented 6 months ago

I verified that running ariaTSsetup.py with the -mo 5800 flag creates a set of interferograms that is complete, but a much smaller number. I am closing this as not a bug in ARIA-tools but what I hope is a temporary set of missing frames in the ARIA S1 GUNW archive.