Skip to content

Assess Element Constraint State #100

@nickmccleery

Description

@nickmccleery

At some point, we would like to be able to surface both sketch level and per-element DOF information, to facilitate user-facing display of this information.


This screenshot is from the sketcher requirements gist. Ignore the driving/driven bit for now as I think that's a definite 'down the road' case, but works really nicely in Onshape.

Image

I chased my tail a little bit on a related topic, trying to come up with a nice way of assessing the overall system's condition (#6), but now think our starting point for this should be to generally ignore rank estimation. If we do the per-element work first, I think the sketch level results should be straightforward to pull out.

So, rather than trying to make some assessment of overall system state, flipping between LU and QR solves etc., I think a very high level solve path I'd be keen to explore is conceptually simpler:

  • Use QR in all cases.
  • Either Tikhonov regularise at all times or based on a fallback strategy if unregularised solve fails.
  • Once we've reached a solve termination condition, run SVD on the final Jacobian and interrogate the null space to identify any DOFs which may remain.
    • We can relate a DOF to the involved variables, and thus to the geometric elements which are not fully constrained.
    • This gives us a binary categorisation of all elements; any element with one or more DOF is underconstrained, and any element with zero is fully or over constrained.
  • Then, to separate fully constrained from overconstrained elements, we effectively just iterate over all of our residuals and where the residual is high and thus the constraint not satisfied, we identify the related primitives/involved elements.

After that we should be able to say whether any given element, e.g. a line or an arc, is underconstrained, fully constrained, or overconstrained. The sketch level stats should then fall out of that:

  • The sketch is underconstrained if any element is underconstrained.
  • The sketch is fully constrained if all elements are fully constrained.
  • The sketch is overconstrained if any element is overconstrained.

For discussion of the SVD based DOF determination and example code see:

For an example of how we might separate fully constrained from overconstrained elements:


Some considerations here are:

  • I don't think we'll be able to identify redundant but consistent constraints without more work.
  • We will have to let the solve run to termination to produce our stats; we can't do this up front.
  • SVD we think is relatively expensive, but hopefully doing it once per solve isn't a big deal.
  • Elements involved in multiple constraints might be harder to categorise well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions