Add more test assemblies

Vectornaut commented

2025-07-21 07:39:55 +00:00

Member

Primary changes

Add more test assemblies to help probe the capabilities of the engine. The new test assemblies fall into the following categories.

Adding constraints

Existing test assemblies, now with constraints.

Low-curvature. Enforce the tangencies among the packed spheres and the triangle edges, and the right angles between all these elements and the assembly plane.

Polyhedral assemblies

Polyhedron construction problems.

Tridiminished icosahedron. A partial assembly of the tridiminished icosahedron. It can be completed by setting the given inversive distance regulators as described in the comment on load_tridim_icosahedron_assemb. Helps test:
- The "Johnson solid" test problem family.
- The "Tridiminished icosahedron rigidity" test problem.
Dodecahedral packing. A partial assembly of the circle packing whose tangency graph is the adjacency graph of the faces of a dodecahedron. It can be completed by setting the given inversive distance regulators as described in the comment on load_dodeca_packing_assemb. Helps test:
- Performance on larger, more complex networks of constraints (12 elements, 30 constraints).
- Ability to maintain a reasonable configuration without user adjustments as a complex network of constraints is built up step by step.

Difficult optimizations

Simple assemblies that the engine should handle easily, but currently doesn't.

Balanced. This test assembly reveals one way that the engine can stall, indicated by a long plateau in the loss history. You can make the plateau even longer by shrinking the inner spheres.
- We first noticed this failure mode while working on the Irisawa hexlet problem demo. When we started setting up the problem by creating the "outer," "sun," and "moon" spheres, fixing their curvatures, and then enforcing their tangencies, the engine would stall.
Off-center. This test assembly should provide a simple example where the loss
function is saddle-shaped near its manifold of minima.

Demo problems

Problems from the summer 2025 tech demo.

Radius ratio. A partial setup for the tetrahedron radius ratio problem. It can be completed by setting the given inversive distance regulators as described in the comment on load_radius_ratio_assemb. Helps test:
- The "Tetrahedron radius ratio" test problem.
Irisawa hexlet. A partial setup for Irisawa's hexlet problem. It can be completed by setting the half-curvatures of the sun and moon spheres and the first chain sphere as described in the comment on load_irisawa_hexlet_assemb. Helps test:
- The "Irisawa's hexlet" test problem.

Secondary changes

Adjust the realization triggering system to reduce redundant realizations as we set an assembly's regulators during loading. This involves two changes:

To improve update batching, consolidate all calls to realize() into a single effect, which is triggered by the needs_realization signal.
Introduce the keep_realized signal and use it to pause realization while loading assemblies.

We plan to redesign the realization triggering system more carefully in a future pull request. In the meantime, though, the adjustment in this pull request is still worth doing: it's a clear improvement, and it's unlikely to complicate the upcoming redesign.

