Ivan Kurz

August 11th, 2014

Today is the first workday of the final week of the internship. From 2 August until now, I have wandered to and fro around Albuquerque, as intern housing ended two weeks before my internship did. This has not prevented me from trekking to the Physics and Astronomy Building to savor the speedy internet and tunnel into the Lithos server, where I run MATLAB and essentially do all my work.

As far as that has gone: it forced me to make the leap in problem solving required for graduate education.

I spent much of the first half of the internship without a clear picture addressed internally or externally to what the project would amount. As Robert Heinlein said, "in the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it." Correspondence revolved around making minute steps in MATLAB coding and awaiting the go-ahead for another step as a consequence of an undergraduate mindset. Around the halfway point, the path which the rest of the summer would follow became more apparent, and while I remain in close touch with my advisor, I am better able to treat the internship as an opportunity to proactively explore my own ways of approaching problems. Nonetheless, I remain in close collaboration with my advisor in abstract composition and poster design, for the project involves a great deal of her efforts as well: a framework in Python to generate the models, pointers on my incipient MATLAB codes, requests for the model specifications, et cetera.

Graduate school is an eventuality. A B.S. in physics and math teaches abstract engineering, and provides the same relative opportunities as a B.A. in English, but even knowing that grad school awaits, I still must reflect on where my desires and abilities converge best.

July 8th, 2014

...That, upon reading that our next post should feature a figure, my first third thought was, "I can use MATLAB to plot this figure!" The result is here.

This graph was supposed to represent work vs. time/results, but what sort of work? Cumulative? If so, the graph would be a fairly standard straight line. I would never expect the work done to decrease. Rather, in order to convey the effort I effect instantaneously, it makes sense to instead plot power over time.

What do the curves mean? The bulk of the effort, as you can see, transpires toward the middle of the project, in cycles roughly representing how often I receive a batch of proposed assignments from my adviser, and how I progress on them. I started from nothing on 1 June, and presumedly will work up until the end on 15 August. The height of the curve represents the proportion of the maximum power I can deliver.

June 30th, 2014

I returned from the workshop last Friday after a couple of days of science talks toward its end and a delayed flight to Los Angeles. On the way into the valley, we had the fortune to spot the San Andreas, a telltale gorge across the mountains.

The following Sunday, yesterday, other IRIS interns in New Mexico, our advisors, New Mexico Tech faculty, and other seismologists met for a barbecue near campus, at the residence of Drs. Bilek and Spinelli. It helped to catch up with fellow interns who I have not seen since orientation and discuss our projects with the faculty present, green chile cheeseburgers aside.

June 23rd, 2014

...As a spectator, but an enchanted air still pervades the whole situation.

Since arriving at Stanford, I have juggled both my coding exercises and the CIG workshop in an increasingly independent manner, even though I maintain close contact with Dr. Roy in my progress, and the week is much less of a wbusiness trip than an opportunity to take a break and view the machinations of academic computational geodynamics. In the process thus far, by osmosis, I have absorbed a tremendous deal of knowledge in CUBIT/Trelis mesh generation and finite-element modeling of faulting: volcano deformation, normal faults in subduction zones, transform faults...

Now, as the programming pace picks up, and I face a brand-new living situation for several days hours from anywhere I have ever been, I am occupied at nearly all hours. But I enjoy such work, and the bursts of spontaneous action required to oil the wheels of the workshop experience.

June 20th, 2014

Lately, I have delved into the introductory aspects of the internship: adjusting previous Python code using FEniCS to compute the velocities of rock at given points inside a theoretical mesh. This mesh emulates a right strike-slip fault with mantle flow beneath; by setting boundary conditions accordingly, we can then model the rheology of a simple chunk of crust.

From the beginning, it was clear that changing the number of iterations of modeling did not affect the velocities themselves. I managed to vary the mesh's parameters--viscosity distribution, thickness, absolute velocities of the boundaries--and establish just how these parameters affected the output. In addition, I varied the viscosity values of the layers in the model. Here is a random example of a ParaView snapshot visualizing the velocity distribution in a two-layered rheology of double the strike-slip velocity relative to the mantle's velocity, comparing a mesh of 100 km thickness to 400 km thickness.

My greatest trouble toward the latter half of this week was in calculating the plane of zero velocity magnitude, where we do not expect motion of the crust, and the velocity tensor. Conceptually, both are simple to address, but the task of converting a .vtu (visual file) into an ASCII file for MATLAB use has worn thin. A slight adjustment to the old Perl code produced a file of irregular dimensions; importing the file in turn produced bugs. Based on today's meeting, the optimal route may be to convert the .vtu file to a spreadsheet within MATLAB before proceeding.

The coming week will take me to Stanford for the Computational Infrastructure for Geodynamics PyLith workshop, and I am nothing less than thrilled to have the chance to be there. The subject matter covers geodynamic modeling as well, so the ideas addressed there, while not directly relevant to the assignments at hand, should be close enough to prove useful. More on this in several days.

June 9th, 2014

I concluded that my aging laptop would not remotely suffice for my internship, purchased a brand-new one, and through a coup d'etat, replaced Windows 8 with Ubuntu. Diving head-first into UNIX has been like ripping off a bandage: painful in the short term, but a relief in the long term. Furthermore, in my quest to find the perfect hardware last weekend, I wound up walking around Albuquerque in a continuous eighteen-hour trek. But what an adventure!

