This past week has been fairly frustrating in the best possible way. While I did post a first iteration tomography model video earlier in the week, I wasn't quite satisfied with the results. When running the inversion code, at least 60% of the events generate the following error: "Error: this station has an out of bounds start point, skipping this station." Now, this error isn't preventing the code from completing, as the stations are just skipped. However, with so many stations being skipped, the results are less than optimal.
The reason this is particularly frustrating is that there doesn't seem to be a predictable pattern for how the error messages are generated. For some events, every station is skipped and the residual value doesn't even calculate. For others, only a few stations skip and the rest read in just fine. There is no evident pattern on why stations are skipping, or why certain events work and others don't. My mentor is also out of the office this week, making it hard for him to help me debug the errors. Hersh, Josh's mentor here at Purdue has helped me dig into the code a little bit, but to no avail. I've gone back into the database of events and searched for patterns related to event distance and event location. Still random. I've spent hours looking in the Fortran code itself to try and find out what is setting the error off, but to no avail. I was able to find the condition that causes it to fail, but can't trace it back to anything related to the input data. It's been a discouraging process as progressing further on more iterations is sort of futile if this error remains prevalent.
I've spent all of today microscopically dissecting the example code, specification files, and data inputs to see where mine differ. It's been quite a laborious process, as there are so many parameters that aren't being used in my model and can simply be ignored. However deciding which ones to ignore isn't always the easiest decision. After engrossing myself in the depths of the specification files, I think I may have found the root of the problem. I'm hesitant to say it will fix anything at this point, but it may be a start. The code starts the progress on a basic 1D earth model, and then uses future models as the bases for additional iterations. When looking at my spec file, I saw that our 1D model was set up for my mentor's previous tomography run in Alaska, thus not meshing well with the new grid for the OIINK model. To fix this, I downloaded 1D travel time tables from IRIS and built a new 1D model file that matched the geometry of the OIINK experiment. I'm now in the process of reconstructing the grid files and travel time files to see if I can fix the inversion errors. I don't ultimately know if this will fix anything, but it seemed like a potentially significant problem to me, as I've learned that the geometry of tomography is extremely important.
Fixing this issue is especially important for me as Josh and I head out into the field after next week. We may potentially have one week after fieldwork to finish up the last bits of our project, but it isn't realistic to bank on that time for significant work, especially considering AGU abstracts are due at the end of that week. It's become quite clear to me how completing something like a fully iterated tomography model is something that isn't done in 10 weeks. Unless you have a perfectly organized data set with first arrivals already picked sitting right in front of you. But lets face it, what is the fun in that?!
You must be logged in to post a comment.