Export velocity model

[sstaehler]

Feature proposal:

• a routine to export the velocity model
• preferably with a direct route to create a TauPyModel object in obspy from it.

Does anyone else think, it's a good idea? Should be pretty straightforward, and I can implement it in the next weeks.

[krischer]

Great idea!

If you want a direct path to ObsPy you have to generate this object here: https://github.com/obspy/obspy/blob/master/obspy/taup/velocity_model.py#L18

Otherwise you could also generate one of the supported text file format and then just use TauPCreate. Might be a bit more generically useful.

A side note: There is actually no proper 1D model handling in ObsPy and that would be very nice to have. So if you want to take the time to cook up something more generic please open an issue on the obspy github to discuss it :)

[martinvandriel]

How would you do it? Assume it's a 1D model? We do not strictly assume this anywhere yet but in principle allow for lateral variations in the AxiSEM run. Hence we also store the model on the mesh and not as a 1D model in the databases.

Of course, the 1D modelname is readily in the file and could be used with the 1D model class from the salvus mesher to do a bunch of stuff (but not yet writing to other file formats).

[sstaehler]

Well, the simplemost solution would be to traverse along the axis, read out the velocities of all points there and create a reasonable parameterisation from it.

I would very much like it to work with arbitrary models, esp. ones that are not the Earth...

Of course, if the user has enabled lateral variations, traversing the axis will not work. I would probably add a flag to the output file whether lateral variation had been switched on and throw an exception then. Another solution would be to use the median of all elements in depth range (d + Deltad), but that's not fool proof either.

[crotwell]

Are the 1D models that were used to generate the mesh for the syngine web service databases at IRIS known and available? Access to the exact 1D model used to generate those would be really useful.

I understand that extracting the 1D model from the 2D mesh would be hard, but if it was originally generated from an existing 1D model, knowing where it came from would be nice, both for computing compatible travel times and for just understanding what the synthetics represent. For example, iasp91 doesn't have a Q model, but I assume the syngine database was generated with attenuation. And ak135f has both a "continental" and "average" variant, and it is not clear which is being used.

[crotwell]

For future reference, it appears that the base 1D models are encoded into the the fortran here:
https://github.com/geodynamics/axisem/blob/master/MESHER/background_models.F90

These look like cubics have been fit to the original model for ak135f, which is different from the form of the original published model.

Also, not clear from the documentation, but appears that the ak135f model is the "average" ak135f with the ocean and sediment layers (top 3.3km) replaced with the crustal parameters giving a 10 km crust. So not the "continental" ak135f variant.

[sstaehler]

Dear Philipp, this is an excellent question. The ideal workflow would be to export the 1D model into the HDF5 database during the AxiSEM run. It is not terribly difficult, but nobody ever took care of it, also because we would need to re-run the IRIS DBs. SCS

[crotwell]

Exporting to the database at run time is a good idea. But could an "export base model" function be added as a standalone executable to AxiSEM? Seems like that would be useful on its own and would make it possible for IRIS to provide this info without regenerating the full database?