## Primary changes Add more test assemblies to help probe the capabilities of the engine. The new test assemblies fall into the following categories. ### Adding constraints *Existing test assemblies, now with constraints.* - **Low-curvature.** Enforce the tangencies among the packed spheres and the triangle edges, and the right angles between all these elements and the assembly plane. ### Polyhedral assemblies *Polyhedron construction problems.* - **Tridiminished icosahedron.** A partial assembly of the tridiminished icosahedron. It can be completed by setting the given inversive distance regulators as described in the comment on `load_tridim_icosahedron_assemb`. Helps test: - The ["Johnson solid"](wiki/Test-problems#johnson-solid) test problem family. - The ["Tridiminished icosahedron rigidity"](wiki/Test-problems#tridiminished-icosahedron-rigidity) test problem. - **Dodecahedral packing.** A partial assembly of the circle packing whose tangency graph is the adjacency graph of the faces of a dodecahedron. It can be completed by setting the given inversive distance regulators as described in the comment on `load_dodeca_packing_assemb`. Helps test: - Performance on larger, more complex networks of constraints (12 elements, 30 constraints). - Ability to maintain a reasonable configuration without user adjustments as a complex network of constraints is built up step by step. ### Difficult optimizations *Simple assemblies that the engine should handle easily, but currently doesn't.* - **Balanced.** This test assembly reveals one way that the engine can stall, indicated by a long plateau in the loss history. You can make the plateau even longer by shrinking the inner spheres. - We first noticed this failure mode while working on the Irisawa hexlet problem demo. When we started setting up the problem by creating the "outer," "sun," and "moon" spheres, fixing their curvatures, and then enforcing their tangencies, the engine would stall. - **Off-center.** This test assembly should provide a simple example where the loss function is saddle-shaped near its manifold of minima. ### Demo problems *Problems from the [summer 2025 tech demo](https://code.studioinfinity.org/Vectornaut/dyna3/src/branch/demo-summer-2025).* - **Radius ratio.** A partial setup for the tetrahedron radius ratio problem. It can be completed by setting the given inversive distance regulators as described in the comment on `load_radius_ratio_assemb`. Helps test: - The ["Tetrahedron radius ratio"](wiki/Test-problems#tetrahedron-radius-ratio) test problem. - **Irisawa hexlet.** A partial setup for Irisawa's hexlet problem. It can be completed by setting the half-curvatures of the sun and moon spheres and the first chain sphere as described in the comment on `load_irisawa_hexlet_assemb`. Helps test: - The ["Irisawa's hexlet"](wiki/Test-problems#irisawa-s-hexlet) test problem. ## Secondary changes Adjust the realization triggering system to reduce redundant realizations as we set an assembly's regulators during loading. This involves two changes: - To improve update batching, consolidate all calls to `realize()` into a single effect, which is triggered by the `needs_realization` signal. - Introduce the `keep_realized` signal and use it to pause realization while loading assemblies. We plan to redesign the realization triggering system more carefully in a future pull request. In the meantime, though, the adjustment in this pull request is still worth doing: it's a clear improvement, and it's unlikely to complicate the upcoming redesign.

Vectornaut added 7 commits 2025-07-21 07:39:56 +00:00

Pause realization while loading assemblies 40d665d8ac

This avoids redundant realizations as we set an assembly's regulators
during loading. Adding some regulators to the low-curvature assembly
confirms that the feature is working as intended.

Add a tetrahedron radius ratio test assembly 543bc4020f

This partial setup of the tetrahedron radius ratio problem is from the
summer 2025 tech demo.

Add an Irisawa hexlet test assembly fae3f4531e

This partial setup of the Irisawa hexlet problem is from the summer 2025
tech demo.

Add a balanced test assembly 27a8cbfd69

This test assembly reveals one way that the engine can stall, indicated
by a long plateau in the loss history. You can make the plateau even
longer by shrinking the inner spheres.

Add an off-center test assembly 9c22eebb46

This test assembly should provide a simple example where the loss
function is saddle-shaped near its manifold of minima.

Add a tridiminished icosahedron test assembly 97d61e154a

Add a dodecahedral circle packing test assembly

/ test (pull_request) Successful in 3m33s

Details

4e5cd6e4a4

glen commented

2025-07-21 17:31:01 +00:00

Owner

(1) add_remove.rs has become too long and a bit diffuse in its content. The AddRemove component near the bottom certainly belongs there. I don't think the data of the test assemblies does. I think it's fine to put all of the test assemblies in one file, though, especially since ultimately they will just become save files.

(2) From our discussions, you know I am not a fan of turning off realization during loading -- that is explicitly slated for future removal? If not, I'd rather not put it in.

(1) add_remove.rs has become too long and a bit diffuse in its content. The AddRemove component near the bottom certainly belongs there. I don't think the data of the test assemblies does. I think it's fine to put all of the test assemblies in one file, though, especially since ultimately they will just become save files. (2) From our discussions, you know I am not a fan of turning off realization during loading -- that is explicitly slated for future removal? If not, I'd rather not put it in.

Vectornaut added 1 commit 2025-07-21 19:16:28 +00:00

Make the test assembly chooser its own component

/ test (pull_request) Successful in 3m32s

Details

91e4e1f414

Vectornaut commented

2025-07-21 19:26:35 +00:00

Author

Member

@glen wrote in #103 (comment):

add_remove.rs has become too long and a bit diffuse in its content. The AddRemove component near the bottom certainly belongs there. I don't think the data of the test assemblies does. I think it's fine to put all of the test assemblies in one file, though, especially since ultimately they will just become save files.

Commit 91e4e1f deals with this by making the test assembly chooser into its own component, which plugs into the AddRemove component.

(2) From our discussions, you know I am not a fan of turning off realization during loading -- that is explicitly slated for future removal? If not, I'd rather not put it in.

