GUNW layer stitching feedback and recommendations

[dbekaert]

Hi,

We have been testing the frame stitching for the GUNW products. Below we capture the discussion and issues that we would like to raise and request for additional sample data.

Layers

Troposhere:

We confirm products can be stitched (we tested based on same UTM projection along track and for same model correction UTC epic). Though we observed artifacts (see screenshot under details) for stitching:

Recommendations:

• NISAR GUNW is rounding to nearest model UTC epoch (00/06/12/18 etc) or center frame time. This will introduce tropospheric stitching artifacts at such transitions. We have done studies on ARIA S1-GUNWs that show frame boundary artifacts for stitching troposphere unless a time-varying azimuth grid is used for linear interpolation of the model (study provided offline).

  We recommend use of a time-varying azimuth grid for troposphere

  An Example on how this is implemented for the ARIA GUNW in combination with the RAiDER package and ISCE3 can be seen at the GUNW entry point for RAiDER (see command below) which is calling ISCE3 for making azimuth varying grid here. raider.py ++process calcDelaysGUNW -m HRES -f S1-GUNW-A-R-137-tops-20211219_20211207-020132-00124W_00046N-PP-41ba-v3_0_0.nc

  • Currently troposphere is provided as differential correction in the product. There might be scenario's where: (1) tropospheric ancillaries arrive late and products are processed/delivered to the DAAC without the ancillary included. (2) users mixing urgent response products with regular standard products were ancillaries might missing. Both cases introduce errors in time-series when the corrections are applied on the epic level when only interferometic delays are provided. We have done studies on ARIA S1-GUNWs in MintPY that show artifacts smearing in time (study provided offline).

    We recommend inclusion of the tropospheric delays for reference and secondary instead of interferometric delays only

    Anticipated product size growth is expected to be very small given 3D data-cube compression of how tropopshere is stored. Examples of this are the ARIA V3 GUNW, provided offline to ADT.

Solid Earth Tide:

Similar as tropopshere, Solid Earth tides layer will have artifacts unless a time-varying grid is utilized (study on ARIA GUNW provided offline). We observed artifacts in provided sample data (see screenshot under details):

Recommendations:

• PySolid does not currently have that support (see issue ticket on Pysolid here). An Example on how this is implemented for the ARIA GUNW in combination with Pysolid package and ISCE2 can be found here and in a notebook here. In short Pysolid is wrapped multiple times.

  We recommend use of a time-varying azimuth grid for solid earth files

Ionosphere:

Still investigating our different stitching flavors (we tested based on same UTM projection along track).

Other layers and evaluations:

## coherence, amplitude: All fine to be stitched ## Unwrapped phase: We confirm products can be stitched without artifacts (we tested based on same UTM projection along track). Per offline discussion only 2 pi phase jumps are to be accounted for NISAR GUNW. ARIA S1 GUNW also have an additional range correction due to data driven correction varying by frame (does not apply to NISAR GUNW).

Requesting specific sample data for testing:

• [ ] 2 products along track where UTM will change. Alike the DISP frame definitions for OPERA. We could also trigger our S1 pipeline on ARIA (assumed WGS84) to compare them with ADT generated products(with varying UTM)
• [ ] 2 products along track for an example with water bodies to test stitching and propagation of connected components in stitching for unwrapped phase and ionopshere

[xhuang-jpl]

Thank you @dbekaert. For the testing, did you use the GUNW products I shared before? if yes, for the troposphere, when you created the dataset, did you use the DEM for the interpolation?

[sssangha]

Hello @xhuang-jpl , yes we have. We used have used the routine outlined in the Metadata Cube Interpolation Example section of the NASA SDS Product Specification document, for which we have also successfully demonstrated for existing ARIA-S1 GUNW products.

Also, we observe this artifact in the tropo layer at the cube level between consistent height levels before cube intersection with the DEM.

[dbekaert]

@xhuang-jpl yes, we used the provided sample data. As @sssangha indicated, the tropo data cubes should not have any discontinuities at the cube level itself as they use the same models and in overlap the timing of a pixel in either frame is the same. Happy to discuss in a short meeting if you have additional questions.

Comparing this after intersection in part masks the problem. Our intersection codes have been used for many years on the S1-GUNW products which are prototypes for NISAR. It has been tested and compared against 2D estimates for baselines, incidence angles etc versus 3D with cube intersection. The approach used is much in line with the suggested approach in the product specification.

[xhuang-jpl]

Thank you @dbekaert and @sssangha, the troposphere delay in the GUNW product I shared was from the pyAPS not RAiDER where pyAPS has the interpolation not taking accounting of the time, so it has the small artifacts of the troposphere among the consecutive frames. NISAR uses the RAiDER, we tested and did not see the inconsistencies anymore as shown below,

For the solid earth tides phase, we have taken into account of the time for the interpolation, and after the fix, I did not see the inconsistencies if the consecutive frames are in the same UTM zone, but we did see some small artifacts (about 0.01 mm) if the consecutive frames are in different UTM zones. Please see them below,

1. Solid earth tides phase stitching with the same UTM zone:

2. Solid earth tides phase stitching with different UTM zone:

[dbekaert]

@xhuang-jpl just residuals look very good.

Just to make sure i fully understand when you refer to "interpolation", could you describe in more detail the step from input to output? This would be handled outside the RAiDER/pysolid like codes. I bolted the implementation i think you might be referring too:

For example which of the following Tropo workflows is representative?

• two/three weather model epics (e.g. 00/06/12/18) and then there is a linear interpolation based on the azimuth grid of sat UTC time?
• two/three weather model epics (e.g. 00/06/12/18) and then there is a linear interpolation based on center frame UTC time?
• nearest weather model epic (e.g. 00/06/12/18) to the UTC time?

