[Lagrangian.Solver] UnbuiltConstraintSolver: implement hotstart

[fredroy]

Based on

• [Lagrangian.Solver] UnbuiltConstraintSolver: Fix resetForUnbuiltResolution (constraint re-ordering) #5871

in #5871 (and more cases) it was noted that (unbuilt) LCP was always faster than UnbuiltGaussSeidelConstraintSolver (in average ~10-20 %) and usually converged in less iterations.
Even if the algorithm is rigorously the same (apparently...)

After investigations, Claude 🤖successfully found that the main difference is UnbuiltGaussSeidelConstraintSolver was always starting its GS with the forces at 0 (cold start), whereas LCP was keeping track of the previous forces.
It also provided the implementation (I could never do that by myself 💩) which... looks good to me at least 🙃

Benches (continuation of #5871)

• 5000 steps on 3instru_collis (deformable), wire_optimization on

LCP                : 5000 iterations done in 43.9782 s ( 113.693 FPS)
UGS (w/o hotstart) : 5000 iterations done in 49.5163 s ( 100.977 FPS)
UGS (w hotstart)   : 5000 iterations done in 44.0242 s ( 113.574 FPS)

• for the fun, wire_optimization off

LCP                : 5000 iterations done in 63.7577 s ( 78.4219 FPS)
UGS (w/o hotstart) : 5000 iterations done in 99.2367 s ( 50.3846 FPS)
UGS (w hotstart)   : 5000 iterations done in 62.5122 s ( 79.9844 FPS)

This PR could be considered a little bit... controversial (:vibe:) as Claude-code implemented lots of stuff

[with-all-tests]

---

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).

[fredroy]

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

[fredroy]

Before merging, I would like a review (or at least the opinion) of either @ChristianDuriez or @EulalieCoevoet

[bakpaul]

Can you prefix all of these by previous so it is clear that they are used for storing values of previous time step ?

[bakpaul]

I don't get why this is needed. When you look at the implementation of the doPreClear, clearing the curren_cp wouldn't change a thing in what MechanicalGetConstraintInfoVisitor will get. So for me the pre/post is not necessary. could you try mergin both and calling the merged method after the clear ?

[bakpaul]

Wouldn't it be better to simply clear the whole map and start fresh ? Otherwise if the parent keep changing, this map will grow without getting properly cleaned

[bakpaul]

Using the parent as a key is somewhat strange because it it irrelevant @the level of the solver. What is relevant is the element on which the force is applied. This information is only kept in the constraint jacobian matrix. At this level I don't think it is possible to get an actual proper hotstart. What is done here it is looking at the id of the constraint at the level of the component which transform the collision detection output into the constraint jacobian. So what you are comparing here is the place of the force in the original vector of the collision detection. So for me this hotstart is just as good as copying back the content of the old force vector into the new one while clamping or padding if size mismatch. This is only by chance that you get forces that are good because the collision detection is somewhat deterministic.

The only strong difference would be when there are two component responsible of transforming this collision output into contact force, this would keep the force at least in the good part of the vector (the old forces will be used a starting point of forces coming from the same collision detection), but there is no garantee that the force is applied in the same region of the object as before. This happens when you have multiple objects colliding. But really, I don't know how much you gain with respect of a simple copy/clipping/padding work.

Could you try out your example with this simple implementation to see if you get worst convergence ?