Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@bakpaul
Copy link
Contributor

@bakpaul bakpaul commented Aug 26, 2025

The constraint solver and constraint problems are too mixed up. IMO the constraint problem should only contain data describing the constraint problem (matrices, ConstraintResolutions, ConstraintCorrections maybe ?) but no intelligence, this is the solver that defines the algorithm.

Moreover, having a single solver that implements multiple method using the same ConstraintProblem structure made it messy and difficult to make changes and even enrich.

Changes

This PR does three things:

  1. Clean the component, removing unused or unnecessary data (small changes)
  2. Introduce a inheritance mechanism to dispatch the different constraint solving methods in different types. Now the method used Is explicitly stated in the name. This has multiple positive effect:
    • Now the set of parameter of the Generic constraint solver will not contain data that can only be used for some subpart of it. Because each solving method is now a real BaseObject, it can enrich the set of data itself
    • No scene can use the GenericConstraintSolver anymore and must use either ProjectedGaussSeidelConstraintSolver, NNCGConstraintSolver, UnbuiltGaussSeidelConstraintSolver and more if any is added. This is way more explicit for the user.
    • Adding a new method is fairly easy and would only require to add a new inheritance, override the doBuildSystem (if it cannot use the ones directly available in built and unbuilt constraint solver) and doSolve methods
  3. We have a clear differentiation between built and unbuilt methods in the ConstraintProblem: it is separated in two set of attributes.

A new type of solver 'DirectconstraintSolver' which are directly augmenting the system matrix to solve the constraint either in a simple direct way or in a Newton can be added in the future.

Of course all scenes are broken with that. Well, actually, only python scenes, because xml ones are saved by SceneCheking mechanism given that the SolvingMethod was not specified. But anyway, it is pretty breaking. I tried my best to fix all the one in this repo along with the ones in the "full" configuration.

Why this design ?

At first my intend was to make the solver agnostic from the solving strategy by adding a new type of component which would be added to the scene along with t he solver and would define the solving method.

My first commit shows it a bit,. I merged this new component with the ConstraintProblem (that again was a mixup between the structure and the inteligence, bu encapsulation is not always bad). Everything was good until I got the compilation error from the fact that we actually need a fixed_array of ConstraintProblem because of the asynchronous haptic loops, which made this design pretty weak. You can see how I've tried to tweak it to make it work but it wasn't satisfying. This need of having multiple instance of ConstraintProblem cried for the separation between the data and the solving method.

Afterwards, to add to this, this previous attemp would make the ConstraintSolver hollow, taking away all the purpose of its component it was making it a useless real implementation of ConstraintSolverImpl. And why adding a new component that would only enrich the constraint solver when it could be the ConstraintSolver itself that does it ?

