## Chapter 6

Inside the Library: SpatialDomains

In this chapter, we walk the reader through the different components of the SpatialDomains
Directory. We begin with a discussion of the mathematical fundamentals, for which we use the
book by Karniadakis and Sherwin [44] as our principle reference. We then provide
the reader with an overview of the primary data structures introduced within the
SpatialDomains Directory (often done through C++ objects), and then present the major
algorithms – expressed as either object methods or functions – employed over these data
structures.

The SpatialDomains Directory and its corresponding class definitions serve two principal
purposes:

- To hold the elemental geometric information (i.e. vertex information, curve
information and reference-to-world mapping information); and
- To facility reading in and writing out geometry-related information.

When designing Nektar++, developing a class hierarchy for StdRegions (those fundamental
domains over which we define integration and differentiation) and LocalRegions (i.e. elements
in world-space) was fairly straightforward following [44]. For instance, a triangle in world-space
is-a standard triangle. The first question that arose was where to store geometric information,
as information within the LocalRegions element or as information encapsulated from the
element so that multiple Expansions could all point to the same geometric information. The
decision we made was to store geometric information – that is, the vertex information in
world-space that defines an element and the edge and face curvature information – in its own
data structure that could be shared by multiple Expansions (functions) over the same
domain (element) in world-space. Hence SpatialDomains started as the directory
containing Geometry and GeomFactors class definitions to meet the first item listed
above. A LocalRegion is-a StdRegion and has-a SpatialDomain (i.e. Geometry and
GeomFactors).

We then realized that in order to jump-start the process of constructing elements and
combining them together into MultiRegions (collections of elements that represent a
(sub)-domain of interest), we needed devise a light-weight data structure into which
we could load geometric information from our geometry file and from which we
could then construct Expansions (with their mappings, etc.). The light-weight data
structure we devised was MeshGraph, and it was meant to meet the second item listed
above.