Ionosphere in GUNW product

[dbekaert]

Below is the outline of the steps to add Ionosphere to the GUNW product:

What

The dispersive Ionosphere adds a phase advance as apparent signal to the interferogram. This signal is proportional to the frequency squared.

Dependencies

Nothing new. Ionospheric correction is available through ISCE2.

Implementation

• Ionosphere is a timely computational step. This could technically be ran in parallel as the existing GUNW workflow with only ionosphere options enabled and all other options including IFG workflow disabled. The computational cost would be doing data staging, geo2rdr, merging twice.
• Ionospheric correction estimation requires the splitting of the SLC in a low and high band frequency. Both are subsequently unwrapped (as the wavelength prior to unwrapping is not the same). Interferograms are severely multi-looked and filtered to help the unwrapping and estimation. Defaults are shown in the ISCE topsApp xml.

#to the filtering parameters above
<property name="total number of azimuth looks in the ionosphere processing">50</property>
<property name="total number of range looks in the ionosphere processing">200</property>
#the above numbers should be integer multiples of the below numbers
<property name="number of azimuth looks at first stage for ionosphere phase unwrapping">10</property>
<property name="number of range looks at first stage for ionosphere phase unwrapping">40</property>

• The ionospheric geo-coding should be done at approximately the multi-look resolution (compute the effective resolution based on native sensor resolution and above provided multi-look factors). This grid should be an integer multiple grid such it can be stitched across different GUNW products. This means that the topsApp xml file should be updated to a new DEM once the other layers are geo-coded before processing with geo-coding the ionosphere.
• The ionospheric correction estimate should only have data where there is SAR data. It should be masked to the no-data value in those regions outside the SAR data coverage.
• The ionospheric correction is mainly suited for correcting the long-wavelength ionosphere. By masking out the water and doing nearest-neighbor interpolation as filling or by feeling snaphu the masked interferogram the correction can be made more reliable (as to not add additional phase over water). Such feature is not a default implementation in ISCE but all features exist to tread this as a modular library to do so.
• The ARIA website should be updated for the details on the ionospheric processing parameters.
• The ARIA-tools package needs to be updated to support the new variant of storing data at a coarser 2D posting.

[cmarshak]

The ionospheric correction is mainly suited for correcting the long-wavelength ionosphere. By masking out the water and doing nearest-neighbor interpolation as filling or by feeling snaphu the masked interferogram the correction can be made more reliable (as to not add additional phase over water). Such feature is not a default implementation in ISCE but all features exist to tread this as a modular library to do so.

I don't think it will be easy for me to mask the water before ionospheric correction.

https://github.com/isce-framework/isce2/blob/main/applications/topsApp.py#L522-L536

Based on the comment, unclear if you have to run ionosphere on different connected components of the masked image or all at once. Looks like these slices/boxes are specified in radar coordinates of the ISCE2 phase image:

https://github.com/isce-framework/isce2/blob/main/applications/topsApp.py#L522-L536

This would require from what I see:

1. get water mask in geo coordinates
2. reproject exactly into radar coordinates of phase
3. Create series of slices/boxes as specified above (or mask out the data manually using 0s as indicated in the second link)
4. Run correction
5. Reproject ionosphere back into ionosphere

While it's easy to describe, I think there are a lot of challenges/obstacles someone that is not familiar with using ISCE2 as a library (not me) would encounter.

[dbekaert]

You would not be using that parameter to mask areas currently exposed in the config file of topsApp.

The description is overly complex. All the work is done in radar coordinates and ISCE has existing modular components in place for water mask generation that is well maintained and tested. You would just call up to a specific step of topsApp, stop mask and fill the IFGs used in iono estimation, and continue.

[cmarshak]

I agree the bbox description is overly complex. Definitely just mask out water once you have a water extent. I was suggesting this approach because I don't quite know which files ISCE2 uses for the ionosphere correction and such a bbox correction could be in theory directly fed through the xml as noted above. If you were to call the correction from the command line, (would it be runIon?) assuming things would work through topsapp identically, just not sure. I imagine there will be some required reprojection/resampling from geo to radar coordinates that would be required for this to work - getting the water extent in radar coordinates specifically. Would love to learn how to do this with ISCE2 - just am not clear on it / have not done it before. This is one of the ISCE2 work horse routines.

In the previous topsapp PGE, the water mask is applied at the end of the processing chain using the SRTM water mask. This is the piece that is easier to do using topsapp xml files.

For the timeline we have, someone with more familiarity with ISCE2 than myself would be better equipped to handle this. It requires some knowledge of how to call the ionosphere correction modularly and make sure the outputs are correctly placed in the topsapp so it doesn't mess up the subsequent processing.