plate_motion.py, [azimuthAngle] not found in file geometry geometryRadar.h5

[Carolina Hurtado]

Hello all,

I processed a couple of time series, one in ascending mode (~200 images), and another in descending mode (~20 images). I found that in a few areas the behaviour is opposite (i.e., up in the LOS direction of ascending and down in descending).
I believe that it can be caused by horizontal motion not accounted in the processing that shows that the ground is getting close to the satellite in one mode and therefore, far in the other mode.. I applied ionospheric corrections, and all the main ones in both cases. So, if it is horizontal motion, I think it can relate to rigid plate motion, as the GNSS stations in the area in a global frame show ~12 mm/y of motion to the west and ~0.5 mm/y in the east component with the plate fixed. However, the study area is 100km x 90 km, I think this may be a relative small area but still.

I wanted to understand a little more, and have a visual aid, so I was trying to use the plate_motion.py script (plate_motion.py -geometryRadar.h5 --plate NorthAmerica). But, it throws the error [azimuthAngle] not found in file geometry geometryRadar.h5

The file geometryRadar.h5 exist and I running the script from the inputs folder. I also tried with geo_geometryRadar.h5 and got the same error.

I am attaching an screenshot of the error lines:

Thanks for any help anyone can provide me!

[Yuan-Kai Liu]

Hello Carolina,

I see InSAR plate motion keywords that draw my eyes, ha. Hopefully it is not a bug in our code there. It looks like the azimuthAngle dataset is not found in the geometry file.

Could you help me to do a quick info.py check on your geometry file? You can check your both files:

info.py geometryRadar.h5 | grep HDF5

info.py geo_geometryRadar.h5 | grep HDF5

The azimuthAngle and incidenceAngle are both required to compute the line-of-sight projection of the rigid plate motion model prediction. Usually they are read in prep_data step. From your default .cfg file, there should be entries like below to read those into the geometry.h5 file:

##---------geometry:
mintpy.load.demFile         = ../hpc_topsStack/geom_reference/hgt.rdr  #[path of DEM file]
mintpy.load.lookupYFile     = ../hpc_topsStack/geom_reference/lat.rdr  #[path of latitude /row   /y coordinate file], not required for geocoded data
mintpy.load.lookupXFile     = ../hpc_topsStack/geom_reference/lon.rdr  #[path of longitude/column/x coordinate file], not required for geocoded data
mintpy.load.incAngleFile    = ../hpc_topsStack/geom_reference/los.rdr  #[path of incidence angle file], optional but recommended
mintpy.load.azAngleFile     = ../hpc_topsStack/geom_reference/los.rdr  #[path of azimuth   angle file], optional
mintpy.load.shadowMaskFile  = ../hpc_topsStack/geom_reference/shadowMask.rdr  #[path of shadow mask file], optional but recommended
mintpy.load.waterMaskFile   = ../hpc_topsStack/geom_reference/waterBody.rdr  #[path of water  mask file], optional but recommended
mintpy.load.bperpFile       = auto  #[path pattern of 2D perpendicular baseline file], optional

best,

--Kai

[Carolina Hurtado]

Hi Kai,

Sorry for my late response, I didn't see the notification.

Here are the results of info.py geometryRadar.h5 | grep HDF5. For  geo_geometryRadar.h5 the results are the same.

The azimuth file is not listed as you suggested. I looked my configuration file and I let the azimut file as auto (mintpy.load.azAngleFile     = auto), so it is not calling it, right? 

I imagine there is not an easy way to correct this, so I will modify the cfg file and create again the time series. If I find any error I will be back :D 

Thanks for your help! 

Carolina

 .  

[Ditasaka]

Hi Kai and Carolina,

According to my poor knowledge, the incidence and azimuth angle for each image can vary. Thus, how can it be defined?

[Yuan-Kai Liu]

Hey Caroline,

Correct, if let it be 'auto' without giving the path, then it will be ignored. You have your incidence angle defined there. Nice. You just need to add the path to the cfg and re-run the load_data.py script. 

Check this: load_data.py -h

  # load geometry ONLY
  smallbaselineApp.py SaltonSeaSenDT173.txt -g 
  load_data.py -t smallbaselineApp.cfg -l geom

The first line will update smallbaselineApp.cfg based on your own prject cfg, in this case, the SaltonSea..blabla file.

The second line will use that updated smallbaselineApp.cfg to load just hte geometry file (so it re-load everything including your azimuth angle into your geometryRadar.h5)

[Yuan-Kai Liu]

Hi Ditasaka,

Because that is an approximation. We use the geometry (incidence and azimuth) of the reference image to represent all secondary images.

Whenever we do the interferogram(s), the phase is only meaningful when computed from a pair of co-registered images relative to the reference image. After coregistration, the entire stack of SLCs lives in the reference's coordinate system. Therefore, the geometric parameters (latitude, longitude, height, incidence angle, azimuth angle) for each pixel are defined solely by the master image's geometry.

The assumption is that the entire displacement time series (or a stack of interferograms) can be accurately referenced to the line-of-sight direction defined by the single reference acquisition.
For the purpose of calculating displacement from phase, the error introduced by using the reference's LOS instead of all the different images' LOS is negligible for most applications.

[Carolina Hurtado]

Thanks for your help Kai!

It worked perfectly. I just want to confirm a few doubst before continue. The script creates two files: ITRF14.h5 and ITRF14enu.h5: I used info.py to know what they are, the first one is velocity and the second one has three layers (east, norht, and up).

1. Are the units mm/y and mm respectively?

2. Are the velocities and the motions estimated only for the period of the images? I mean, if my first image was acquired in September 2015, and the last one on March 2025, the rate and motion is only for that period?

3. Is the velocity in the LOS direction?

Also thank you for teaching me how to modify only parts of the process I run all the steps again!

[Dita Faith]

Hi Kai,

Thank you for the explanation.
That makes sense now, especially regarding the use of the reference image geometry for all secondary images and why the error is negligible in most applications. 

--
You received this message because you are subscribed to the Google Groups "MintPy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mintpy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mintpy/0afd5bea-0050-40ce-a1ea-944f0d29b557n%40googlegroups.com.

[Yuan-Kai Liu]

1. meter/year. You can use `info.py ITRF14.h5 | grep UNIT`. 
I would expect all the default timeseries and velocity files in MintPy are "meter", rather than cm or mm.

3. ITRF14enu.h5 is velocity in east/north/up. ITRF14.h5 simply project east/north/up to LOS. Both are meter/yr for sure.

2. It doesn't care about your time period. It is a prediction based on the Euler pole (a very simple model of only 3 parameters) derived from contemporary GNSS velocities over 11 plates on Earth that are constrained "okay". We assume the plate is rigid (no internal strain; not a good approximation when applying this to wide deformation zone), and assuming a constant angular velocity of the plate over any time frame (which is a good approximation).

Reference:

https://web.gps.caltech.edu/~simons/publications/pdfs/2022-Stephenson.pdf

more stuff:

https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2025GL115137