jjcasmar

I have kind of solve this. I have reimplemented the CG solver using the one in Caribou. Based on that, I have kept only the implementation that doesn’t build the matrix, but added some calls to assemble the vector that I had to project after preconditioning according to the paper linked above.

I copy paste the implementation here, and when I…[Read more]

I have been looking at the code from Caribou, as well as the code from ShewchukPCGLinearSolver and I have posted a possible bug on the github tracker. If I understand the code correctly, there are some differences with the algorithm described in https://www.cs.ubc.ca/~ascher/papers/ab.pdf

When I have that clear, I will have a better look on how…[Read more]

I think this solves all the issue.

I think you did a small typo in
root.object2.mo.position += root.object1.mo.dx
right?

I think I still have one doubt.

From Caribou
`
// Updating the geometry
x.peq(dx); // x := x + dx

// Solving constraints
// Calls “solveConstraint” method of every ConstraintSolver objects found in the current context tree.
// todo(jnbrunet): Shouldn’t this be done AFTER the position propagation of the…[Read more]

So I still need to update the mapping to propagate the positions, right?

Great, that is what I was looking for.

So if I understand correctly,
1) Compute forces and current error to bootstrap the solver
2) Compute a dx
3) Compute x as x0 + dx
4) Propagate this changes through the graph using MechanicalPropagateOnlyPositionAndVelocityVisitor
5) Recompute forces, now in the new state
6) Repea

Somewhere between 4 and 5,…[Read more]

the mop.computeForce takes care of updating the mappings in both directions?

Sorry, cant share the scene description right now. Ill do it ASAP.

One thing I normally dont have clear if is I have to add the kFactor or dt on the computations and also the sign of the result.

For example, if used in a EulerImplicit solver, the force is multiplied by the dt and the hessian is multiplied by dt+beta value (or something like…[Read more]

@Froy can you provide a bit more details or documentation on how to do this? I am trying to mimic what I see in other types, but I fail to actually make it work. I am having linking errors when I try to load my plugin.


[ERROR] [PluginManager] Plugin loading failed (/home/jjcasmar/projects/VNCSSofaPlugin/build/Debug/lib/libVNCSSofaPlugin.so):…[Read more]

Thanks for the answer. I guess I will wait until that is ready and code that part in C++ for now.

Well, that depends on your preconditioner. For my particular use case, the preconditioned can be represented as a matrix, but its easier to represent it as some functions, kind of matrix-free preconditioner. I think saying that a its based on a external linear direct solver may arise to some misconceptions later. Better to just say that is has to…[Read more]

Thanks Hugo. I have read the document you proposed and I think that this: The ShewchukPCGLinearSolver allows to choose the preconditioner of our choice based on an external direct linear solver: LULinearSolver, SparseLDLSolver, etc Is not exactly correct.

From reading the source code, I think any linear solver can be used, not only direct linear…[Read more]

So ShewchukPCGSolver is a preconditioned conjugate gradient implementation. Why is not the default CG implementation? Seems like it is a bit hidden…

If I understand correctly, I just need to provide an implementation of my preconditioner, deriving it from sofa::core::behavior::LinearSolver and link it to the preconditioners property, right?