Yes: after this pull request is merged, we're planning to make a pull request that simplifies the realization triggering system. The simplification should, in particular, get rid of the system for pausing realization. If you'd like, I could flag the pause system with KLUDGE comments to remind us to remove it.

@glen wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/pulls/103#issuecomment-3078: > add_remove.rs has become too long and a bit diffuse in its content. The AddRemove component near the bottom certainly belongs there. I don't think the data of the test assemblies does. I think it's fine to put all of the test assemblies in one file, though, especially since ultimately they will just become save files. Commit 91e4e1f deals with this by making the test assembly chooser into its own component, which plugs into the `AddRemove` component. > > (2) From our discussions, you know I am not a fan of turning off realization during loading -- that is explicitly slated for future removal? If not, I'd rather not put it in. Yes: after this pull request is merged, we're planning to make a pull request that simplifies the realization triggering system. The simplification should, in particular, get rid of the system for pausing realization. If you'd like, I could flag the pause system with `KLUDGE` comments to remind us to remove it.

glen commented

2025-07-22 00:57:23 +00:00

Owner

In our meeting today, Glen was concerned about the fact that creating the test_assembly_chooser component in its own source file obliged adding a line to main.rs, even though that component is not used directly in the top-level code.

Wouldn't it be a solution to everyone's concerns to have a module components, with a submodule for each component? Certainly main will mention components, as it has to use some components or other. And then the components that use each other can just mention each other, as siblings within the components module.

Mightn't that be a cleaner organization that would reduce non-locality of reference? Interested in your thoughts.

In our meeting today, Glen was concerned about the fact that creating the test_assembly_chooser component in its own source file obliged adding a line to main.rs, even though that component is not used directly in the top-level code. Wouldn't it be a solution to everyone's concerns to have a module `components`, with a submodule for each component? Certainly main will mention components, as it has to use some components or other. And then the components that use each other can just mention each other, as siblings within the components module. Mightn't that be a cleaner organization that would reduce non-locality of reference? Interested in your thoughts.

Vectornaut commented

2025-07-22 08:26:11 +00:00

Author

Member

@glen wrote in #103 (comment):

Wouldn't it be a solution to everyone's concerns to have a module components, with a submodule for each component? Certainly main will mention components, as it has to use some components or other. And then the components that use each other can just mention each other, as siblings within the components module.

Mightn't that be a cleaner organization that would reduce non-locality of reference? Interested in your thoughts.

Yes, that organization sounds fine to me! I've seen it in other Sycamore projects, like this tic-tac-toe game. I'll comment again when I've implemented it.

@glen wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/pulls/103#issuecomment-3081: > Wouldn't it be a solution to everyone's concerns to have a module `components`, with a submodule for each component? Certainly main will mention components, as it has to use some components or other. And then the components that use each other can just mention each other, as siblings within the components module. > > Mightn't that be a cleaner organization that would reduce non-locality of reference? Interested in your thoughts. Yes, that organization sounds fine to me! I've seen it in other Sycamore projects, like this [tic-tac-toe game](https://github.com/nthnd/Sycamore-Tic-Tac-Toe). I'll comment again when I've implemented it.

Vectornaut added 1 commit 2025-07-22 20:29:05 +00:00

Move the components into their own module

/ test (pull_request) Successful in 3m36s

Details

5233d8eb93

This makes the module tree more reflective of module use patterns. In
particular, it restores the condition that every top-level module is
used in top-level code, which was broken by the addition of the
`test_assembly_chooser` module in commit 91e4e1f.

Vectornaut commented

2025-07-22 20:31:41 +00:00

Author

Member

@glen wrote in #103 (comment):

Wouldn't it be a solution to everyone's concerns to have a module components, with a submodule for each component?

Implemented in commit 5233d8e! I also found a pithy phrasing of the locality condition we're trying to maintain: every top-level module should be used in top-level code.

@glen wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/pulls/103#issuecomment-3081: > Wouldn't it be a solution to everyone's concerns to have a module `components`, with a submodule for each component? Implemented in commit 5233d8e! I also found a pithy phrasing of the locality condition we're trying to maintain: every top-level module should be used in top-level code.

glen commented

2025-07-22 21:58:31 +00:00

Owner

Appears to work, code organization seems cleaner to me now. Thanks. Merging.