sxs-collaboration / spectre

SpECTRE is a code for multi-scale, multi-physics problems in astrophysics and gravitational physics.
https://spectre-code.org
Other
154 stars 187 forks source link

Atlas support #1455

Open wthrowe opened 5 years ago

wthrowe commented 5 years ago

Our current treatment of coordinates is sufficient for our main science goals, but it is not sufficient for a more general set of problems where the domain does not look sufficiently like a subset of R^n. The simplest case of this is an evolution on S^2. The standard way to handle this in mathematics is by defining a manifold using an atlas. We are unlikely to need to satisfy the full requirements of the mathematical concept. In practice, having a different set of inertial coordinates in each block may be sufficient.

Using S^2 as an example, the most obvious problem is the coordinate singularity at the poles. This could be mostly worked around by arranging for there not to be a point at the pole. The bigger problem is that our tensors are represented in the inertial basis, and even when we have coordinate discontinuities (as in our current periodic domains) this basis must be continuous across the cut. There is no way to define a basis on S^2 that satisfies that requirement.

I can think of three things related to this, not all of which are necessarily needed:

  1. Transformations between vector bases at coordinate transitions. Restricting the transitions to block boundaries is probably best. This is a contraction with the Jacobian of the map between the coordinates on the two sides of the boundary, but we don't currently have a way to compute said Jacobian. It might be sufficient to restrict the transformations to permutations and sign flips.
  2. Better support for coordinate patches (such as labeling). This is a convenience enhancement, as we can always differentiate patches by separating them using large translations in a global coordinate system. (E.g., put the equatorial region of a sphere near the origin and the polar regions near (+/-100, 0).) This is mostly relevant for input and output.
  3. Transformations between patch coordinate systems. This is close to the mathematical atlas, in that we would want overlaps between the patches (but we would still presumably want a canonical one in any given block). This is not needed for basic DG. (We have no problem with the discontinuities in periodic domains.) It may be necessary in cases where non-boundary information needs to be communicated, (limiting? ray tracing?) but it may be easier to either use approximate methods (e.g., working in logical coordinates) or recast the communication as boundary data (e.g., an Euler's method ray trace can be communicated as a boundary point and a displacement vector into the next element). Note that mapping coordinates on the boundary is easy, as we can go through the logical coordinates, which we know the relation between.

cc: @gsb76

kidder commented 5 years ago

These papers on multi-patch methods in SpEC might be worth looking at...

mar-celine commented 5 years ago

Possible motivations for implementing this functionality: