Design

Here I will layout some of the current design decisions.

If Mind Maps are your thing, here's a link to the CDT-plusplus Mind Map.

CDT-plusplus runs a simulation of spacetime that, once thermalized, can generate useful quantities such as spectral dimension or transition amplitudes.

So the basic unit is a simulation. A simulation is an algorithm (e.g. Metropolis-Hastings) which is run on a simplicial manifold (e.g. spherical, 3D). The algorithm must be run a certain minimum number of times to render the geometry of the simplicity manifold in an expected state such as Einstein-deSitter.

The geometry of the simplicial manifold determines the type of ergodic moves that can be run on it, as well as the CDT action used in the algorithm.

The program cdt-opt is intended to show the main logic without all of the extras needed.

The first thing that happens is that an n-dimensional ball (and later, torus) is generated using CGAL.

The radius from the center of a given n-dimensional point is taken as it's time coordinate, which defines a foliation of nested n-1 dimensional spheres within the n-dimensional ball. The set of points is then placed into the Delaunay triangulation data structure, which then finds a Delaunay triangulation of the given points. The triangulation is then checked for simplices which have bad foliations; a correctly foliated simplex will span between time coordinates which differ by exactly one. Bad foliations are deleted, and the system checks the remaining simplices on the remaining set up points. When there are no mis-foliated simplices, the simulation can begin.

A SimplicialManifold struct is constructed with a std::unique pointer to the Delaunay triangulation. An additional data struct, GeometryInfo, stores values that are used to calculate the action.

There are potentially many different algorithms that can be used, but for now we start with the Metropolis-Hastings algorithm. This algorithm makes moves based upon a probability which has two multiplicative parts: the first part is the probability of making the move divided by the probability of all other moves. For this, the algorithm must know the total number of attempted moves of all types. The second part is the change in the action generated by a move, which depends upon the changes to the GeometryInfo made by that move.

The possible (ergodic) moves depends upon the SimplicialManifold, in particular its dimensionality (3 or 4) and topology (spherical or toroidal).

Moves are defined as functions within the SimplicialManifold. Currently an S3Triangulation is defined, a 3 dimensional spherical Delaunay Triangulation.

Design of Moves It is intended that moves perform move assignment/move constructor operations on the SimplicalManifold.

Moves typically invalidate the Delaunay triangulation, and may also fail. To deal with the former, once a move has been done on the triangulation only functions of the underlying triangulation data structure class are used. To deal with the latter, a MoveManager RAII class is used which takes in the triangulation and a function pointer/closure of the intended move.

Design of MoveManager The intended design of the RAII class is that a copy of the SimplicialManifold is made, the move is attempted, and if the move's postconditions are successful, the copy is swapped with the original.

Design of SimplicialManifold If the SimplicialManifold is move-assigned or move-constructed, then this is as a result of an ergodic move being performed (hopefully within the MoveManager). Thus, the SimplicialManifold needs to update its GeometryInfo. However, if it is copy-constructed or copy-assigned, then no updates are needed.