Student Post: Variations in Size on General Petersen Graphs

Hello again!

One more blog post dealing with Petersen Graphs. Last week we saw several examples of embeddings of Petersen graphs. Since one of the main goals behind creating those realizations is to 3D print them. As such, it is important that the dimensions of our embeddings are reasonable. In the previous embeddings, the graphs were realized with edges of radius .02mm. The realizations from last time were created using code that hard coded most of the dimensions of the objects instead of using any of the inherent values of a Petersen graph. Since then, the code has been changed to be much more general (also allowing it to be more readable). I have also changed the code to include the vertices of the graphs as well to more effectively demonstrate the properties of a Petersen graph.

The following example is of GP(12, 4) where the edges have radius 2mm and the spherical vertices have radius 3mm. The radius of the approximated circle created by the outer ring (in blue) is 50mm. The height of the graph is also reasonable dimensioned in this embedding.

App Sized Double Thickness Centered Terraces GP 12 4

The code that produced this example is relatively robust in terms of what dimensions it can produce when realizing these embeddings of Petersen graphs. The smaller n/k is the more variability there is in how large the radius of the edges of the graph can be. I also took a suggestion to realize the graph with the base in the center, creating a beautiful embedding.

This example is of GP(40, 10) where the edges have radius 1mm and the base has radius 50mm. The height on this graph however is ~200mm.

Modified Steel Cable Structure GP 40 10

The biggest issue with this code is that it is not very robust in terms of the size of the radius of the edges. Last week we had an example of GP(60, 12) which was very tight and had a “steel cable” in it. However, this code was only able to produce an embedding with no intersections due to the tiny radius that was being used. This example however has edges that are just thick enough to print. Given the height of this graph, one might be interested in an embedding that doesn’t have such proportionally thin edges.

As stated last time, now that we have some relatively printable realizations of general Petersen graphs, I’m going to shift my focus to working with n-panelled and n-flat graphs for next time.

Thanks for reading!


-Ben Flint

Student Post: Several Generalized Petersen Examples

Welcome back!

My last blog post dealt with learning some of OpenSCAD to tackle the problem of representing graphs in 3D, culminating in some OpenSCAD code that would draw any generalized Petersen graph. To do so, I wrote code that would take in values for the parameters that define a Petersen graph and then use a dedicated loop to draw three edges of the graph at a time by rotating 360/n degrees each time the loop was run. This created a very interesting representation of a Petersen graph where the outer rim was drawn entirely on one plane with the edges approximating a circle and the inner rim was drawn on a plane that was parallel to the outer rim. The inner rim, when drawn in a plane, creates many intersection points between the edges of the rim. However, one might have reason to be interested in representing graphs in 3D without any intersections.

I have started working on the problem of representing general Petersen graphs without any intersections between the edges that make up the inner rim (recall that they take the form (i + k)’ where (i + k) is read mod n). One thing to note before I jump into how I represented these graphs is that the edges of the inner rim form a set of cycles, C. If k divides n then these cycles will be of length m where k * m = 0 mod n and |C| = k. If k does not divide n, then |C| = 1 and that cycle will have length m = n. Thus the inner rim of GP(12, 3) will have cycles of length m = 4 and |C| = 3.

Keeping that in mind, my first attempt at drawing Petersen graphs was to draw the distinct cycles on their own planes. However, this ONLY works for generalized Petersen graphs where k divides n, because as we saw, attempting to draw generalized Petersen graphs where k does not divide n with the single cycle in the plane results in many intersections. My first attempt at drawing these graphs works by raising each vertex by a set amount. To isolate the cycles, I realized that the distinct cycle starting at vertex i’ had vertices {i’, (i + k)’, (i + 2k)’, … , (i + (n-1)k)’}. I also noted that each one of these vertices is the same mod k. Then to correctly graph the distinct cycles, I changed the height of each point by a set amount depending on its value mod k. The results presented some very interesting examples of Petersen graphs, including the following: Terraces GP 12 3The Colliseum GP 60 4The Highrise GP 60 12Top Down GP 60 12 The first of these examples is a representation of GP(12, 3), the second of GP(60, 4), and the third and fourth are of GP(60, 12) (the fourth is a top down view of GP(60, 12)). One interesting thing to note about the representation that I’ve chosen to implement is only partially successful at representing general Petersen graphs without any intersections. First there is the obvious issue that this code is severely limited in that it can’t represent any Petersen graph where k does not divide n. The second is that, even if given n and k such that k divides n, if the value of n is too large compared to the value of k, the cycles will be so long (have too many edges) that each edge will be short and intersect with the edges making the spokes of the graph. This can be seen in the second example, the representation of GP(60, 4), which I like to call “The Coliseum”. In “The Coliseum” each cycle has length 15 but there are only 4 such cycles.

