make the internal mesher capable of reading in multiple xyz tomography files

[komatits]

From Avinash Nayak:

Meshing with CUBIT allows one to assign different tomography files with different discretization intervals to different elements of the mesh. Is it possible to use the internal mesher xmeshfem3D in the same way with more than one tomography file ? Any working example will be really helpful.

[komatits]

From Carl Tape @carltape :

My impression is that the internal mesher cannot read in multiple xyz tomography files. As an example, with the external mesher you might choose to use two different xyz models, with each element assigned a -1 or -2, as well as two domains that are uniform-valued, with each element assigned a 1 or 2.

nummaterial_velocity_file 2 -1 tomography elastic cook_shallow_vsmin_1000.xyz 1 2 -2 tomography elastic cook_crust.xyz 1 2 1 3000.0 7800.0 4500.0 9000.0 0 0 2 2 2800.0 6700.0 3870.0 9000.0 0 0

In the internal mesher, I don't think there is option to specify more than one tomography model, nor is there an option to specify to both uniform-valued regions as well as regions that grab values from an external tomo file.

It might be a good goal to have an option in the internal mesher that would be similar to the external mesher. So maybe you would have four domains (1,2,3,4) assigned like this

Mesh_Par_file 1 3370.0 8300.0 4720.0 2479.8 300.0 0 2 2 3320.0 8100.0 4600.0 2443.3 300.0 0 2 3 cook_shallow_vsmin_1000.xyz 0 2 4 cook_crust.xyz 0 2

The first two blocks of elements are uniform-valued, whereas the 3rd and 4th would be assigned values interpolated from xyz tomo files.

I think the code is mostly set up to handle this kind of input, though the changes would require someone who is very familiar with model_tomography.f90.

I just started trying out the internal mesher and am interested to see how its meshes compare with the external-generated meshes (from trelis).

[rmodrak]

Hi Carl and Dimitri,

I agree, the functionality Carl describes would be useful.

I think to some extent, this functionality already exists in SPECFEM3D. If you set MODEL = default in the Par_file and a mix of positive and negative material_id's in the Mesh_Par_file, then you obtain a combination of homogeneous and tomographic elements. Two relevant parts of the source code are here and here.

To fulfill the other part of Carl's request, it would be easy to generalize the existing routines to support multiple tomography files. One could simply change the expected filename to 'tomography_model.xyz_'//str(material_id). This change could be done in a way that affects only the minority of users who choose multiple material domains via MODEL = default, not the majority of users who choose MODEL = tomo, so it would be minimally disruptive.

While as I was saying, code for mixed homogeneous and tomographic elements already exists in SPECFEM3D, unfortunately, it seems this part of the code is now actually broken. I get segmentation faults when I try to use it. And because of how complex and fragile the generate_databases routines are, a robust fix may be difficult.

Short of a fix, I noticed that a comment in src/generate_databases/get_model.f90 appears incorrect. I believe the material_id variable actually corresponds to the the number of the materials entry in the Mesh_Par_file. This threw me off when I was debugging. If others confirm, I could push a correction.

Best wishes, Ryan

[rmodrak]

Because others might benefit from a temporary solution, attached is is an "ugly hack" for what Carl was requesting. You would use it by setting MODEL = tomo in the Par_file and changing the number and names of the hardwired tomography files to suit your needs. (grep for "UGLY HACK" to see changes to the current devel branch). Probably this is not something that should actually be committed. Rather than such a hack, instead we'd want to commit bug fixes for the existing code.

model_tomography.f90

[komatits]

Thanks!

Dimitri.

On 11/5/18 7:38 PM, Ryan Modrak wrote:

Because others might benefit from a temporary solution, attached is is an "ugly hack" for what Carl was requesting. You would use it by setting |MODEL = tomo| in the Par_file changing the number and names of the hardwired tomography files to suit your needs. (grep for "UGLY HACK" to see changes to the current devel branch). Probably this is not something that should actually be committed. Rather than such a hack, instead we'd want to commit bug fixes for the existing code.

model_tomography.f90 https://github.com/geodynamics/specfem3d/files/2550080/model_tomography.txt

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/geodynamics/specfem3d/issues/1306#issuecomment-435985634, or mute the thread https://github.com/notifications/unsubscribe-auth/AFjDKXDRW1Fd81Fwwq-PVMrtj9jq571eks5usIWOgaJpZM4X7M-M.

-- Dimitri Komatitsch, CNRS Research Director (DR CNRS) Laboratory of Mechanics and Acoustics, Marseille, France http://komatitsch.free.fr

[komatits]

Hi Ryan,

Thanks! Regarding src/generate_databases/get_model.f90 I will ask Vadim on Wednesday and we will get back to you.

Thanks, Best wishes, Dimitri.

On 11/5/18 6:56 PM, Ryan Modrak wrote:

Hi Carl and Dimitri,

Short of a fix, I noticed that a comment https://github.com/geodynamics/specfem3d/blob/2e63fffde29ee3d13a861572cc5e0a1178f042b3/src/generate_databases/get_model.F90#L217 in src/generate_databases/get_model.f90 appears incorrect. I believe the material_id variable actually corresponds to the the number of the materials entry in the Mesh_Par_file. This threw my off when I was debugging. If others confirm, I could push a correction.

Best wishes, Ryan

-- Dimitri Komatitsch, CNRS Research Director (DR CNRS) Laboratory of Mechanics and Acoustics, Marseille, France http://komatitsch.free.fr