Mangungane, Mozambique 2016 Earthquake

Here’s a quick update for the Hongtu, China earthquake:

Since Gareth and I need to model about twenty earthquakes, we decided to temporarily forget about this earthquake. The forward model we produced was adequate enough, so we decided to move on.

I am currently in the process of modeling an earthquake that occurred near Mangungane, Mozambique in 2016.

Here is what the unwrapped interferogram for that looks like:

I will go through the steps (again) of creating an inverse model to help break down the process (for me and for you).

The first step is to make a directory for this earthquake under the modeling directory.

Which is through the command mkdir (name of earthquake). Within that directory, I make another one for okinv and data within that data directory I make another one for ascending (since this is an ascending swath). Ultimately, here is what the path reads in the terminal:


The next step is to split the phase and amplitude. Through the command:

rmg2mag_phs filt_topophase.unw.geo filt_topophase.amp.geo filt_topophase.phs.geo 4533

The numerical value at the end denotes the column number which can be obtained through the command:

head filt_topophase.unw.geo.vrt

which looks like this in the Linux terminal:

I found the head command to be extremely useful because instead of using gedit to open the whole ASCII text file I can immediately view that information in the terminal. There is also the tail command which allows you to view the bottom lines of the text file which can come in handy.

Here is what the phase layer looks like after the amplitude and phase layers are split. This image is ran using the command mdx -r4  filt_topophase.phs.geo 4533

I circled the white blob which is the earthquake, and the arrow is pointing to the river that is cutting right through it.

In addition, I must also split the correlation file using the command;

rmg2mag_phs topophase.cor.geo /dev/null topophase.cor.geo.r4 4533

I then type,

mdx -r4 topophase.cor.geo.r4 4533

This image then appears (the arrow is pointing to the river):

After that process, I can now start copying those over to the ascending directory I made.

This is done through this command:

~/modeling/mangungane_mozambique_2016/data/ascending cp /data/mangungane_mozambique_2016/swath1/merged/filt_topophase.phs.geo .

The first path is where I am currently, the cp stands for copy, and the last path is where the file is and the . at the end is to copy to where I currently am. I do the same for the filt_topophase.unw.geo.vrt and filt_topophase.unw.geo.xml files. This whole step requires me to copy over scripts into the appropriate directory, and then I edit the scripts according to the earthquake information.

Afterwards, I go into the crop_data.m and crop_data_correlation.m scripts to input all the values required to successfully crop and mask the image. These values include the longitude and latitude which in this case is 33.098333333 and -21.0391666666 respectively. I must also approximate where the start of the crop should be, I then enter the crop size of 1536 (which then becomes the new column number), and I also edit the names of the input and output files (I must ensure that the input files are all in the correct directory). This part involves some trial and error and here is the end result:

Top: Uncropped. Bottom: Cropped

Top: Uncropped. Bottom: Cropped

This end result works well, but when you take a closer look at the image you can see an unwrapping error (Gareth’s very keen eye detected this).

You can see two blobs that I circled and there is an additional error that was too small to circle. He discovered this because when we ran the image using the command, mdx -r4 mangungane_asc_crop_mask_1536.r4 1536, points within the error had values that made no sense together.

I asked Gareth if unwrapping errors were common, and he responded with yes. He also said that fixing those errors is a “dying art” which I found to be interesting.

He noticed the error when we were running the unw.pha_quadtree script on MatLab. As I have mentioned before, running this script initiates the quadtree decomposition process (which is a technique that divides an image into blocks and is the first step for the image compression).  After running that script, this is the resulting image:

The desired result is to have the points (which indicate the center in each block) along the edge of the earthquake. During this part, we ran into a data sampling error due to the combination of the unwrapping error and the river cutting directly through the earthquake.

Fortunately, Gareth was able to resolve the unwrapping error. I had to email him the mangungane_asc_crop_mask_1536.r4 file, and he cut out data in the error that couldn’t be fixed and shifted the bad values to the correct data points in areas that were fixable. He did this on a software called ER Mapper. Then I inputted the fixed file into the unw.pha_quadtree script.

After that, I transferred all the necessary information from that script and inputted it into the los_quadtree.m script. I edit this twice by saving and running it for the incidence and azimuth files. Once this script is ran then these output files on the right side save into the quadtree directory:

apply_qt_boxes.m mangungane_asc_crop_mask_1536_fixed_null.dat
asc_ll.okinv mangungane_asc_crop_mask_1536_fixed_qtc.dat
asc_utm.okinv mangungane_asc_crop_mask_1536_fixed_qtd.mat
azimuth.r4 mangungane_asc_crop_mask_1536_fixed_qti.r4
box_x_out.dat mangungane_asc_crop_mask_1536_fixed_utm.dat
box_y_out.dat pendiffexpcos.m
calc_e.m pendiffexp.m
crop_images.m process_quadtree.m
cvdcalc.m qt_azimuth_crop_1536_qtc.dat
dem_quadtree.m qt_azimuth_crop_1536_qti.r4
detrend.m qt_azimuth_crop_1536_utm.dat
dist_test.m qtgetblk.m
do_quadtree.m qt_incidence_crop_1536_qtc.dat
expcos.m qt_incidence_crop_1536_qti.r4
flatten_ff.m qt_incidence_crop_1536_utm.dat
incidence.r4 unw_pha_quadtree.m
load_dem.m unw_pha_quadtree.m~
los_quadtree.m utm.xy

All the files ending in .m were originally copied over scripts (that Gareth typed up when he first showed me the process).

However, the asc_utm.okinv file is made when I type commands into the terminal that I obtain from the make_okinv_file.txt. I input the correct files in the command, change the origin of the local coordinate system values that are obtained from asc_utm.okinv, and I must enter the correct UTM zone. That zone is found when I enter the command ll2utm (x reference and y reference points obtained from cropregdata.dat which comes out to be -36 (negative because it’s south).

Now, once I have the okinv3.inp file I can start inputting the appropriate parameters for the earthquake. I provide a rough estimate as to where the fault is, and I go on the website:

I search the date of the earthquake which is 9/22/16 and here is the information that appears:

Fault plane:  strike=339    dip=38   slip=-108
Fault plane:  strike=181    dip=54   slip=-76

We inputted the second line into okinv3.inp file, and when I typed okinv3 okinv3.inp in the terminal then some of the following files are produced: okinv3.inp resid.cpt
boot.out gmt.historyparam.outresid.out
displ.out insar.cpt plot_data_model_residual.gmt5restmp

Afterwards, I type the command gedit param.out and enter the appropriate parameters there as well. Once that was saved one of the last steps was to type

csh plot_data_model_residual.gmt5

And Ta-Da!

Inverse model:

The left is the data, the middle is the model, and the right is the difference which is the misfit of the model to the data. Here the misfit is about three mm which is pretty good.

And there you have the inverse model for the Mangungane, Mozambique earthquake folks.

With that complete, I must continue with modeling about eighteen more earthquakes!