I decided that the first of these issues that I would tackle would be that this code cannot represent generalized Petersen graphs for any valid values of n and k. In order to rectify this, I wrote a new function that assigned a different height to each vertex. Then I changed the function that drew the edges of the inner rim to modify the height based on its value (i + k)’ mod n. The resulting code could draw any generalized Petersen graph with valid values for n and k where the first half of the inner rim edges have rising height and the other half have descending height. This code is much more robust than the other code in that it can draw many more generalized Petersen graphs and still maintains the property that distinct cycles are all raised to different heights. However, given how close the rising edges are, the thickness of the edges had to be lowered significantly to avoid intersections. Consider the following three examples this code has produced:

The Crazy Coaster GP 11 3Funland Ride GP 12 3Steel Cable Suspension Structure GP 60 12

At first glance, the first two pictures look like they represent the same graph, but on closer inspection, the first represents GP(11, 3) and the second represents GP(12, 3). A fine distinction, to be sure but note that GP(11, 3) only has one distinct cycle, whereas all three distinct cycles of GP(12, 3) can be picked out. The third example represents GP(60, 12). Given the perspective of the picture, it can be difficult to see, but this graph is embedded with no intersections. The resulting graph looks a lot like a structure that is being suspended by tightly knit steel cables that are under tension. Though this code is more robust in the amount of Petersen graphs that it can represent, it is still plagued by the issue of drawing Petersen graphs with large values of n and small values of k without intersections.

For next week, I intend to move away from Petersen graphs and start working on representing examples of flat and panelled graphs following along with the paper On n-panelled spatial graphs, n-flat graphs and graph minors by Ryo Nikkuni and Yukihiro Tsutsumi.

As always, thank you for reading!

-Ben Flint


Nikkuni, Ryo, and Yukihiro Tsutsumi. “On n-Panelled Spatial Graphs, n-Flat Graphs and Graph Minors.” preprintWeb.

Student Post: General Petersen Graphs in OpenSCAD

The field of graph theory is diverse and interesting. There are many topics to explore and endless different representations of different graphs. A particularly interesting side of graph theory to explore involves different embeddings of graphs in 3 Space. This is exciting in part due to the modern ability to 3D print. Given that there are so many different ways to embed the same graph, one has reason to be interested in spatial embeddings of graphs that illustrate the unique and interesting properties of a graph. Considering the question of which embedding to choose is putting the cart before the horse however, as there is a more pressing question to consider: How do we represent spatial embeddings of graphs at all?

Towards answering that question, I have been learning to use OpenSCAD in order to model graphs. A class of graphs I find interesting are the Generalized Petersen graphs.  A Generalized Petersen graph, GP(n, k) has 2n labelled vertices with labels 0, 1, … , n-1, 0′, 1′, … , (n-1)’ and edges of the form (i, i’), (i, i+1), and (i’, (i + k)’) where all numbers are read mod n. The edges (i, i+1) form the “outer” rim of the graph, the edges (i’, (i+k)’) form the “inner” rim of the graph, and the edges (i, i’) form the “spokes” of the graph. It has been shown that all Generalized Petersen graphs have a Tait coloring. A Tait coloring of a trivalent graph (each vertex has three edges attached or valence 3) is an edge coloring in three colors of the graph where each vertex is adjacent to all three colors. I decided to try and realize an a Tait colored embedding of GP(11, 3) in OpenSCAD.

Learning to use OpenSCAD has been an adventure in realizing that all the coding tips and tricks I’ve picked up still apply. At first, I approached the problem of drawing GP(11, 3) by hard coding every edge. After realizing that that was tiring and a pain, I started using loops to draw the outer rim and the spokes of the graph. I wrote loops that drew the outer rim and the spokes of GP(11, 3). The loops worked by drawing an edge between vertex 0, (1, 0, 0), and vertex 0 rotated by 360/11 degrees (vertex 1) as well as between vertex 0 and vertex 0′, (1, 0, dist(vertex 0, vertex 1)) then drawing an edge between vertex 1 and vertex 1 rotated by 360/11 degrees (vertex 2) as well as between vertex 1 and vertex 1′, etc. From there I realized that not only could I condense the two loops I had written but that I could draw the inner rim in the same loop as well. Note that this embedding draws the outer rim as a polygon approximating a circle. This picture of a crown was my first attempt at drawing both rims and the spokes of the graph in the same loop. The Crown

