dyna3

glen/dyna3

Brief summaries of activities one might try/problems one might solve with dyna3.

P370 Frugal Firepower from the Playground in Math Horizons Volume 25 no. 4. (the cannonball shipping problem) Find the configurations of five nonoverlapping unit spheres that have the maximal points of contact with planes parallel to the coordinate axes (the problem is really looking for the rectangular solid with minimum l+w+h into which they will fit, but extremal solutions will necessarily have lots of contact).
P12 Rigid Hexagon from the Playground in Math Horizons Vol 2 no.1. Specifically, let ABCDEF be six points in space such that AB=CD=EF=a, BC=DE=FA=b, and AD=BE=CF=a+b. Then ABCDEF is a planar equiangular hexagon. So in particular it is rigid, which hopefully dyna3 should detect even though fewer distances are specified than generically produce rigidity. A more extreme version of this is specifying AB=BC=CD=DE=EF=1 and AF=5, constraining all six points to lie on a line. A question one might explore with dyna3, for which I do not know the answer, is whether there are also (interesting) specifications of exactly 7 or 8 distances that also entail rigidity.
In the other direction, consider equiangular, equilateral, not-necessarily-planar hexagons, see https://arxiv.org/pdf/1105.5046.pdf. These generally have a one-dimensional configuration space, possibly with additional isolated point(s?). This is true even though the system might seem overdetermined. And according to Dan Piker, an equilateral right-angled heptagon also has a one-dimensional configuration space (or at least the space has at least one one-dimensional component),
A slightly farfetched one: put three or more "pins" in a plane (or in space). Constrain an additional point in the plane as the "pencil" such that the length of a string looped around the pins and the pencil in some way (there are multiple configurations) has constant length. Find the locus of positions of the pencil. (Generalizations of ellipse-drawing; note James Clerk Maxwell considered these loci in his youth and apparently wrote an article or report of some kind on his findings.)
Somewhat less farfetched, another natural generalization of ellipse-drawing: find the locus of a point P such that the surface area of tetrahedron ABCP is a constant. (In the plane, an ellipse is the locus of a point P such that the perimeter of ABP is constant.)

A thing I am trying/needing to do right now:

Understand the configuration space of http://levskaya.github.io/polyhedronisme/?recipe=aaaD but with: each trapezoid a congruent rectangle and each pentagon constrained to be regular (and hence planar) and each rhombus constrained to be planar. In particular, is it realizable with an arbitrary aspect ratio of rectangle, and if so, for a given ratio, what similarity type of rhombus arises? Actually, in real life, the rectangles will each be a face of a box, so bonus points if we can actually make them part of a rectangular solid.

I am trying out solvespace to understand how things go in that setting for doing this. So here's something of a log of my efforts, in case that provides useful background for Dyna3 work.

I decided to start with the rectangular panels, as they are individually rigid, and connecting them with the appropriate constraints creates the entire polyhedron.
It is very easy to draw one such a rectangle in SolveSpace: activate the current planar sketch (actually in starts activated in a new drawing), use the Rectangle tool, and then constrain the W and H to the desired dimensions. And the bonus points come easily, too: you can just hit the extrude button and it makes a rectangular solid with one face being the rectangle, and then constrain the third dimension of that solid.
Now I just want to make more boxes. Unfortunately, it does not seem that SolveSpace has a "free copy" operation that will let me just duplicate this box, except with the ability to rotate/translate arbitrarily in space as a rigid body. However, there does appear to be a contributed branch that adds such an operation, so I am going to try to compile from source and then go onto that branch.
OK, compiling from source went ultra-smoothly, and then rebasing the branch copy-groups from https://github.com/phkahler/solvespace.git on current master went smoothly, and then restarting SolveSpace with this I was then easily able to make a copy of the first box. And making corresponding vertices of the first and copy boxes coincide was totally smooth, and sure enough, they snapped into a configuration in which the boxes were connected at a vertex. However, then selecting adjacent edges -- one from each of the two boxes -- and trying to constrain their angle to 108° (since they form two consecutive edges of a regular pentagon) led SolveSpace to assert

SOLVE FAILED! unsolvable constraints
the following constraints are incompatible
  c00c-points-coincident
  c00d-angle

