More general initial condition plugin from seimic tomography

[jdannberg]

Create an initial condition plugin that reads in common format(s) of seismic tomographic models.

[jaustermann]

I think @pmbremner is thinking about this as well. I guess the question is: what is the common format of seismic tomographic models?

[pmbremner]

I'm actually back from all my travels now, and starting work on this again. What I'm doing so far is making a new plugin based on Ritsema's S40RTS that is more general. The most common formats for seismic velocity models that I've run into (my stuff and from other people) are spherical harmonics, some sort of splines, or ascii grid points in lat/lon or Cartesian. These are just the velocities, though. I don't know the best way to put the relations between velocities and temperature/density into the prm file. Maybe as functions? The same issue comes up for the normalization if using harmonics or splines. Right now these things are hard coded...

[gassmoeller]

I am not sure a function in the input file is a good way to include the velocity - temperature conversion. Often there will be no analytic function, but rather only a list of values for different depths. What about allowing a separate file of the same format we use for the burnman cookbook (essentially with two columns, depth and conversion factor). Then you can reuse the Utilities::AsciiDataLookup class to read and parse the file and prescribe any conversion profile you want.

We should also take a look at how expensive these approaches are. Usually computing a value based on spherical harmonic coefficients is relatively slow (you need all coefficients of a layer to computer each value), while grid based approaches are much faster to read in. I am not opposing having a general spherical harmonic loader plugin, maybe we need both? Or can one or the other be already done by using the existing S40RTS or AsciiData plugins?

[pmbremner]

Having a separate file is an interesting approach. That allows the user to input the seismic model as is and the flexibility to test different conversion factors. I don't know how expensive that would be, but doesn't it only happen once at the beginning? Also, the S40RTS plugin is not very flexible as is, which is the part I'm trying to change about it. But I'd actually be in favor of just a single plugin that reads in seismic velocities, from which you can choose your file format for any input files (velocities, conversion factors, depth interpolations, others(?)). This would be the most general I think. At least this makes sense in my head. Of course I could just be thinking too complicated. Thoughts?

[bangerth]

Would it make sense to separate (i) reading the seismic velocities from files using different conventions, and (ii) specifying how to convert seismic velocities into material properties using different conversion strategies? It seems to me that these two things are separate conceptually, and probably ought to be represented through separate parts of code.

[pmbremner]

I was about to write this: "But they aren't fully independent of each other. The need for a conversion strategy comes from using seismic velocities. To the user they go together." But as I was writing I realized that separating them could open the door to inputting other observables like EM methods (magnetotellurics for example) without much more code. Although I'm not sure that inputting these other data types would be any different than seismic velocities.

[jaustermann]

I think having the option to read in a list [depth, conversion factor] would be a worthwhile addition, I've done something like that for some of my runs (e.g. by following the internal::S40RTS::SphericalHarmonicsLookup format). I agree with Wolfgang that I think about these two things (read in s wave velocity and converting it to density perturbations) as two separate steps.

I think having the option to read in a tomography model from a grid would be great and maybe the most versatile format since there's no standard spherical harmonic format. That would be good for new tomography models and also provide the possibility to read in a grid based spherical harmonic model like S40, which one could generate externally once. That would help to speed up the initialization if one uses the same spherical harmonic model for many different runs.

[pmbremner]

What is the current status of this need? Does the general ascii file read function already meet this purpose?

[bangerth]

Let's close this. The issue seems too general to address. If we find that there is overlap between multiple readers, we can always refactor.