This tutorial tries to give the user a first idea about the features of the topaz application of polymake. We take a look at a variety of small examples. The text contains commands to be given to the polymake system (preceded by a '>') along with the output. Commands and output are displayed in typewriter type.
One way to construct a triangulated d-sphere is to start with a d-ball and add the cone over the boundary. Let's do so and let d = 2. (We are just warming up.) To make things not too simple, we will use a triangulated square as a 2-ball. The vertices of the square are numbered 0, 1, 2, and 3, and our complex consists of the facets {0 1 3} and {0 2 3}. In topaz any simplicial complex is encoded as its set of FACETS, the inclusion maximal faces. Pay attention that the vertices must be numbered consecutively starting with 0 and that no redundancies are allowed. Thus we create a text file my_2ball.top consisting of the following three lines
Alternatively you may use the cube_complex client
Now the question of computing the boundary arises. Since a simplex is a pseudo manifold, this question is answered easily. We select all ridges contained in one facet only. polymake not only does this for us, it also checks first, if the complex actually is a pseudo manifold.
The option -A topaz tells polymake that we want to use the topaz application. Once having seen it, polymake remembers that our file is a topaz file, so you may omit this option by all subsequent computations.
But let's have a look at the file my_2ball.top once polymake is finished.
We see the section FACETS, which we produced ourselves, and a lot of additional information computed for us. (Do not worry about the representation of the sections. The most curious and impatient can find a precise explanation by clicking on the section headers.) Actually, polymake has done rather a lot. In order to verify that my_2ball.top is a pseudo manifold, polymake computed the HASSE_DIAGRAM, the dimension DIM and that the complex is PURE. With all that information, computing the boundary is easy: The Hasse diagram tells us, which ridges are contained in one facet only.
Next we want to compute the cone over the boundary. The result will be a new object, unlike the boundary, which can be viewed as a property of my_2ball.top. Whenever we want to produce a new simplicial complex, we do not call the polymake script, but call the construction program, in our case it will be cone, directly.
The command line first names the client we are using, followed by the output file, input file and the section we want to use for the construction. For any client program, if in doubt how to use it, just type the client's name and press return.
Finally we have to complete the construction of the sphere by computing the union of the ball and the cone over its boundary. The t_union client relies on the VERTEX_LABELS to determine which vertices get identified with each other. Since we did not specify any labels, they are just induced by the vertex numbering. The vertex labels of my_cone.top are the ones induced by BOUNDARY_OF_PSEUDO_MANIFOLD, except for the apex which topaz labels uniquely, in our case apex_0. If we now construct the union, topaz identifies the vertices correctly.
In order to verify what we have done, lets have a look at the HOMOLOGY of the complex. Since my_2sphere.top is an oriented pseudo manifold of dimension 2, the homology suffices to prove that it is a sphere.
The application topaz computes the reduced homology. Therefore the output tells us that H0 and H1 are trivial and H2 is isomorphic to Z.
Still not convinced? Then lets have a look at the complex. After all, a 2-sphere is embeddable in R3. All we need are coordinates for the vertices. Note that in contrast to the polytope application, we do not use homogeneous coordinates for the GEOMETRIC_REALIZATION of a simplicial complex. Add the following information to the my_2sphere.top file.
And let polymake visualize it.
If you call polymake requesting the method VISUAL, polymake visualizes the GRAPH and the facets of the complex using the GEOMETRIC_REALIZATION as embedding. If the dimension of the geometric realization is greater than three, polymake tries to embed the graph using the home-made spring embedder. The standard tool for visualization is JavaView, which is fully interactive. For instance, it allows you to rotate or zoom into your complex. There are some other visualizations available which will be introduce later.
Last but not least, topaz can verify that the complex is a sphere. If the dimension is smaller than three a deterministic algorithm is used. In higher dimensions topaz uses a heuristic approach to try to verify if the complex is a sphere.
But let us build a different sphere. We will use the boundary of a 3-ball. Since topaz views the boundary of a complex as a property of the original complex rather than a complex in its own right, we must use the extract_subcomplex client to get our sphere.
It is time to get a little more ambitious. So we will build a 3-sphere using the suspension of my_2sphere.top to do so.
Let us have a closer look at the visualization of the complex. For each facet all faces of dimension two and smaller build a distinct JavaView geometry. Try Method -> Effect -> Explode Group of Geometries in the JavaView menu. In the image you can see the facets intersecting each other and the graph of the complex.
All this is rather complicated if you are interested in just any triangulated d-sphere. Therefore topaz can produce a sphere for you. The client sphere uses the boundary complex of a simplex, for example
Another class of simplicial spheres are the boundary complexes of simplicial polytopes, leading us to the next section.
There is a strong connection between (simplicial) polytopes and simplicial complexes: The boundary_complex of a simplicial polytope (or the triangulated boundary of an arbitrary polytope) is a simplicial complex, and for a given simplicial complex one might ask, whether there exists a polytope with the complex as its boundary. Alternatively topaz computes the crosscut_complex and the triangulation_complex.
We will use polytopes generated by a random point distribution on the unit sphere to demonstrate this connection.
Again, to verify what we have done, lets compare our result with the original polytope.
Any triangulated surface is in particular a simplicial complex, hence the client surf2top. To observe its effect, try to convert the quad_surface.surf example from the surface tutorial.
The topaz application is of course not limited to triangulated balls and spheres. Any simplicial complex, represented as its set of FACETS can be worked with. In fact, topaz knows a few standard constructions. So, let's try another example, a subdivided tetrahedra. Again, topaz provides us with the means to construct such a complex.
The -geom_real flag tells the client to compute the GEOMETRIC_REALIZATION. Since computing the geometric realization can be done, yet requires some time, the client does it only when explicitly asked for. If you would like to know more about visualization and the topaz application, have a look at the following section. But for now just have a look at this. Again try Method -> Effect -> Explode Group of Geometries in the JavaView menu.
But we promised something different from balls and spheres, so try
and add the following information to the file (you may choose any name for the gluing section)
The client glue_induced_subcomplexes replaces the vertices in each glueing set by one representative (with the smallest number) and removes any redundancies which may result from this identification. If two sets are not disjoint, the client replaces them by their union to guarantee transitivity. Vertices not contained in any of the glueing sets are considered to be in a glueing set by themselves, therefore will not be glued to any other. The result is a torus.
To get a realy good look at our torus let's add coordinated to my_torus.top
and have a look at it.
Of course topaz knows about the torus and other surfaces like the klein_bottle or the projective_plane. So lets try the following
and we end up with a non orientable surface of genus 3. Again we could have let topaz do the work by calling the t_surface client. (The "-3" indicates that we want a non orientable surface homeomorphic to the connected sum of three projective planes.)
In the previous sections of the tutorial we tried to provide images for most of the example. However, the topaz application is primarily designed to work with abstract simplicial complexes. Therefore constructions only deal with coordinates if only little extra computation is involved. Otherwise topaz's means to visualize are limited. Visualization gets increasingly harder for complexes embedded in R4 or higher dimensions. Some clients like boundary_complex or cube_complex provide us with coordinates or compute them if possible (most likely you will have to specify the -geom_real flag in order to make the client produce coordinates). Otherwise all the topaz application can do is try to compute coordinates by using the spring embedder for the graph of the complex.
To visualize the complex use
and you will see the GRAPH and the facets embedded in R3 using the GEOMETRIC_REALIZATION, if it has dimension three or smaller. Otherwise the spring embedder is used. For each facet all faces of dimension two and smaller build a distinct JavaView geometry. Try Method -> Effect -> Explode Group of Geometries in the JavaView menu to see how the facets fit together. This visualization can sometimes give an insight, even if the complexes cannot be embedded in R3.
Calling polymake requesting VISUAL_GRAPH , VISUAL_DUAL_GRAPH, or VISUAL_MIXED_GRAPH embeds the graph in R3 using the spring embedder yet ignores any specified coordinates.
topaz may also visualize distinguished subcomplexes or just sets of faces with different decorations (colors, styles, etc.). Say the property specifying the subcomplex is called MY_SUBCOMPLEX, you call polymake requesting "VISUAL->SUBCOMPLEX(MY_SUBCOMPLEX)". The effect is similar to what you see when calling VISUAL, only that the facets of the subcomplex are added as well. For example, try to visualize a 3-dimensional cube_complex and its BOUNDARY_OF_PSEUDO_MANIFOLD.
The facets of the subcomplex are colored blue. Again, you may use Method -> Effect -> Explode Group of Geometries in the JavaView menu.
Alternatively to visualizing an entire subcomplex, topaz can visualize distinguished faces only. For an example, let us visualize our torus from above, its MORSE_MATCHING, and the critical faces of the Morse matching, the MORSE_MATCHING_CRITICAL_FACES.
The critical faces are colored red, the colors of the arrows interpolate in between orange (matching vertices to edges) and purple (matching (d-1)-faces to facets). As one expects, we have one critical vertex, two critical edges (the first homology group is isomorphic to Z2), and one critical triangle. In contrast to visualizing a subcomplex, where each facet of the subcomplex is drawn with all its faces, here only the distinguished faces are added to the visualization.
If visualization is not successful (e.g. the dimension of the complex is to high or there are no coordinates available), you may have a look at the face lattice. We choose a klein_bottle to demonstrate this visualization tool.
Here the matching of faces is denoted by reversed red arrows and the critical faces are marked red. As in the previous example of the torus, we have one critical vertex, two critical edges (the first homology group is isomorphic to Z + Z2), and one critical triangle. Check that the graph remains acyclic. Of course, as with VISUAL, you may also add a SUBCOMPLEX to the visualization of the face lattice: The sublattice, that is all faces and their inclusions corresponding to the subcomplex, is colored blue.
As described above, polymake uses it's spring embedder if VISUAL is called and no three-dimensional coordinates are available. As the default, the primal graph is used. However, in order to use the neighborhood information encoded in the primal graph as well as the neighborhood information encoded in the dual graph (that is neighboring vertices and neighboring facets), you may ask polymake to use the MIXED_GRAPH for the spring embedding by calling "VISUAL(mixed_graph=>1)" . The mixed-graph is composed of all nodes and edges of the primal and the dual graph and an additional edge is added between a primal and a dual node if the vertex corresponding to the primal node lies in the facet corresponding to the dual node.
In the topaz philosophy a knot is represented as a 1-dimensional subcomplex (homeomorphic to the 1-sphere) in a triangulated 3-sphere. This allows us to encode the knot-type in a purely combinatorial way as an abstract simplicial complex. Note that (unfortunately) the orientation of the knot is lost. As an example, the client unknot produces such a representation of a particular vicious unknot. However, a more intuitive way is to think of a knot as a 1-dimensional simplicial complex (homeomorphic to the 1-sphere) embedded in 3-space. Thus the client knot_complex produces a triangulated 3-sphere with an embedding of a given polygonal knot. Indeed, the client rand_knot produces a random knot by choosing random coordinates in 3-space for a closed polygonal curve of given length. Every thing discussed in this section also applies to collections of (possibly interlinked) knots, so called links, too. However, in oder to keep things simple and avoid confusion with the notion of a link of a face in a simplicial complex, we restrict the discussion to knots.
Once you obtained a triangulation S of the 3-sphere with your knot K embedded in its 1-skeleton, topaz constructs another simplicial complex homeomorphic to the UNKNOWN LINK: knot_complement by carefully refining S and removing a regular neighborhood of K. Now the homeomorphy type of the knot complement of K determines the knot type of K (this is non-trivial!).
Using the bistellar client we try to simplify the triangulation of the knot complement without changing its homeomorphy type. Let us verify that the knot produced by unknot really is trivial
The -min_n_facets tells the client to stop once the triangulation has seven or less facets. Any triangulation of a knot complement has at least seven facets and exactly seven if and only if the knot is trivial. So, hopefully, we end up with
To verify that this is really a solid torus with seven facets have a look its DUAL_GRAPH
Note that the client bistellar is a heuristic only. So a negative result only tells us that the client did not succeed, and does not prove that K is non-trivial. By the way, if you would like to have a look at the original unknot, try
In general, polymake may try to verify pl-homeomorphy for any two manifolds. To this end run the client bistellar with the -pl_comp flag set. It assumes the "test complex" to be facet-minimal. With high probability the client rand_knot produces the unknot if we limit the stick length to 12. The following series of commands tries to verify this. Again, you may visualize the random knot.
If you end up with a triangulation on 49 facets, you probably have a trefoil knot. Construct a trefoil knot by hand (and a facet-minimal triangulation of its complement as described above) and try to verify the type of your random knot.
You may also use the client edge_contraction to obtain a smaller triangulation of the same PL-type. Hopefully, polymake eventually will come with an extensive data-base of minimal triangulations of knot complements to allow for proper knot recognition and classification.