What are the differences between GenericConstraintSolver and LCPConstraintSolver ?

[John-MF]

Hi, I'm trying the Geomagic plugin and have an unstable behaviour caused by the LCPConstraintSolver on the scene Geomagic-DeformableCubes.scn. The initial contact force can reach 10N, while when using the GenericConstraintSolver it is only around 0.5N.

The other difference that I notice when using one or the other is that with GenericConstraintSolver the feedback force is updated only when SOFA can compute the deformations and stays constant in between, while LCPConstraintSolver always returns an estimation of the force based on the position and the last scene computed.

I'm trying to understand what changes between the two solvers to see how I could improve my haptic feedback when SOFA runs at low fps.
Where can I find the differences between them ? In the documentation they are described almost identically;

• A Generic Constraint Solver using the Linear Complementarity Problem formulation to solve Constraint based components
• A Constraint Solver using the Linear Complementarity Problem formulation to solve BaseConstraint based components
  while Factorize ConstraintSolvers #3148 mentions that the generic solver is used for non linear problems.

Here are the two behaviour with GenericConstraintSolver and LCPConstraintSolver showing the instability in the second case

DeformableCubesGeneric.mp4

DeformableCubesLCP.mp4

[bakpaul]

Hello !

Both (LCP and Generic) are able to solver for non-linear constraint problems. The main difference between the two (outside of any consideration of force feedback) is that the LCP solves for only contacts and has got a global parameter of friction that is applied to the whole scene. This parameter mu is in the parameter set of the LCP and overrides every other parameters that might have been set. Even the parameter present in the CollisionResponse, which mean that if you want to get the same parameters between the two scenes, make sure you've set the right parameters.

In SOFA usually, constraint solving is defined by the constraint itself, e.g. a UnilateralLagrangianConstraint defines a little class where the constraint is solved: the ConstraintResolution this is the object responsible for solving for one constraint inside the iterative solver. This "bottom to top" mechanism allows the GenericConstraintSolver to be agnostic of the constraint is solves, enabling for a versatile API, any type of constraint can be used. But this comes with a cost of computation efficiency, this is why the LCPConstraintSolver exists, when you know that you are using only contact constraint with a single mu parameter, then you can speedup the computation and use other solving strategy (e.g. an unbuilt GS), and that is what is done in the LCP.

For the force feedback side, the LCPForceFeedback component that is used to compute force in the haptic thread is agnostic of the constraint solver used. It uses methods form the virtual API of ConstraintSolvers. Meaning that the method used to compute the forces in the haptic thread is different for the two of them. From what I saw in a quick glance, is that this computation is timed to enforce a stable force feedbakc frequency. The default value is 0.8ms. Nevertheless, the fact that it converged or not is never tested, you'll get the result that have been computed anyway. So my guess is that one of them is converging and the other one is not. To check that you'll need to modify the code... Currently the verbosity of the LCPConstraintSolver is hardcoded, you'll need to change the default parameter of the method nlcp_gaussseidelTimed in /home/paul/dev/sources/sofaProject/sofa-framework/sofa/Sofa/framework/Helper/src/sofa/helper/LCPcalc.h. The one of the GenericConstraintSolver is well coded, you should get the warning when it happens.

Finally, it would really easier to help you if we could get access to the scene files to see the components and parameters that you used. If you provide them I could try to give you more insight before you need to modify the source code.

Hope that helped you !

[John-MF]

Hi @bakpaul, thank you for your answer.
First of all sorry for forgetting tomention the scene I am using. It is this one: applications/plugins/Geomagic/scenes/Geomagic-DeformableCubes.scn. I will edit the question to specify it at the beginning.
The only thing I changed to test the generic solver was <LCPConstraintSolver tolerance="0.001" maxIt="1000"/> into <GenericConstraintSolver tolerance="0.001" maxIt="1000"/>.

If I understand correctly LCP is just an optimization of the Generic solver specific for contact constraints, but the difference in behavior may come from the fact that I didn't use the same friction coefficient between the simulations. I thought at first this was likely since there is no friction explicitly specified anywhere in the scene, and it's not the first time I get instabilities trying to simulate high friction with the Omni device, but I went to test it this morning and neither changing <LCPConstraintSolver tolerance="0.001" maxIt="1000" mu="0.000001"/> in the LCP nor <CollisionResponse name="response" responseParams="mu=0.6" response="FrictionContactConstraint" /> (because 0.6 is the default parameter for LCPConstraintSolver ) in the Generic changed the behavior of the simulations.

Regarding the force feedback I don't have to set anything to see the warnings from GenericConstraintSolver ? Because I never got any, while I did recompile SOFA to have those from LCPConstraintSolver and it only happens in specific circumstances that we can ignore for the question.

[hugtalbot]

Hi @John-MF

Have you been able to make some progress?
There is definitely a difference in the way contact forces are interpolated between LCP&GenericCS.
To investigate have you tested Paul's suggestion?

Currently the verbosity of the LCPConstraintSolver is hardcoded, you'll need to change the default parameter of the method nlcp_gaussseidelTimed in /home/paul/dev/sources/sofaProject/sofa-framework/sofa/Sofa/framework/Helper/src/sofa/helper/LCPcalc.h. The one of the GenericConstraintSolver is well coded, you should get the warning when it happens.

[github-actions[bot]]

⚠️ ⚠️ ⚠️
@John-MF
Feedback has been given to you by the project reviewers, however we have not received a response from you. Without further news in the coming weeks, this discussion will be automatically closed in order to keep this forum clean and fresh 🌱 Thank you for your understanding

[github-actions[bot]]

⚠️ ⚠️ ⚠️
@John-MF
In accordance with our forum management policy, the last reply is more than 4 months old and is therefore closed. Our objective is to keep the forum up to date and offer the best support experience.

Please feel free to reopen it if the topic is still active by providing us with an update. Please feel free to open a new thread at any time - we'll be happy to help where and when we can.