ExaSeis with rupture coupling

Table of Contents

• Code architecture
  • Voxel mesh
  • Solver engine
  • Mesh topology
  • Localisation

Code architecture

We realise the solver as a two-solver scheme:

1. A patch-based voxel field is embedded around the fault. It represents the geometry (through distance fields) and we use this helper mesh to realise all the rupture logic. So the rupture is eventually represented in a Minecraft-like data structure.
2. The actual wave equation sits on top. Its source term uses the voxel field's data.

Voxel mesh

The voxel mesh hosts all fault-related data including all derived quantities. The mesh resembles a degenerated Finite Volume solver, where the solver does not actually evolve a wave equation. Typically, we employ a \( p \), i.e. number of voxels per direction, which is significantly finer than the Finite Volume scheme employed or larger than the polynomial degree of the DG scheme. It yields a subcell representation of the geometry. The following quantities are stored per volume in this helper mesh:

Colour function

1. The fault identificator \( \phi \). By default, this is the sinmod function of the distance to the fault. Every value of \( \phi > 0 \) indicates that this voxel is part of the actual fault geometry, whereas \( \phi=0 \) means that we are far away from the fault and
2. We
3. abc

As the As the point

-overlaps

To compute differences, the

Solver engine

Mesh topology

The mesh is static in this particular case, but it has to be extremely adaptive to resolve the fault accurately.

Todo

Maybe we can model this differently using the FV infrastructure.

Localisation

It makes no sense to hold the voxel mesh globally. For most of the cells, all the \( \phi \) entries would be zero. Therefore, we add a marker function which deactivates the voxel mesh far away from the fault.