As soon as I'm able to tunnel into the physics department's computer and solve "some" configuration issues, progress should arrive. Because I model, no data or instruments are required; I rely on FEniCS and ParaView to solve differential equations by finite-element methods and plot the evolution of a theoretical geodynamic system. These software packages are universal among the theorists, particularly at Brown and Columbia. Other students and I also toy around with GMT, for example, in group meetings, and a seminar later this month involves extensive PyLith usage.

One more point on my last blog entry: in order to study seismic anisotropy, we often use SKS phase waves reflected off the core-mantle boundary. How come? At the boundary, compressional waves convert into shear waves. We know the initial polarization of these waves, so given the final polarization of the split shear wave, we can speculate on the anisotropy of the material through which the wave passed.

June 6th, 2014

I suppose I should verify the understanding of anisotropy I gleaned over the first week for you ladies and gentlemen.

The basics: often, we idealize a fluid as isotropic, meaning that it has the same properties in all directions. It follows that within each broad category of seismic wave, p-waves and s-waves (compressional, longitudinal waves which have amplitudes along a stress, and shear, transverse waves which have amplitudes orthogonal to a stress), waves travel at the same speed no matter their directions.

However, many earth materials, such as olivine, don't exhibit this. They have orientations which propagate waves faster or slower due to the "stiffness" along their directions, computed by the bulk and shear moduli. For an analogy, imagine how fast a taut Slinkie carries a compression verses a loose one, how quickly a tense rope carries a disturbance, or how the speed of sound is greater in brass than air. Often, the spacing in the medium's structure is lesser in the fast directions and greater in the slow directions. (Generally, waves travel faster under greater pressure, but that's a finer point I won't elaborate upon here for the sake of simplicity.) The equations say so, and you can't lie using Greek letters. (Believe me, I've tried.)

What are some geological processes that can cause anisotrophy? In the crust, metamorphic foliation is sometimes at fault--when stresses cause materials in a rock to line up along a direction, so the rock doesn't have equant properties in that direction. In addition, microcracks in sedimentary rocks slow waves attempting to cross this spacing. In the upper mantle, where the mineral olivine is prevalent, the molecular structure of olivine facilitates the transmission of stress similarly.

How do we measure it seismically? When an s-wave enters an anisotropic medium, it splits into two perpendicular polarizations dependent on the medium's anisotropy. One polarization, "stiffer" than the other, races ahead. You can then note the polarizations of incoming s-waves and their spacings in time to estimate the anisotropic orientation(s) and thickness of the medium. Hence, we specifically examine the properties of incoming s-waves.

That should do the subject justice for now. I'll return to preparation for a brief presentation later today.

June 5th, 2014

A typical introduction to any programming language will start with one of the more basic functions: printing a simple phrase. Ubiquitously, this phrase is "hello, world!" Whether in C++, FORTRAN, or Python, this hardly ever fails. I figure that there's no better way to begin this blog.

How come? For starters, my project--originally titled "Melt migration and distribution at the lithosphere-asthenosphere boundary and its implications for seismic observations," but altered to "Models of seismic anisotropy around the San Andreas Fault, California" after discussion with my adviser, Dr. Mousumi Roy--involves plenty of coding, and for good reason. My overarching plan for this project is, via Python coding, FEniCS software for partial differential equation solutions, and D-Rex calculations of seismic anisotropy, to construct various models of lithospheric and asthenospheric rheologies in the San Andreas Fault region and their effects on anisotropic orientations of dry olivine-enstatite aggregates in the upper mantle.  We observe a stark contrast between northern California and southern California: in northern California, east-west anisotropy dominates far from the transform boundary, and fault-parallel anisotropy dominates in its neighborhood. Meanwhile, in southern California, east-west anisotropy dominates to a greater extent; fault-parallel anisotropy lies only in the immediate vicinity of the fault. Tetreault, Roy, and Gaherty have previously suggested that the former is due to strong lithosphere-asthenosphere coupling, and the latter, weak coupling. They drew their conclusions from variations of viscosities of two layers, emulating the higher-viscosity lithosphere and lower-viscosity asthenosphere, over different time frames. In particular, two-layered viscosity emulates northern data, and isoviscosity emulates southern data. I'm here to verify these observations!

Much of this is new to me, and fairly technical. Faced with the task of eating a whole elephant, I'll adopt the strategy incorporated many times before: taking the whole elephant bit by bit, not all at once, in stafes I can measure. IRIS's suggestion of taking the summer in thirds sounds feasible enough. So, here goes:

-The first third (about 1 June to 27 June): install all required software (Gedit, D-Rex, etc.) on my computer; learn Python and FEniCS from tutorials and code written by previous students under Dr. Roy; author my own code to reproduce growth time of a disturbance as a function of wave number for the Rayleigh-Taylor instability, shown in 6-12 of Turcotte and Schubert's Geodynamics; attend the PyLith workshop at Stanford University from 23 to 27 June.

-The second third (about 28 June to 19 July): complete the first step of the modeling process, accounting for strike-slip plate motion and asthenospheric flow, in both a two-layered scenario with differing lithospheric and asthenospheric viscosities and an isoviscous scenario.

-The third² (about 20 July to 15 August): apply D-Rex's calculations of seismic anistropic orientation to my models; submit my abstract for AGU (due 6 August); describe the implications of my models in full.

Hopefully, I'll be able to progress past the material I'll attempt to verify and embark into more advanced territory by imposing new constraints on my models.

In the meantime, I'm jumping through various hoops in the UNM bureaucracy so I may gain access to the physics building and internet in the first place. If I vanish, then I've been defeated. Stay tuned, folks.