[All] Introduce integration schemes - #6117
Open
bakpaul wants to merge 86 commits into
Open
Conversation
bakpaul
added
pr: enhancement
bakpaul
force-pushed
the
26_05_introduce_integration_schemes
branch
2 times, most recently
from
June 10, 2026 14:46
0aba213 to
16b6e0f
Compare
bakpaul
marked this pull request as ready for review
June 10, 2026 14:49
bakpaul
added
pr: status to review
This was referenced Jun 10, 2026
Contributor
Author
|
[ci-build][with-all-tests] |
alxbilger
reviewed
Jun 12, 2026
bakpaul
force-pushed
the
26_05_introduce_integration_schemes
branch
from
June 16, 2026 15:03
8f17907 to
99e800d
Compare
…l take into account the Newton step
…inition and residual-based one
…onent.ODESolver* but throw warnings when used
…pute real initial acceleration in Newmark-beta
…ready responsible for this. But it needs to be noted that for rigid mapping the propagation is wrong and the propagation assumes a Euler implicit
fredroy
force-pushed
the
26_05_introduce_integration_schemes
branch
from
September 8, 2026 00:17
41ab494 to
4692959
Compare
Collaborator
|
[ci-depends-on] detected during build #76. To unlock the merge button, you must
|
…ing inertia effect
Collaborator
|
[ci-depends-on] detected during build #77. To unlock the merge button, you must
|
alxbilger
reviewed
Sep 10, 2026
Contributor
There was a problem hiding this comment.
the source file in the diff is questionable...
| * before solving. This method now internally calls doIntegrate. | ||
| */ | ||
| virtual void integrate(const core::ExecParams* params, SReal dt, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult) override final; | ||
| virtual void doIntegrate(const core::ExecParams* params, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult) = 0 ; |
| * Template method pattern is implemented here to ensure some data/member are rightly initialized | ||
| * before solving. This method internally calls doSetupIntegrationStep that can be overridden. | ||
| */ | ||
| virtual void setupIntegrationStep(const core::ExecParams* params, SReal dt, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult) final; |
Contributor
There was a problem hiding this comment.
do you need those methods to be public? Can't they be protected?
| virtual sofa::Size getIntegrationSchemeTimeOrder() const = 0; | ||
| /** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **/ | ||
|
|
||
| /** New API methods of VelocityBasedImplicitIntegrationScheme **/ |
Contributor
There was a problem hiding this comment.
Suggested change
| /** New API methods of VelocityBasedImplicitIntegrationScheme **/ | |
| /** API methods of VelocityBasedImplicitIntegrationScheme **/ |
"New" will no longer be valid if your API is still here in 15 years.
| {"ForceField", FFIELD}, | ||
| {"BaseAnimationLoop", SOLVER}, | ||
| {"OdeSolver", SOLVER}, // même valeur que ci-dessus | ||
| {"IntegrationScheme", SOLVER}, // même valeur que ci-dessus |
Contributor
There was a problem hiding this comment.
Suggested change
| {"IntegrationScheme", SOLVER}, // même valeur que ci-dessus | |
| {"IntegrationScheme", SOLVER}, |
| }; | ||
|
|
||
| } // namespace sofa::core::behavior | ||
| using OdeSolver = BaseIntegrationScheme; |
Contributor
There was a problem hiding this comment.
Should this alias be deprecated?
| { | ||
|
|
||
| class RelativeEstimateDifferenceMeasure : public NewtonRaphsonConvergenceMeasureWithSquaredParameter | ||
| class SOFA_SIMULATION_CORE_API ExplicitIntegrationScheme : |
Contributor
There was a problem hiding this comment.
I feel that this class is not really specialized for explicit methods. And if we compare to ImplicitIntegrationScheme, we can see a lot of similarities in setupIntegrationStep. The only advantage I see is for strong typing (which can be a valid reason to keep this class). What's your opinion?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR replaces the ODE solvers by Integration schemes. It enriches the API of Implicit integration schemes by exploding the timestep solving in sub phases useful for Newton applications
Now instead of single monolithic way of expressing an integration scheme, two families of integration schemes are introduced the Implicit and Explicit ones.
Explicit integration schemes get no improvement from being run into a Newton solver, thus their implementation remain unchanged and they can still live in a one solve function. Enabling local optimization such as lumping the mass matrix to compute acceleration.
Implicit solvers are divided here in to three main families : Velocity-based, acceleration-based and the rest. By doing so, the velocity and acceleration based integration schemes share a common implementation enabling a clear API to introduce new ones. As it can be seen in the PR, for any new Velocity based IS we need to implement 4 simple methods. For acceleration based it is 5. But the implementation sticks to the basics of what makes an IS : the position update, the velocity update, the acceleration computation and some derivative terms. A full documentation + scientific explanation will be added using the following this custom note https://typst.app/project/rVNQw8slVmqX7aHTCUrewe
To list them, the current velocity based IS are
And the acceleration based :
And the others are :
This is a first required step to implement a global Newton on the simulation.
There is still a TODO list :
(re) implement the symplectic ISPS: I am sorry for the history being croped to 11 commits. There should be way more but it has been lost because I started with a much complex PR including the work on the Newton solver which in the end was to intricated, so I started fresh with only the modifications on the ODE...
About first order :
I've only implemented is for velocity-based IS, I don't feel that it makes sense in acceleration based one. For instance, in Acceleration based one we could also think of second order approximation. But for instance for the Newmark solver it would react as an explicit IS or as if beta = gamma = 0. For me this approximation makes sense for second order IS, but if you use a higher order one, you just want every order. Actually I have the implementation somewhere but it makes the implementation much more complexe for no real use IMO
After struggling with diffusion it seems like the first order implementation was broken since its creation. A 1/h was missing in front of the mass matrix in the LHS. This PR fixes it too.
List of regression tests I had to regenerate because of unconverged CG:
--> Most of these errors are due to CG not converged except for "Pendulum, SofaScene, fallingSofa, and distance grid ones". But for most of those the error is imperceptible visually : the expected precision might be wrongly set, or explaned in this list.
--> All scenes on non-linear mappings where simply broken because the CG did only one step.
--> The pendulum is now working better because the trapezoidal rule was a bit broken before
--> The SofaScene has huge difference because of the BeamAdapter addMDx method that is broken. The regression files will be regenerated when the PR is merged if necessary.
Finally the forceFeedback component in SOFA wasn't using the contact force but the impulsion dt*lambda) because the legacy implementation of the EulerImplicitSolver was multiplying the RHS and the LHS by dt. This is not the case anymore, so now the forces are real forces, and so you will need to carefully update the force factors in your scene to cope for this missing factor. Plus, it has to be noted that the unit test values of forces will be updated with forces instead of impulsion.
Last point on the static solver: the old implementation of the Newton-Raphson algorithm has been droped as it will be reimplemented in a more generic way in future PR. But the new version of the static solver still propose a newton algorithm based on Armijo condition ofr linesearch. It is 'optimized' by considering the system matric as symetric only for computin the line search stopping criterion. This will be studied more profoundly in the future generic implmentation.
I've added some todos here and there for future work on Newton. Some of them are instruciton some are still questions to be answered beut are not needed until a proper Newton algorithm is introduced.
One especially is to be noted : the propagation of states. It is currently done by the animation loop. The issue is that the freemotion part is wrongly done as it is not the freePos that is directly propagated buyt first the freeVel then we explicitly integrate it using eulerImplicit scheme which doesn't make sense. This will be fixed in another PR.
[with-all-tests]
[force-full-build]
[ci-depends-on https://github.com/sofa-framework/SofaPython3/pull/615]
[ci-depends-on https://github.com/sofa-framework/SofaGLFW/pull/283]
[ci-depends-on https://github.com/sofa-framework/BeamAdapter/pull/232]
[ci-depends-on https://github.com/sofa-framework/CSparseSolvers/pull/8]
[ci-depends-on https://github.com/sofa-framework/ManifoldTopologies/pull/16]
[ci-depends-on https://github.com/SofaDefrost/ModelOrderReduction/pull/176]
[ci-depends-on https://github.com/sofa-framework/PluginExample/pull/23]
[ci-depends-on https://github.com/sofa-framework/Registration/pull/35]
[ci-depends-on https://github.com/sofa-framework/SofaSphFluid/pull/22]
[ci-depends-on https://github.com/SofaDefrost/SoftRobots/pull/346]
[ci-depends-on https://github.com/SofaDefrost/SoftRobots.Inverse/pull/86]
[ci-depends-on https://github.com/SofaDefrost/STLIB/pull/139]
[ci-depends-on https://github.com/sofa-framework/Regression/pull/114]
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