This picture illustrates the outer rim but not the spokes or the inner rim. I had used the wrong points in the OpenSCAD code trying to create the spokes and inner rim which had connected the spokes to two vertices on the outer rim instead of across the graph to create the inner rim. This obviously does not follow the correct form for a Generalized Petersen graph, but it did result in a pretty circlet that could be colored and printed.

After inadvertently making the crown, I starting thinking about how I could draw the inner rim in for any valid k given instead of hard coding GP(11, 3). I also realized that I could easily change my current code to correctly draw the outer rim and spokes for any given value of n by rotating by 360/n degrees instead of 360/11 degrees. In order to draw the inner rim, I chose to use a similar method to the one I used to draw the outer rim and spokes . To draw the inner rim, vertices i’ and (i+k)’ have to have an edge. In order to draw this in using the same loop, I drew an edge between vertex 0′ and vertex 0′ rotated by k*360/n degrees (vertex (0+k)’) and repeated that process the same way as before. This created a properly drawn embedding of GP(n, k) given valid parameters. I decided that aesthetically having the i and i’ vertices be aligned vertically was not pleasant to look at, so I modified that code so that the “lower” (outer) rim could be scaled. Doing so resulted in the following picture of a peanut butter cup (GP(11, 3)).Peanut Butter Cup

Looking at this peanut butter cup was much more pleasant and also illustrative of a fun geometric property of GP(11, 3). When looking at the structure from the top, the outer rim almost disappears as its shape is created by the intersections of the inner rim. After all that, you might notice that this graph is only one color. That is due to the fact that a Tait coloring of this graph cannot be easily drawn using the loop that I have written. The current loop essentially draws a 3 edge chunk n times, each time rotated by 360/n degrees. Since simply coloring each edge a different color and rotating that does not result in a valid coloring, several logic statements are needed to actually realize a Tait coloring on this graph. This code can currently draw any GP(n, k). I am not sure that a Tait coloring on any distinct GP(n, k)  can be drawn in the same way.

For most of the embeddings I work with this semester, I am using a simple module in OpenSCAD called rod_rounded_ends to draw the edges and vertices of a given graph. This approach only allows for straight edge embeddings of graphs. In general this will be of interest to me as I continue to look into panelled and flat graphs and their properties.

Thank you for reading! Keep checking back for more interesting graphs!

-Ben Flint


F Castagna, G Prins
Every generalized Petersen graph has a Tait coloring
Pacific J. Math., 40 (1972), pp. 53-58

Student Post: Printing Printers

One thing I love about 3D printing is the sheer endlessness of it. There is always something new to print, and if there isn’t then you aren’t trying hard enough. I think that one defining feature of this field is the ability of the tool to improve itself. A 3D printer is not limited by how the factory set it up, or how the manufacturer designed it. Considering that some of the largest 3D printing communities are built around open source kits, it is not a surprise that there numerous mods for practically every 3D printer on the market. In almost every community guide to a 3D printer there will be a section about mods that can improve basically every part of the experience and end product. The amazing thing about these mods is that they can be created using the 3D printer that they are designed to enhance.

We happen to have a Flash Forge Creator Pro 2016 edition (FFCP), and a quick search on thingiverse returns numerous models to get started improving it. At home I have a Monoprice Select Mini v2 (MPSM) and some of the first things I printed on it were parts to improve it. In this post I want to show you a few of the parts I have printed as direct enhancements to both of these printers.

First lets look at the FFCP. DrLex on thingiverse has several designs for additions to the FFCP that are really nice. I have printed two of them for our printer. Two major problems with this printer are: the way that the filament feeds off of the spools, and the spool holders themselves. The filament is forced flush with the back of the printer when going through the normal feeding tubes, and this causes it to be stretched across the whole spool. So the first part I printed is and extension that holds the feeding tubes out from the back of the printer so the filament can feed off the center of the spools. In this photo you can see the new extension near the top printed in red. The pink circle is highlighting the old point where the feeding tubes started, and as you can see it was not ideal.FFCP_filament_guide