For solid earth tides which is more representative?

• SET tide for central frame UTC time?
• SET tide for varying azimuth grid of sat UTC time?

[xhuang-jpl]

Thank you @dbekaert,

1. Troposphere

1.1 Sorry for the confusion of troposphere interpolation. For the troposphere interpolation, I mean that the pyAPS package introduces very small residuals (around 0.01mm) even when the consecutive frames uses the same weather model, which may be because of the UTM and lat/lon conversion since pyAPS only accepts the lat/lon grid. However, RAiDER does not have this issue.

1.2 We did not do any extra interpolation outside of the package (RAiDER and pyPAS) for now because NISAR uses the HRES weather model data (every 6 hours), and for consecutive frames one the same NISAR track, the same HRES data will be applied. Therefore, the nearest weather model epic (e.g. 00/06/12/18) to the UTC time is the one we currently use now.

2. Solid Earth tides The second is our current implementation (i.e., SET tide for varying azimuth grid of sat UTC time)

[sssangha]

@xhuang-jpl , to clarify is the nearest weather model epoch is informed by the center UTC time of a given frame?

[dbekaert]

Hi @xhuang-jpl @hfattahi,

I think that rounding the tropo to the nearest UTC epic will lead to discontinuous tropospheric correction for frames that span +-3hour transition from the UTC model time. Please see the below two graphics illustrations, though that is assuming the equator crossing case, where this occurs for Sentinel-1 as well as NISAR. The local time might be 6am/pm at equator but the weather model UTC time various in longitudinal bands for that time, and the orbit cycle of 90 min passes all these bands. Anyhow wondering if you could check if i made incorrect assumption with the sketch.

1) Example for Sentinel-1 showing that there are frames for which one frame round to one UTC model epic and the other frame to another.

2) Schematic for the problem in context of NISAR. UTC zones where the center represents the 00, 06, 12, 18 epic; and a ground track where the local time at equator is 6am/6pm and you can see that an orbit cycle even though 90 min long or so would pass differnt UTC zones of the model.

Summary: Limiting to nearest model epic will lead to discontinuity at selective locations (not everywhere) Recommendation: linear interpolation based on time-varying azimuth grid to before-after model epic should remove the issues.

Tagging @scottstanie for OPERA relevance

[dbekaert]

@hfattahi @xhuang-jpl excellent for the solid earth tides.

I also had a brief check on the latest products from the NISAR website. Was wondering in case there is any feedback/plan on the recommendation for inclusion of both the reference and secondary tropo and solid earth tides.

[hfattahi]

@hfattahi @xhuang-jpl excellent for the solid earth tides.

I also had a brief check on the latest products from the NISAR website. Was wondering in case there is any feedback/plan on the recommendation for inclusion of both the reference and secondary tropo and solid earth tides.

@dbekaert If I understand correctly, the concern is that a disconnected network of interferograms might lead to biased estimates when inverting for differential tropospheric delay or solid earth tide, which could distort the time-series of those delays. While that's true, the bigger issue is that the interferometric data itself would be affected in such cases. Providing delays for dates in a differential product (InSAR product) won't solve this problem. Instead, it would require users to perform two interpolations and a subtraction to create the differential delay, which adds unnecessary complexity. In my opinion, the best solution is to ensure that users work with a connected network of interferograms when performing time-series analysis.

[hfattahi]

Hi @xhuang-jpl @hfattahi,

I think that rounding the tropo to the nearest UTC epic will lead to discontinuous tropospheric correction for frames that span +-3hour transition from the UTC model time. Please see the below two graphics illustrations, though that is assuming the equator crossing case, where this occurs for Sentinel-1 as well as NISAR. The local time might be 6am/pm at equator but the weather model UTC time various in longitudinal bands for that time, and the orbit cycle of 90 min passes all these bands. Anyhow wondering if you could check if i made incorrect assumption with the sketch.

1. Example for Sentinel-1 showing that there are frames for which one frame round to one UTC model epic and the other frame to another.

2. Schematic for the problem in context of NISAR. UTC zones where the center represents the 00, 06, 12, 18 epic; and a ground track where the local time at equator is 6am/6pm and you can see that an orbit cycle even though 90 min long or so would pass differnt UTC zones of the model.

Summary: Limiting to nearest model epic will lead to discontinuity at selective locations (not everywhere) Recommendation: linear interpolation based on time-varying azimuth grid to before-after model epic should remove the issues.

Tagging @scottstanie for OPERA relevance

@dbekaert Thanks for the comment. I wouldn't call this an issue with the product, but rather a limitation in the sampling of the weather models. The real question is how significant this issue might be for NISAR and what can be done to mitigate it.

To address the first part, here's a plot showing the Weather model UTC times nearest to the NISAR acquisition times from an Ascending orbit:

This plot demonstrates that the issue is minimal, affecting only a few frames where the transition from one weather model UTC to the next occurs. Given that this transition impacts just 5 frames out of over 7000+ frames over land, I don't see this as a significant issue that would prevent meeting any science requirements.

As for potential solutions, the options would be: 1) producing a NISAR-specific weather model at the exact NISAR acquisition time or 2) interpolating the weather model to match the exact NISAR acquisition time. The first option isn't practical with the current resources, though it could be an interesting research topic for relevant agencies to explore. However, there's currently no strong evidence or literature supporting the interpolation of such coarsely sampled weather models to the second level of SAR acquisitions. For those 5 frames of transition over a global scale, end users can always come up with post processing strategies at higher level processing. This way we won't risk affecting tropospheric delay estimates for the other 7000+ frames.

Thank you again for your feedback. With this response, I’ll go ahead and close the issue. Please feel free to open a discussion if you'd like to explore this topic further.