[All] Introduce integration schemes#6117
Conversation
…based IS and some implementaiton of final IS. Still need to make the solve visitor use these IS
Co-authored-by: Alex Bilger <alxbilger@users.noreply.github.com>
0aba213 to
16b6e0f
Compare
|
[ci-build][with-all-tests] |
|
[ci-depends-on] detected during build #21. To unlock the merge button, you must
|
|
[ci-depends-on] detected during build #22. To unlock the merge button, you must
|
| /** | ||
| * \brief Component responsible for timestep integration, i.e. advancing the state from time t to t+dt. | ||
| * | ||
| * This class currently control both the integration scheme (explicit, |
There was a problem hiding this comment.
There is something wrong in this sentence.
| * (some computations can be executed in parallel). | ||
| * | ||
| */ | ||
| class SOFA_CORE_API IntegrationScheme : public virtual objectmodel::BaseComponent |
There was a problem hiding this comment.
Usually the abstract base classes in Core are prefixed with Base. I recommand BaseIntegrationScheme for consistency.
|
|
||
| public: | ||
|
|
||
| virtual void integrate(const core::ExecParams* params, SReal dt, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult) = 0; |
There was a problem hiding this comment.
Could you add a documentation for this function?
| /// Given the solution dx of the linear system inversion, how much will it affect the velocity | ||
| /// | ||
| /// This method is used to compute the compliance for contact corrections |
There was a problem hiding this comment.
Sorry, but the current documentation does not tell me what this function returns. Same for getPositionIntegrationFactor
| */ | ||
| virtual void updateStatesFromLinearSolution(SReal alpha, bool firstIteration = false) = 0; | ||
|
|
||
| virtual void integrate(const core::ExecParams* params, SReal dt, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult) ; |
There was a problem hiding this comment.
You should do a pass on the whole PR checking missing override keyword.
| /** | ||
| * Returns the evaluation of the residue | ||
| */ | ||
| virtual SReal evaluateResidue() = 0; |
There was a problem hiding this comment.
I think it should be residual instead of residue.
| // WARNING we expect the linear integrator to initialize the working vecs. Meaning that if we | ||
| // work in FreeMotion, the xResult should already be equal to the actual position. | ||
| // Same for the velocity. This is expected when updating the position, only a += will be done. | ||
| virtual void setupIntegrationStep(const core::ExecParams* params, SReal dt, sofa::core::MultiVecCoordId xResult, sofa::core::MultiVecDerivId vResult); |
There was a problem hiding this comment.
Is it necessary to make it virtual since you use the template method pattern?
| // WARNING we expect the linear integrator to initialize the working vecs. Meaning that if we | ||
| // work in FreeMotion, the xResult should already be equal to the actual position. | ||
| // Same for the velocity. This is expected when updating the position, only a += will be done. |
There was a problem hiding this comment.
Could you clarify a bit?
| namespace sofa::simulation::integrationschemes | ||
| { | ||
|
|
||
| class SOFA_SIMULATION_CORE_API AccelerationBasedImplicitIntegrationScheme : |
There was a problem hiding this comment.
Can you document this class?
| const core::ExecParams* m_params; | ||
| sofa::core::MultiVecCoordId m_xResult; | ||
| sofa::core::MultiVecDerivId m_vResult; | ||
| sofa::core::MultiVecDerivId m_unknown; |
There was a problem hiding this comment.
I was confused by the name of this variable. I recommend m_systemUnknown
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
[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