# Inverse vs. Forward Model

/My meeting with Gareth opened my eyes to mistakes I made with the Hongtu, China earthquake I was attempting to model. Errors happen, but I learned more because of those mistakes.

First off, I had the incorrect crop size. I had put 1200 which is too small. This value has to be divisible of two enough times to have an adequate amount of data. He stated that for earthquakes of magnitude five or six a crop size of 1536 will provide sufficient data.

After I fixed that in the scripts, I had to change the shifts in the rows and columns for the correct cropped image; as a result, I also had to change the x and y coordinate for the start of the crop. He informed me that the crop_data.m was a simpler version of the crop_data_correlation.m script and the latter was all that needed to be used. On top of that the quadtree process begins with the unw.pha_quadtree where the minimum and maximum quadtree threshold can be altered as necessary. Most of the values in the script can be arbitrarily altered to get our desired result (meaning equally spaced points). After saving and running that we get an image that has a bunch of points and if there are clusters of points, then the script needs a different value for the box size or the quadtree thresholds (like I said all of that is arbitrary, and I need to mess with the values). Once we have the boxes for the quadtree, then that info needs to be transferred to the incidence and azimuth scripts. There’s numerous steps to this, and I will gladly elaborate more in a later post.

On another note, not only did I make several mistakes, but I chose an earthquake that has already been the center of discussion and debate. Due to the shape of the earthquake, there are two possibilities on where the thrust fault is. A thrust fault is a low angle reverse fault where the hanging wall is above the foot wall. Essentially, I chose a very interesting earthquake to do my first inverse model on.

I mentioned inverse model, so I will further elaborate on that. This whole process produces an inverse model which uses the data to retrieve parameters such as strike, dip, rake, and slip using okinv. After Gareth ran through the quadtree steps with me, we realized that we couldn’t do an inverse model.

Typing the command okinv3 okinv3.inp in the terminal creates files called param.out resid.out etc.

Once we typed gedit param.out we inputted all the parameters we think are associated with the earthquake and we used information from http://www.globalcmt.org/CMTsearch.html, however, since seismologists can’t pinpoint exactly where the fault plane is there were two options and we chose the first one from these two:

Fault plane: strike=146 dip=43 slip=83

Fault plane: strike=335 dip=47 slip=96

With the param.out script, we inputted the appropriate parameters and bounded them. One of those were the coordinates of the fault which was found using the cropregdata.dat file. In there are the coordinates for the start of the crop. The x and y reference points of the cropped image are then added to the values 1012 times the pixel size and 712 times the pixel size respectively to acquire the coordinates in lat long (ll) which then need to be converted to UTM (Universal Transverse Mercator) using the command ll2utm.

There was one issue though. Unfortunately every time we ran mdx, an unstable inversion resulted. That means that the values were going to extremes like no slip or the magnitude was off (by a lot). In addition, the computer kept wanting to exceed the bounds we inputted.

Gareth suggested that instead of an inverse model we’ll do a forward model. This uses oksar3 oksar3.inp which produces a file similar to param.out. This type of model uses parameters and theory to obtain a pattern from mdx.

Unfortunately, I forgot to take screenshots of the end result and the entire process. When I meet with Gareth again this upcoming Friday, we will still attempt to produce an inverse model of this earthquake, and I won’t forget to take pictures this time!