Impact of Ionospheric Correction via TEC files

[jonathanbahlmann]

I am trying to gather information about procedure of and possible problems with near-real time processing the NISAR L0 RRSD data up to Level2 GSLC independently of the official processing (viewtopic.php?t=7970). In the thread it came up that for the RSLC -> GSLC processor (https://github.com/isce-framework/isce3/blob/static-layers-wip/python/packages/nisar/workflows/gslc.py) I would need the TEC (total electron content) file of the day of the acquisition date. I've since learned that TEC is about signal interference with the ionosphere, caused by sunlight. What is the magnitude that this effect could have on geolocation accuracy of the GSLC product?

As the TEC files seem to be published per day, they're a bit slow for my NRT case. I would be interested in the consequences of using an older TEC file, say the one from the day before. Would that still represent the atmospheric/sun conditions reasonably well or would I make it worse by applying an unrelated dataset? My area of interest are the Polar latitudes.

[ASF - bhauer]

Hi Jonathan,
I apologize, but since your post wasn't originally tagged with "ASF," I didn't see it until now.

I just want to clarify if your questions have been answered in your later post NISAR Data Latency? If not, I'm hoping someone from the NISAR science team will see this and respond.

Thanks.

[jonathanbahlmann]

Hi Bill, thank you for coming back to this!

My question has not been answered yet. In the thread "Data Latency" Max explained very well the overall procedure, but my questions about TEC remain:

Is the TEC correction important for geometric errors, radiometric errors or both?
What kind of errors do I have to anticipate when using an older TEC file (e.g. from yesterday) because the current one isn't available yet?

[ASF - bhauer]

Hi Jonathan,
Here's what the NISAR team has to say:

...applying TEC files from the previous day is a bad idea since there is certainly variation that occurs day-to-day that would affect the geometric calibration, but I can’t say for certain how much error it introduces to GSLC products, and if it is sufficient for this user’s sea ice monitoring NRT use-case for ship navigation.

One thing to note is that the urgent response GSLC jobs actually run without a TEC map input by skipping ionospheric/tropospheric corrections.
It is probably safer for the user to just manually run GSLC as an UR type that omits the TEC file and accept the reduced geolocation accuracy from those missing corrections, rather than risk unbounded error of using potentially garbage TEC inputs from the previous day.

The user can run the GSLC as a UR by omitting the TEC file input and setting processing_type to “UR” in the runconfig.

And,

It is better if users don’t use TEC at all compared to using TEC from the day before. Unless they have done an extensive analysis and they have a model (e.g, a forecast model) that predicts TEC for them with some accuracy, so that they know what they are doing. We do not have such forecast models!

I hope this answers your question.

[jonathanbahlmann]

Hi Bill,

yes, that helps. Thank you very much for following this.