Module mechanism 

The mechanism of a part: its mates as constraints on the program’s state — where its placed parts are, how its joints are turned — and what they declare for solving it: the parts a fixed mate holds, each joint’s coordinates as values a solve moves and a user sets. Solving, checking and measuring is generic (crate::solving).

A mate is worked out in two steps, each a target of the run. Its entities are resolved once, in the frames of the parts they are of ([resolve], the target crate::mate), which reads no state. Its constraint on the state ([constrain]) places those where the state has the parts, and is all that is made again when a part moves. A joint’s limits are constraints of their own ([limit]), which hold anywhere short of them.

A constraint’s derivatives are by the state’s own steps (see geop_core_program::values::StateValue): a pose’s by a twist in its own frame, a coordinate’s by what is added to it. They are exact, through every pose a placement reads — a part placed in a placed part moves with both — computed in dual numbers, one state at a time.

The editor solves (crate::solving::solve): the solve moves the state until the constraints hold, making only the constraints it asks again at every state it tries, of the part as built (see geop_lib_constraints::constraint::Remade) — which is why a constraint reads only the state and what reads none — and the editor runs the program once more with the state found.

The constraints of one step’s mates are defined together, and so are their unknowns (see [define]).

Functions

mates_of

The mates of the part reader reads, resolved, by name, in the order the steps made them.

mates_resolved

How many mates this thread has resolved — their elements found and measured on the parts placed — ever. What any question about the mates costs grows with this, so a test can bound the work an edit does by the mates it touches, rather than time it.