The spool holders themselves are also problematic on the FFCP. They allow for quite wide spools and if a thinner spool is used havoc may ensue. The spools tend to shift away from the back of the printer and the filament can get tangled behind the spool and cause all sorts of issues. This may have partly been due to the pool feeding location, but it is not worth risking damage to the printer to find out. To solve this issue I printed adjustable spool holders. These can be tightened to fit different width spools.

This slideshow requires JavaScript.

For my MPSM at home I have printed three different upgrades. This printer also does not feed filament in an optimal way, but a small guide helps to alleviate undue stress on the extruder. I also printed a new main control knob because the one that comes on the printer is lacking and a little bit ugly. Finally I printed a fan cover for the hot end cooling fan so that I don’t accidentally catch the fan blades when it is running.

In conclusion, 3D printers are awesome because you don’t have to buy extra parts to upgrade them, you can just print them. I think this is extremely cool.

Thanks for Reading. — Quincy

P.S. Here is a sneak peek at another project I am working on for the semester. Spoiler Alert: 3D scanning is really cool too.

Image: non-physically-based light transport through bubble cluster

This is an image of a non-physically based light transport through a bubble cluster generated as part of REU student Sarah Ciresi’s project. We show a physically based one below as well, but this one just looked too cool not post. This image was produced after we added circular arc rendering to a 2D raytracer, but before we added the actual simulation of light through a thin soapy film. We hope you’ll allow us some artistic license even though we’re mucking around with the physics:

Screen Shot 2017-07-01 at 10.18.18 AM

The bubble cluster was generated using our Koebe-Lib library for inversive geometry that we have developed over the past two months. The light transport was simulated with a modified version of Tantalum, a nice GPU-based 2D raytracer designed to simulate physically modeled light transport through a scene.

Here’s a rendering that is more accurately modeling the physics of light passing through a thin-film. Not quite as visually stunning, but still pretty cool:

Screen Shot 2017-07-02 at 9.59.35 PM.png

The light source is modeled as an incandescent light. We used 1.0 for the index of refraction of air and 1.33 for the index of refraction of soapy water. We are not currently simulating any color shift on reflected rays, but may add this in the future. Our walls are also modeled as infinitesimally thick, since the thickness of a bubble wall at this resolution is much smaller than a pixel. The scene was rendered using 12 million simulated photons.

Stay tuned for an initial release of Koebe-Lib’s alpha version, which we expect will occur within the next month.

On Representing Circles and Disks

JMU is hosting an REU program this summer in computer science. Sarah Ciresi, a rising senior at Georgetown, is working on a project to develop a low-cost 3D scanner for capturing soap bubble configurations. You can follow her progress here.

To aid her work, we’ve been developing a library for inversive geometry on S^2 which is (heavily) based on the structure formulated in Sharif Ghali’s excellent book Introduction to Geometric Computing. The goal is to make our library public at the end of the summer.

Ghali covers a lot in his book, including the development of some spherical geometry (though his “circles” are really only the “great circles”), and an implementation of the oriented projective space T^3 as formulated in Jorge Stolfi’s PhD thesis and subsequent book. This oriented projective space is really the space of rays in \mathbb{R}^4.

In this post we assume some familiarity with homogeneous coordinates of points in \mathbb{R}^3 and their representation in \mathbb{R}^4. Readers unfamiliar with these should check out “Introduction to Geometric Computing” for a very well thought out introduction. (Perhaps we’ll post a video on this sometime.)

Representing disks on the sphere

For our purposes, we needed more spherical geometry than Ghali’s introduction provides. Specifically, we work with circles on S^2 which are not necessarily great circles, and we also need our circles to be oriented, meaning that there is a given direction along the circle that is treated as counter-clockwise. Another picture of this is that instead of oriented circles, we are dealing with disks, which are the oriented circles along with the region bounded on the left of the circle (where “left” is defined with respect to the circle’s counter-clockwise orientation).

Now, notice that any circle C on the sphere S^2 can be represented by the plane ax + by + cz + d = 0 whose intersection with S^2 is C. This, in turn, is the intersection of the hyperplane ax + by + cz + dw = 0 in \mathbb{R}^4 with 3D unit sphere in the the w=1 level sub-space. (If it seems like we just jumped into 4-dimensions out of nowhere, don’t worry, it will make sense in a minute.) Thus, we give coordinates to a circle C on S^2 by specifying the 4-tuple of coefficients of the hyperplane (a, b, c, d).  Notice that multiplying all the coefficients by any fixed \lambda does not change the circle represented since ax + by + cz + dw = 0 = \lambda a x + \lambda b y + \lambda c z + \lambda d w.

To obtain disks from such a representation, we adopt the convention of Stolfi and treat (a, b, c, d) and (\lambda a, \lambda b, \lambda c, \lambda d) as the same disk if and only if \lambda > 0. Our convention is to identify the disk incident to C with area less than 2\pi with those 4-tuples where d > 0 and those with area greater than 2\pi with those 4-tuples where d < 0. (d = 0 is a great circle, and then the direction of the 3-vector (a, b, c) is used to identify the disk.)

One of the nice things about this representation, is that several computations become trivial. In the following let (a, b, c, d) represent a disk D with boundary C For instance:

  • The Euclidean center of C (i.e. the center in Euclidean 3-space, not on the sphere S^2) is given by the homogeneous coordinates (-a, -b, -c, \sqrt{a^2 + b^2 + c^2} / d), (the 3D point (\frac{-ad}{L}, \frac{-bd}{L}, \frac{-cd}{L}) where L=\sqrt{a^2 + b^2 + c^2}).
  • The spherical center of D is (a / L, b / L, c / L) where L is defined as above.
  • The Conical cap of C, which is the apex of the cone tangent to S^2 at C is given by the homogeneous coordinates (-a, -b, -c, d). If d \neq 0, then this corresponds to the 3D point (-a / d, -b / d, -c / d), and if d = 0, this corresponds to the point at infinite at the endpoint of the ray (-a, -b, -c). (For the uninitiated, this is the power of the homogeneous coordinates–we can represent points at infinity as if they are any other point. But that is a matter for another post.)

The Inversive Distance

One of the main functions we work with in inversive geometry is the inversive distance between two circles. The usual way of defining this for circles on the sphere is:

\langle C_{1}, C_{2} \rangle = \frac{-\cos \sphericalangle ( p_{1},p_{2} ) + \cos(r_{1}) \cos(r_{2})}{\sin(r_{1}) \sin(r_{2})}

where p_{i} is the spherical center of C_{i} and r_{i} is its spherical radius (for i = 1, 2) and \cos \sphericalangle ( p_{1},p_{2} ) is the spherical angle between p_1 and p_2.

Given our representation of circles as the 4-tuples (a_1, b_1, c_1, d_1) and (a_2, b_2, c_2, d_2), the inversive distance becomes

\langle C_{1}, C_{2} \rangle = \frac{-(a_1 a_2 + b_1 b_2 + c_1 c_2 - d_1 d_2)}{\sqrt{a_1^2 + b_1^2 + c_1^2 - d_1^2} \sqrt{a_2^2 + b_2^2 + c_2^2 - d_2^2}}

which is simply the cos(\theta) between the vectors (a_1, b_1, c_1, d_1) and (a_2, b_2, c_2, d_2) under the (3,1) Minkowski inner product.

In other words, circles on the sphere endowed with the inversive distance are a geometric picture of vectors in space-time endowed with the usual Minkowski inner product!

Student Post: Sphere Packing Honors Thesis Proposal

Dear Reader,

I’ve decided to do a senior capstone project involving the material I’ve presented in the previous posts. Therefore, in the previous two weeks I’ve been working on writing up my honors thesis proposal for sphere packing.

My proposal can be found at the following link if you wish to see it:

Xiang Chen’s Honor Proposal

This week I will be exploring a more advanced tool called COMSOL to which I have been provided access courtesy of Dr. Marcelo Dias. Among many other features, this tool provides a very comprehensive set of capabilities for analyzing the stresses internal to an object subjected to forces. I will be figuring out how to load my sphere packing graphs into COMSOL and parsing the stress output from COMSOL.

Thanks for reading,


Student Post: Automated Detection of 3D Print Failures Thesis Proposal


For the past two weeks, I have been drafting and submitting my honors thesis proposal in order to formalize what I have been blogging about this semester! The proposal is titled “Automated Detection of 3D Printer Failures” and can be found at the link provided below. Please peruse the proposal for details and to see what is coming for the next year.

Thank you,

Adam S.


New Paper: Rigidity of Circle Polyhedra in the 2-Sphere and of Hyperideal Polyhedra in Hyperbolic 3-Space

We just posted a new paper to the ArXiV, “Rigidity of Circle Polyhedra in the 2-Sphere and of Hyperideal Polyhedra in Hyperbolic 3-Space“. This is joint work with Philip L. Bowers at FSU and Kevin Pratt, who worked on the project over the summer as a visiting undergraduate research assistant here at JMU.