This was just kind of astonishing, since (a) without the c00d-angle constraint, SolveSpace reported that the copy box had three degrees of freedom, which seems like they must correspond to the orientation of that box as a whole, so it's unclear why it can't just use one of those degrees of freedom to ensure the angle I specified; and (b) if I just make two line segments and make each the same length and then make two endpoints coincide and then constrain their angle to 108°, SolveSpace has no problem. So maybe there is something just superficially wrong with the boxes; but (i) I am not sure nor have the time how we might debug that, and (ii) if not, then clearly the tactic of "just skin SolveSpace" seems totally dead, in that at the point where things went awry, it still seemed like just a "toy" problem. Kind of a pity because I do really need to know the answers here, and I was hoping SolveSpace was going to find them for me!

But I did get a nice response from a SolveSpace maintainer pointing me to the "Link/Assembly" method of combining copies of objects, so I switched to that. Unfortunately, it reported unsolvable constraints in exactly the same place. I think there is a lot of clue about what is going on in the following SolveSpace forum entry in which a user was simply trying to construct a truncated icosahedron from hexagon and pentagon units (very similar to this use case!) and was running into very similar problems. The following passage is particularly alarming:

For example, two point-on-point constraints will always overconstrain, because they're either redundant (if the distances between the point pairs are equal) or inconsistent (otherwise). Take a look at the assembly tutorial for examples of sets of constraints that exactly constrain a part in an assembly.

whitequark et al. have a development version in which you can permit overconstraints if they're redundant but not inconsistent. If you don't want to think about how many degrees of freedom you're constraining, that might help.

Also note that groups are solved in order, with geometry in earlier groups locked down by the time a later group is solved. In your step 6, it looks like you're constraining in a way that would require two parts to move, which won't work.

I think it will be hopeless to assemble the aaaD without a step in which multiple boxes need to move in concert. And it has some warning and maybe some hope for Dyna3:

Warning: the authors of SolveSpace seemed to feel the need to solve in pretty bite-size chunks at a time. Is that because doing more global constraint satisfaction was impractical?
Hope: maybe it's not a limitation of the underlying engine but more of the way that the current SolveSpace UI is using that engine, chopping it up into small pieces that are successively locked down. Perhaps if we fed the same data into SolveSpace in a different way, chunking it a bit less fine (i.e., merging elements from different boxes in a single solver call), we would get a global solution.

Ok, so at this point I backed off to making the smallest construction I could think of that would have enough in it that it would simultaneously solve into a non-planar configuration that should be tightly constrained enough to produce elements that will assemble rigidly into the full solution, placing each additional copy one at a time. I hit on six rectangles, surrounding two equilateral triangle faces, with two adjacent far sides of rectangles that will form regular pentagons constrained to be at 108°. That seems to curl up properly and I think it is fully constrained and will assemble into the desired unit. I should mention, though, that the first time that I built it, it folded "incorrectly" (like bad protein folding!) in that one part was convex one way and the other part was convex the other way, so overall it was not a portion of a convex solid. The only way I could find to get out of this rut was to delete some of the line segments, sort of push around the remaining elements to be closer to what I knew the solution should look like, and then put back in and re-constrain those deleted line segments. This second time I got lucky that it snapped into the desired configuration.
The next step is to extrude the boxes from the six rectangular faces of the assembly, but so far I have not found a way to get solvespace to realize that they are extrudable rectangles. I can create a new workplane from two adjacent edges and a vertex, but then if I select all of the edges and vertices and hit extrude, only that one original vertex extrudes to make a line, not the whole rectangle to make a solid. Not sure if this is due to numerical issues leading solvespace not to think that the whole rectangle really lies in the workplane, or if there's just something I don't know about bringing elements into a workplane or something. I was not able to figure this out after a bunch of poking around, so I posted on the SolveSpace forum about it, but hadn't gotten a response last I checked.
In the end, I solved approximately by hand in GeoGebra and found that independent of the aspect ratio, the rhombi are golden, which I think will now let me do an explicit construction of the polyhedron. So guess and check by a human worked -- some luckiness that this is such a nice example (part of why I am presenting it at PCMI!)