Design - acgetchell/CDT-plusplus GitHub Wiki

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_ptr 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 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 S3Triangulation.h is defined, a 3 dimensional spherical Delaunay Triangulation; the accompanying moves are in S3ErgodicMoves.h.

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.

Design of Metropolis The Metropolis-Hastings algorithm needs to know the number of passes, where a pass equals a number of attempted moves equal to the total number of simplices in the triangulation. It also needs to know the checkpoint, which is the number of passes before it writes output (usually to a file). In addition, because each move, once invoked, will keep trying until it succeeds, it has to be able to pass a data structure into the moves themselves to keep track of this data. I'm still working on the best design for this; ideas welcome!

Design of Simulation A simulation is a worker (borrowed from Michael Caisse's example in http://cppcon.org/modernizing-your-c/) which queues up the various operations. These operations include things such as running the algorithm, calculating values on the resulting spacetimes (e.g. is it Euclidean-deSitter?), outputting results (hopefully as plots), and storing results in files (e.g. HDF5).