[ci-depends-on https://github.com/sofa-framework/SofaPython3/pull/531]
[ci-depends-on https://github.com/sofa-framework/BeamAdapter/pull/200]
[ci-depends-on https://github.com/SofaDefrost/ModelOrderReduction/pull/168]
[ci-depends-on https://github.com/SofaDefrost/SoftRobots/pull/338]
[ci-depends-on https://github.com/SofaDefrost/STLIB/pull/134]
[ci-depends-on https://github.com/SofaDefrost/Cosserat/pull/158]
[ci-depends-on https://github.com/SofaDefrost/SoftRobots.Inverse/pull/73]


By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).


Reviewers will merge this pull-request only if

  • it builds with SUCCESS for all platforms on the CI.
  • it does not generate new warnings.
  • it does not generate new unit test failures.
  • it does not generate new scene test failures.
  • it does not break API compatibility.
  • it is more than 1 week old (or has fast-merge label).

@bakpaul
Copy link
Contributor Author

bakpaul commented Aug 26, 2025

[ci-build][with-all-tests][force-full-build]

@sofabot
Copy link
Collaborator

sofabot commented Aug 26, 2025

[ci-depends-on] detected during build #2.

To unlock the merge button, you must

@hugtalbot hugtalbot added pr: highlighted in next release Highlight this contribution in the notes of the upcoming release topic for next dev-meeting PR to be discussed in sofa-dev meeting labels Aug 27, 2025
@sofabot
Copy link
Collaborator

sofabot commented Aug 27, 2025

[ci-depends-on] detected during build #3.

To unlock the merge button, you must

Copy link
Contributor

@alxbilger alxbilger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I like the idea. Good job!

Is it relevent to add GenericConstraintCorrection into a component change list to help users to update the scenes?

: GenericConstraintProblem(solver)
{}

linearalgebra::SparseMatrix<SReal> Wdiag; /** UNBUILT **/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do those members need to be public?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really a container. So I don't mind having them public

Copy link
Contributor

@th-skam th-skam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the logic behind the refactoring and I think it'll be helpful for any future additions.
I only left a few comments on your changes, hope they're helpful

@sofabot
Copy link
Collaborator

sofabot commented Sep 23, 2025

[ci-depends-on] detected during build #4.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Sep 23, 2025

[ci-depends-on] detected during build #5.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Sep 23, 2025

[ci-depends-on] detected during build #6.

To unlock the merge button, you must

@bakpaul bakpaul removed the topic for next dev-meeting PR to be discussed in sofa-dev meeting label Sep 24, 2025
…info in GenericCosntraintSolver data that are dependent on the method type. Need to find a way of setting the solving method by adding a component in the scene.
…ritance. Now the constraintProblem is only a container
@fredroy fredroy force-pushed the 25_08_modularize_solving_method_in_generic_constraint_solver branch from 6faaf7a to 956c777 Compare September 29, 2025 22:10
@sofabot
Copy link
Collaborator

sofabot commented Sep 29, 2025

[ci-depends-on] detected during build #7.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Sep 30, 2025

[ci-depends-on] detected during build #8.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Oct 2, 2025

[ci-depends-on] detected during build #9.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Oct 6, 2025

[ci-depends-on] detected during build #10.

To unlock the merge button, you must

…olver is still being used"

This reverts commit dd1c031.
@sofabot
Copy link
Collaborator

sofabot commented Oct 9, 2025

[ci-depends-on] detected during build #11.

To unlock the merge button, you must

@sofabot
Copy link
Collaborator

sofabot commented Oct 9, 2025

[ci-depends-on] detected during build #12.

To unlock the merge button, you must

@hugtalbot hugtalbot added pr: status ready Approved a pull-request, ready to be squashed and removed pr: status to review To notify reviewers to review this pull-request labels Oct 16, 2025
@hugtalbot hugtalbot requested a review from alxbilger October 16, 2025 21:34
@hugtalbot hugtalbot dismissed alxbilger’s stale review October 16, 2025 21:34

Agreed in dev meeting

@hugtalbot
Copy link
Contributor

[ci-build][with-all-tests]

@sofabot
Copy link
Collaborator

sofabot commented Oct 16, 2025

[ci-depends-on] detected during build #13.

All dependencies are merged/closed. Congrats! 👍

@hugtalbot hugtalbot merged commit b3e42f1 into sofa-framework:master Oct 16, 2025
8 of 12 checks passed
damienmarchal pushed a commit to CRIStAL-PADR/sofa that referenced this pull request Oct 17, 2025
)

* First working version of exploded constraint problrms. Still lots of info in GenericCosntraintSolver data that are dependent on the method type. Need to find a way of setting the solving method by adding a component in the scene.

* Changed all problems into solvers. It makes more sense to use an inheritance. Now the constraintProblem is only a container

* Apply changes to scenes, tests and tutorials

* Apply review comments

* change ownership of d_multithreading

* Add comment on do methods and changed signature to add constraint problem

* Add scene check to fix and display info if GenericConstraintSolver is still being used

* Revert "Add scene check to fix and display info if GenericConstraintSolver is still being used"

This reverts commit dd1c031.

* Add component change for GenericConstraintSolver

---------

Co-authored-by: Hugo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr: breaking Change possibly inducing a compilation error pr: clean Cleaning the code pr: highlighted in next release Highlight this contribution in the notes of the upcoming release pr: status ready Approved a pull-request, ready to be squashed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants