-
Notifications
You must be signed in to change notification settings - Fork 343
[Lagrangian] Refactoring of GenericConstraintSolver #5666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lagrangian] Refactoring of GenericConstraintSolver #5666
Conversation
|
[ci-build][with-all-tests][force-full-build] |
|
[ci-depends-on] detected during build #2. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #3. To unlock the merge button, you must
|
alxbilger
left a comment
There was a problem hiding this 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?
Sofa/Component/AnimationLoop/src/sofa/component/animationloop/FreeMotionAnimationLoop.cpp
Outdated
Show resolved
Hide resolved
...nt/Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/BuiltConstraintSolver.h
Show resolved
Hide resolved
...int/Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/ConstraintSolverImpl.h
Outdated
Show resolved
Hide resolved
Sofa/Component/AnimationLoop/src/sofa/component/animationloop/FreeMotionAnimationLoop.cpp
Outdated
Show resolved
Hide resolved
.../Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/BuiltConstraintSolver.cpp
Outdated
Show resolved
Hide resolved
...olver/src/sofa/component/constraint/lagrangian/solver/ProjectedGaussSeidelConstraintSolver.h
Outdated
Show resolved
Hide resolved
| : GenericConstraintProblem(solver) | ||
| {} | ||
|
|
||
| linearalgebra::SparseMatrix<SReal> Wdiag; /** UNBUILT **/ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
...Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/UnbuiltConstraintProblem.h
Show resolved
Hide resolved
...agrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintSolver.cpp
Outdated
Show resolved
Hide resolved
.../Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintSolver.h
Show resolved
Hide resolved
th-skam
left a comment
There was a problem hiding this 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
.../Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintSolver.h
Show resolved
Hide resolved
...agrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintSolver.cpp
Show resolved
Hide resolved
...int/Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/ConstraintSolverImpl.h
Show resolved
Hide resolved
.../Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintSolver.h
Outdated
Show resolved
Hide resolved
|
[ci-depends-on] detected during build #4. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #5. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #6. To unlock the merge button, you must
|
...Lagrangian/Solver/src/sofa/component/constraint/lagrangian/solver/GenericConstraintProblem.h
Show resolved
Hide resolved
…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
6faaf7a to
956c777
Compare
|
[ci-depends-on] detected during build #7. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #8. To unlock the merge button, you must
|
… still being used
|
[ci-depends-on] detected during build #9. To unlock the merge button, you must
|
…_constraint_solver
|
[ci-depends-on] detected during build #10. To unlock the merge button, you must
|
…olver is still being used" This reverts commit dd1c031.
|
[ci-depends-on] detected during build #11. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #12. To unlock the merge button, you must
|
…_constraint_solver
|
[ci-build][with-all-tests] |
|
[ci-depends-on] detected during build #13. All dependencies are merged/closed. Congrats! 👍 |
) * 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]>
The constraint solver and constraint problems are too mixed up. IMO the constraint problem should only contain data describing the constraint problem (matrices,
ConstraintResolutions,ConstraintCorrectionsmaybe ?) but no intelligence, this is the solver that defines the algorithm.Moreover, having a single solver that implements multiple method using the same
ConstraintProblemstructure made it messy and difficult to make changes and even enrich.Changes
This PR does three things:
BaseObject, it can enrich the set of data itselfGenericConstraintSolveranymore and must use eitherProjectedGaussSeidelConstraintSolver,NNCGConstraintSolver,UnbuiltGaussSeidelConstraintSolverand more if any is added. This is way more explicit for the user.doBuildSystem(if it cannot use the ones directly available in built and unbuilt constraint solver) anddoSolvemethodsConstraintProblem: 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
ConstraintSolverhollow, 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