Atmospheric Correction for InSAR

Dear all,

I know that the significant topographic relief or the steep terrain would cause the stratified atmospheric effect. But could this topography condition be quantified? Such as how steep (related to the slope angle) or how large of the elevation difference would cause the vertical-stratified delay? From previous studies, I found that this kind of delay seems happen in area where the altitude difference is more than 1000 m (Parker et al., 2015; Dong et al., 2019; Kang et al., 2021). And from previous discussion in this topic, in the small volcano area (300 m peak elevation / 4 km2 area) the stratified atmospheric effects are likely to be small to negligible.

But I have applied the PSInSAR technique to monitoring the activities of slow-moving landslides. One of my study area exist obvious seasonal fluctuation in the middle and top of the unstable slope. The topography information are as follow:

image

According to previous studies and discussions, I think my study area wouldn’t be affected by the stratified atmospheric? Is that right?

For better understand the source of seasonal variation, I also tried the linear method in TRAIN to calculate the stratified atmospheric effect. I followed these steps:
1 : stamps(1,6)
2 : aps_linear
3 : stamps(7,7)
4 : stamps(6,6)
5 : setparm(‘subtr_tropo’, ‘y’)
6 : stamps(7,7)

And potting the time series ‘u-dmo’, ‘u-dao’ and ‘a’. I chose two points in this slow-moving landslide to plot the time series. The elevation difference and distance between these two points are about 188 m and 685 m, respectively. Point A is at the top of this slow-moving landslide, while point B is at the bottom of this slow-moving landslide. There seems exist obvious stratified atmospheric effect at point A. But the elevation difference between point A and B is just 188 m and the slope angle less than 20 degree. I’m not sure this kind of topography would cause such stratified atmospheric effect or not ? Unfortunately, I don’t have other continuous monitoring data could check it.

I also found a strange situation when check the time series in another slow-moving landslide area. The atmospheric delay shows seasonal fluctuation, but the time series of ‘u-dmo’ and ‘u-dao’ almost are the same as followed:

I don’t know how it would happen. I export the time series data by following command. Is there anything I did wrong?

ps_plot(‘u-dmo’,-1) % change ‘u-dmo’ to ‘u-dao’ and ‘a’
load(‘ps_plot_u-dmo.mat’,‘ph_disp’)
load(‘ps2.mat’,‘lonlat’)
load(‘parms.mat’,‘lambda’)
ts = -ph_disp * lambda * 1000 / (4 * pi);
ps_ts_u_dmo = [lonlat ts];
dlmwrite(‘ps_u-dmo_ts.txt’,ps_ts_u_dmo,‘precision’,’%7f’)

Could @mdelgado @ABraun @thho @mengdahl @falahfakhri help me or give me some suggestions?

Thank you for reading these long questions.

2 Likes

Dear @sharon,
while plotting u-dmo, it is running good. but while plotting u-dao and a it is giving error. Please give me some suggestion.

Hi @suribabu
Could you show what error you have got? Thank you.

stamps(7,7)

STAMPS: ########################################
STAMPS: ####### StaMPS/MTI Version 4.0b6 #######
STAMPS: ####### Beta version, Jun 2018 #######
STAMPS: ########################################

STAMPS: Will process current directory only

STAMPS: ########################################
STAMPS: ################ Step 7 ################
STAMPS: ########################################
STAMPS: Directory is INSAR_20180426

PS_CALC_SCLA: Starting
PS_CALC_SCLA: Estimating spatially-correlated look angle error…
GETPARM: small_baseline_flag=‘n’
GETPARM: drop_ifg_index=
GETPARM: scla_method=‘L2’
GETPARM: scla_deramp=‘y’
GETPARM: subtr_tropo=‘y’
GETPARM: tropo_method=‘a_l’
GETPARM: scla_drop_index=
K>> ps_plot(‘u-dao’)
Error using ps_plot_tca (line 285)
not a valid APS option

Error in ps_plot (line 1179)
[aps_corr,fig_name_tca] = ps_plot_tca(aps,aps_flag);

K>>

Hi,
I think you need to add the method you used for atmospheric correction.
For example:

ps_plot(‘u-dao’,‘a_linear’)

1 Like

I got this plot,
u_dmo_a_linear.tif (3.5 MB)

Thank you.

1 Like

Why you mentioned 1000, Please explain the above formula.

Hi,
I remember it just the unit conversion from m to mm.

1 Like

My problem is that I cannot find the get_modis.py file inside Train installation folder nor inside the entire linux system, in order to edit the APS_CONFIG.sh directories. I have cloned Train from github but still didn’t find any path named “TRAIN/python_packages/oscar-client-
python/get_modis.py”.


Is there a solution for this ?

There is an obsolete get_modis.py script, but NASA now requires an EOSDIS login to download MODIS data. For ways to download data, see EOSDIS Data Recipes.

Is this what referred to as Master Atmosphere in the tutorials ? which is plotted via (ps_plot(‘m’)

If I understand this correctly, the APS of the master interferogram is calculated accurately while the APS of slaves interfergrams are roughly estimated. Isn’t it? but why ? please could elaborate this slave APS issue or at least mention the research paper where this dilemma was discussed ? I didn’t find information about the term “Master Atmosphere” in [D.P.S. Bekaert et. al, 2015)

I am not sure as I have not used TRAIN for many years, but I see that the script you are trying to use is called “oscar-client-python/get_modis.py”. I suspect that this script was developed to use the JPL OSCAR service that was discontinued about four years ago. The OSCAR service was providing post-processed products for water vapor delay estimates from the standard NASA MODIS products, but it was developed about 10 years ago as a prototype service and it was not maintained after the NASA support for OSCAR ended.

Maybe the TRAIN script is getting the original NASA MODIS products and doing the water vapor delay calculation, using the same calculations that the OSCAR system used to do.

The MODIS Terra data was acquired at about 10:30 AM local time, which was close to the times of Envisat and ERS SAR acquisitions, usually within an hour of the same time. MODIS Terra (10 AM+10 PM) and MODIS Aqua (2 PM+2 AM) are much less useful for Sentinel-1 because Sentinel-1 is in a 6 AM and 6 PM orbit, so the MODIS acquisitions are about 4 hours away from the Sentinel-1 times.

1 Like

Then all my attempts went in vain since displacement velocity map estimation were built upon unwrapped interferograms with calculated troposphere contribution using TRAIN where that obsolete get_modis.py script was called. I have edited the APS_CONFIG.sh accordingly. I don’t know of other methods how to configure TRAIN to utilize up-to-date atmospheric data that is suitable for STAMPS processing of Sentinel 1 time series.

If somebody has a proper configuration for the APS_CONFIG.sh file that contains reliable scripts for PS InSAR Stamps processing of Sentinel-1 database, please send a Screenshot to it.

This is how the velocity map look like "ps_plot (‘vdrop-do’) look like. I see that it’s barely ever changing when dropping an interferogram at a time.

and Those are (‘v’) top figure , (‘v-do’) middle figure and (‘v-dao’) bottom figure after stamps(7,7)



I can see that the removal of tropospheric contribution using the most basic APS linear has changed the LOS relative velocity from large negative values into small positive values especially in the middle of the area near 29.5 to 29.45 lat and 32.2 to 32.35 long. But I am not sure whether the atmospheric correction was effective or did it introduce even more errors

I have not used StaMPS for several years either, but I understand that you used an option to estimate an atmospheric phase screen (APS) that is linearly proportional to elevation. This can work well if you are not looking to measure a geophysical signal that is also correlated with elevation. It looks like the APS linear correction was successful in removing the part of the InSAR phase that was correlated with elevation. You did not mention what kind of signal you are trying to measure, so we can’t advise on whether the APS linear correction might have introduced errors in your measurements.

I appreciate it. Thank you very much for your time.

I am not sure if I understand your question. I am looking forward to measure the small displacements in ground elevation caused by earthquakes which frequently occurred in the middle and eastern middle sections of this area to give clues about the locations of recently formed fractures and/or re-activated faults

I had the same problem too, my mean and absolute LOS velocity results indicates LOS uplift while the study area is tilted fault blocks of normal fault system (subsidence is expected). Maybe the atmospheric phase screen removal is erroneous because I have used TRAIN with oscar-client-python/get_modis.py script and the method used was the aps_linear which assumes constant tropospheric contribution in space and isn’t affected by relief variation . have you figured out a solution yet ?

Alright, I have found that the atmospheric removal using TRAIN’s Linear tropospheric correction was based on an old script. How may I configure APS_CONFIG.sh file to be used for automatically downloading updated estimates for atmopsheric delay. so far I can’t downlaod any data from EOSDIS

[typo corrected for the benefit of text searches] Do you have an EOSDIS login? Have you tried using NASA EarthData Recipes?

All data downloads from the NASA EOSDIS servers require a NASA EarthData login account. You can register for free at this website:

2 Likes