the mappings around the freemotion. It is disabled by default, so no
change is actually introduced from the exisiting behavior.

classes to redefine the state vector allocation for the constraint
lambdas and the corrective displacements.

… to an active node

git-svn-id: https://code.insimo.fr/svn/IS/ISSofa/branches/ISSofa@10524 f8a8aa39-ebdb-4476-bae3-08f188f1b544

- ConstraintParams need to be given the VecId where the constraint
  jacobian must be accumulated, and where the constraint lambda must be
  stored. Right now the current API mostly assumes that the constraint
  lambda and the constraint force are stored in pre defined VecIds. It
  was therefore difficult to know where these quantities are stored,
  because it was dependent both on the constraint solver, and the
  constraint correction scheme used in the scene.

- Separate method which computes the corrective displacement coming
  from the constraint force from the methods which apply this corrective
  displacement. This is anyway what was silently done in the concrete
  implementations of the ConstraintCorrection API.

- give read only access to the MultiMatrixAccessor used to construct
  the system matrix, if the solver actually builds it.

- rename applyContactForce method into applyConstraintForce method.

- also change the signature of the method, and document its
  responsibility, which is bounded to:

  -- projecting the constraint force in the motion space provided the
  constraint jacobian is known (which should be the case at the time
  this method is called)

  -- computing dx = A^-1 . J^t . lambda
     and storing the result in the VecId passed as a parameter.

The visitor must be passed the location of the VecId where the
corrective motion coming from the influence of the constraint force is
stored. On overall this Visitor can be tuned to work along with the
parameters of the methods of the ConstraintCorrection API.

MatrixLinearSolver.

Also, PrecomputedConstraintCorrection can no longer rely on the former
API methods to compute the list of "active dofs" (which correponds to
the sparsity pattern of the constraint jacobian). Instead this list is
computed whenever the update of the compliance matrix is done.

ConstraintParams object that contains the necessary information to
retrieve:

- where to read the free motion of the dofs ( as done before )

- where the constraint jacobian must be accumulated

- where the constraint force must be stored

introduced in ConstraintCorrection API. It also allocates dynamic VecId
for constraint jacobian and constraint lambda.

constraint lambda at the constraint dofs level.

…ilarities with UniformCompliance from the Compliant plugin. The idea is to be able to express constraint equations compatible with the Constraint / ConstraintCorrection API with mappings that give a strain measure and its jacobian.

… rhs as vfree + pos * invDt when solving constraints for velocity corrective motion.

…lution which factors the compliance block to perform a direct solving of the constraint blocK. The default mode stays the iterative one where each line is treated one after the other.

…straint index offset when filling the constraint jacobian matrix.

…which assembles the geometric stiffness computed by a mapping inside the mechanical matrix. Does not support multimappings.

MappingGeometricStiffnessForcefield

created when allocating new state vectors.

ConstraintCorrection constructor argument nbLines, which specify the
size of the block this ConstraintCorrection is dealing with, is a non
optional argument. Also prefer the use of setters / getters when
specifying the nbLines and tolerance, since it is then much easier to
track down mutable vs non mutable operations on a ConstraintCorrection
object.

and dx of the mapped dofs.

support arbitrary block size. Previous implementation would crash
silently (out of bounds in a raw buffer) if the block size was above 6.

lambdas at the constraint dofs level and accumulate it back to the
independent degrees of freedom, after the corrective motion has been
applied.

geometric stiffness when available.

when required, ie when solving constraints in position. Removed
linearizeMappingsAroundFreeMotion option, since only one mapping
linearization per time step is computed.

A personal opinion though, I find these random generated strings to be
very confusing and ugly.

ContactMappers when propagating the free motions to contact dofs.

velocity violation computation.

velocity violation evaluation.

computation in the general case ( arbitrary number of lines ) using LDLT
decomposition provided by Eigen library.

…Deriv

API.

accumulating MapMapSparseMatrix of child dofs.

example from the CompliantPlugin. It shows that the formulation which
uses a linearisation of the constraint force during the time step offers
superior stability.

component into MappingGeometricStiffnessForceField to be consistent
with the filename

namespace.

…ires

a ConstraintParams so that it can retrieve MatrixDerivID which specifies
for each state the location of the constraint jacobian (in a MatrixDeriv
form) to use to build the compliance matrix.

resetConstraint and getConstraintJacobian must be passed a ConstraintParams
which is used internally to retrieve which allocated MatrixDeriv to use.

Essentially it means that MechanicalResetConstraintVisitor and
MechanicalGetConstraintJacobianVisitor must be passed a pointer to a
ConstraintParams object.

MechanicalGetConstraintJacobianVisitor must be constructed with the
ConstraintParams object that the buildComplianceMatrix receives as a
parameter.

resetConstraint and getConstraintJacobian method are passed a
ConstraintParams which must be used to know which allocated MatrixDeriv
to use internally by these methods. This contrast with the previous
implementation whereby a fixed MatrixDerivId was used.

- buildComplianceMatrix must be passed a ConstraintParams object which has
  the MatrixDerivId that can be used to retrieve which allocated
  MatrixDeriv contains the jacobian of the constraints.
- MechanicalResetConstraintVisitor uses the ConstraintParams to know which
  allocated MatrixDeriv to clear.

…ust be

constructed with a ConstraintParams.

…an by

the means of a MultiMatrixDerivId instead of a ConstMultiMatrixDerivId
since some visitors can need to have a write access to this location.
Accumulation of the constraint directions towards independant dofs being
the main reason for this change.

holonomicC()

constraint direction can be retrieved from the ConstraintParams.

local default instance of ExecParams.

ConstraintParams constraint jacobian location to its default value.

…cC().

The MatrixDerivId for the constraint jacobian must be retrieved through
a ConstraintParams object.

…motion

# Conflicts:
#	modules/SofaConstraint/GenericConstraintCorrection.cpp
#	modules/SofaConstraint/GenericConstraintCorrection.h

One scene was crashing in SensableEmulation plugin : testOmniDriverEmu.scn
I fixed it by adding the option : solveVelocityConstraintFirst="true"

Fixed added warnings
- in GenericConstraintSolver.cpp line 368
none of the function parameter (cParams, res1 and res2) were unused.
- in GenericConstraintCorrection.cpp line 277
the complianceFactor is not used.