This paper grew out of the curious and surprising result of Jiming Ma and Jean-Marc Schlenker, in which they construct an inversive distance circle packing on the sphere which is not globally rigid (meaning that there exist more than one realization of the same inversive distance data as a pattern of circles that are not Möbius equivalent).

Suppose you are given a triangulation K of a topological sphere and a real number weight w(ij) on each edge ij of K. The inversive distance circle packing problem asks, is there a set of circles C on the sphere and a bijection P : V(K) \rightarrow C such that for every edge ij of K, the inversive distance between circles P(i) and P(j) is equal to the weight w(ij)? We call C an inversive distance circle packing realizing (K, w). There are really two important questions: (1) given such a K and edge labeling w, does there exist a packing? and (2) if one does exist, is it unique?

The Ma-Schlenker result was especially surprising because the answer to question (2) has been yes, it’s unique, in virtually every setting circle packings have been studied. (As of this post’s writing, question (1) remains very much open for general inversive distance circle packings.) Ma and Schlenker start with a Euclidean twisted octahedron and use some powerful mathematical tools (Pogorolov maps and infinite de Sitter space) to obtain their result. Recently, we provided some constructions of Ma-Schlenker style octahedra in the intrinsic inversive geometry of the sphere in another paper that may interest the reader. We can now construct lots of examples of families of circle-polyhedra where there is not uniqueness.

The Ma-Schlenker construction raises the question, “When is global rigidity of an inversive distance circle pattern on the sphere guaranteed?” This is the subject of our paper.

Enter Cauchy

The questions being asked of circle patterns have an analog in the study of Euclidean polyhedra dating back to the ancient Greeks. The question might be asked, if we know the shapes of all the faces of a polyhedron and which faces are attached together along which edges (though not at what dihedral angle), does that data determine the polyhedron uniquely? In general, the answer is no–take a cube and replace its top face with a pyramid made of four equilateral triangles to obtain a house-like structure; now, invert the pyramid. However, in 1813, Cauchy proved his celebrated Rigidity Theorem, which states that if we further require that the polyhedron be convex, along with the specified faces and their combinatorics, then there is only one construction possible. This theorem (and some of its later proofs–Cauchy’s original argument had several serious bugs) is certainly one of Erdös’s proofs from the book (and in fact one proof of the theorem is in the Aigner and Ziegler book Proofs from THE BOOK).

To Our Paper

Inspired by Ma and Schlenker’s use of Euclidean polyhedra to prove their result, we set out to recreate Cauchy’s proof, except in the case of inversive distance circle packings. To do this, we first generalized packings to circle-polyhedra, which are really the natural way of talking about gluing up circle-polygons along “edges” to form patterns of circles on the sphere. In order to do this, we began to work with circle space, a space that is a partial dual to the real-projective 3-space in which circles are points, coaxial families of circles are lines, and bundles of circles are planes. Along with this space comes a notion of convexity for circle-polyhedra, and our main result is an analog to Cauchy’s: if you specify (up to Möbius transformations) a bunch of circle-polygons (to serve as the faces of a polyhedron), and how the polygons should be combined (by identifying edges), then if there exists a convex circle-polyhedron satisfying your specifications, it is the unique convex circle-polyhedron satisfying your specifications.

Our proof of this theorem follows the same general outline as Cauchy’s original proof, though with some really lovely forays into hyperbolic geometry. (A quick preview: if a bunch of circles intersect some other circle orthogonally, we can take the parts of each of the intersecting circles lying on the interior of the one circle to be hyperbolic lines in the Poincare disk model of hyperbolic 2-space. From there we build some nice hyperbolic polygons with some interesting properties, and derive a lemma about certain hyperbolic robot arms constructed out of revolute joints with the occasional piston thrown in. It’s all very fun.)

Check out the full details here. 

Student Post: FreeCAD FEM Module Results

Dear Reader,

In accordance with my timeline, I have explored the capabilities of FreeCAD’s FEM Module along with other auxiliary modules in order to find a reliable software program that enables easy application and analysis of stress on a 3D object.

I explored the basic functionality on a trivial yet essential structure as shown in the following image:

Here were the displacement and stress results on individual nodes of the mesh:

In this test, I used auto generated nodes for the mesh. FreeCAD also appears to support more customized methods for defining structural nodes:

However, I’m still in the process of figuring this feature out. Also, I’m working on designing a specific 3D object that would be simple to stress test given a specific set of available equipment.

Stay tuned for updates.

Thanks for reading,