Several issues using SofaCaribou on sofav21.12 and v21.06

[ruiliang-gao]

Hi @jnbrunet ,

I want to use Caribou to play with a few Hexahedral experienments but came with a few issues along the way.
I'm on caribou master branch, using the SOFA_EXETERNAL_ DIRECTORIES in-tree compilation (as we have disscussed this earlier in another thread), cmake 3.20 and win10. And i have tested this both on sofa v21.12 and v21.06.

1. if i keep all the default options in cmake (BUILD_TESTS and BENCHMARKS are ON), without building SofaPython3. I got the following cmake config error for Caribou(even after i manually set eigen3_dir):
   Could not find a package configuration file provided by "Eigen3" with any
   of the following names: Eigen3Config.cmake...

2. If i set BUILD_TESTS to OFF (since the above error happens at sofa_plugins/caribou/unittest/SofaCaribou/CMakeLists.txt:19 (find_package))
   if on sofa v21.12, there are no errors in the cmake step but compilation has quite a few errors related to BENCHMARKS. I simply unchecked the BENCHMARKS in cmake and the compilation is fine.
   switches to sofa v21.06, There are no errors in the cmake step and compilation is fine even with BENCHMARKS set to ON.

3.Then i tested it with both v21.12 and v21.06 and got the same issue here:

with the attached scn file, there are no errors upon loading the XML and the hex geometry model loads well. But the hex model can not move when started simulation. And it crashes when i want to use mouse to grab it. I tested replacing the integrator, solver and mass element by the Caribou ones, still no luck.

caribou-test.txt

Please let me know how i can correct the xml or if there is anything missing in my compilation steps. Thanks!

[hugtalbot]

Thanks a lot @rgao15 for noticing us.

@Sidaty1 @fredroy @guparan @jnbrunet have you already experienced this?

it makes me think that we should clarify the status of the Caribou plugin on GitHub : under a Mimesis account or the SOFA one.

[jnbrunet]

No idea for the first error, I will try to compile on Windows and report back here.

[jnbrunet]

Hey @rgao15

Concerning your second issue, could you try adding some boundary condition? I suspect the system isn't converging. Something like this should suffice:

<BoxROI name="base_roi" box="9.95 9.95 -0.95 25.05 25.05 0.05"/>
<FixedConstraint indices="@base_roi.indices" />

You could also try to start from a working scene, such as those in the scenes folder, and build your way up to the desired scene. Maybe this one?

[ruiliang-gao]

Hi @jnbrunet!

Thanks for the suggestions.
I added the BoxRoi and FixedConstraint to my test scene, it still has the same non converging issue (see output below) and as soon as i use mouse to grab, it crashes.
[INFO] [BackwardEulerODESolver] ======= Starting static ODE solver =======
...
Newton iteration #1 |R| = 4.104351e+00 |R|/|R0| = 1.000000e+00 |du| / |U| = 1.000000e+00 Time = 22 ms # of linear solver iterations = 80
Newton iteration #2 |R| = 9.475597e-04 |R|/|R0| = 2.308671e-04 |du| / |U| = 6.742831e+01 Time = 22 ms # of linear solver iterations = 83
[DIVERGED] The linear solver failed to solve the unknown increment.

I also played with the "backward_euler.py" you mentioned, I converted it XML and it converges now, i can see the hex bar is deformed a bit under gravity. It seems i need to use backend="Eigen" for LLTSolver and add this pattern_analysis_strategy="ALWAYS" to the BackwardEulerODESolver to make it work?

However i still can not use the mouse to grab the model, it crahes with the same output:
_########## SIG 11 - SIGSEGV: segfault ##########
8: sofa::helper::BackTrace::dump - 0x7ff888c96ff07: sofa::helper::BackTrace::sig - 0x7ff888c971706: seh_filter_exe - 0x7ff909370cc05: seh_filter_exe - 0x7ff909370cc04: _C_specific_handler - 0x7ff8e85fec303: chkstk - 0x7ff90bc91fb02: RtlRaiseException - 0x7ff90bc410201: KiUserExceptionDispatcher - 0x7ff90bc90bd00: sofa::core::objectmodel::DDGNode::updateIfDirty - 0x7ff8886f6330

[jnbrunet]

Hey @rgao15 ,

Sorry for the late reply, I had a busy week! It's good that you made it work. Using Eigen as the solver backend or analysing the matrix pattern at each time iteration should not be mandatory to reach convergence, especially for close to linear material such as StVk. I saved your scene and I will try to play a little bit with it in the next days.

For the segmentation fault, I see that it breaks in the StiffSpringForceField that is automatically added by SOFA on mouse grab. I will poke @hugtalbot here as I think this might be a regression. @hugtalbot , did you guys changed something in this FF for direct solver that could cause this crash? Didn't Alex recently played in these trouble waters that is interaction forcefields and alike? The callstack is the following:

########## SIG 11 - SIGSEGV: segfault ##########
  sofa::helper::BackTrace::sig(int)
  _ZNK4sofa4core11objectmodel7DDGNode13updateIfDirtyEv+0
  sofa::component::interactionforcefield::StiffSpringForceField<sofa::defaulttype::StdVectorTypes<sofa::type::Vec<3u, double>, sofa::type::Vec<3u, double>, double> >::addDForce(sofa::core::MechanicalParams const*, sofa::core::objectmodel::Data<sofa::type::vector<sofa::type::Vec<3u, double>, sofa::type::CPUMemoryManager<sofa::type::Vec<3u, double> > > >&, sofa::core::objectmodel::Data<sofa::type::vector<sofa::type::Vec<3u, double>, sofa::type::CPUMemoryManager<sofa::type::Vec<3u, double> > > >&, sofa::core::objectmodel::Data<sofa::type::vector<sofa::type::Vec<3u, double>, sofa::type::CPUMemoryManager<sofa::type::Vec<3u, double> > > > const&, sofa::core::objectmodel::Data<sofa::type::vector<sofa::type::Vec<3u, double>, sofa::type::CPUMemoryManager<sofa::type::Vec<3u, double> > > > const&)
  sofa::core::behavior::BaseForceField::addMBKdx(sofa::core::MechanicalParams const*, sofa::core::TMultiVecId<(sofa::core::VecType)2, (sofa::core::VecAccess)1>)
  sofa::simulation::mechanicalvisitor::MechanicalAddMBKdxVisitor::fwdForceField(sofa::simulation::Node*, sofa::core::behavior::BaseForceField*)
  sofa::simulation::BaseMechanicalVisitor::processNodeTopDown(sofa::simulation::Node*, sofa::simulation::Visitor::VisitorContext*)
  sofa::simulation::BaseMechanicalVisitor::processNodeTopDown(sofa::simulation::Node*)
  sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocator<sofa::simulation::graph::DAGNode*> >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::less<sofa::simulation::graph::DAGNode*>, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
  sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocator<sofa::simulation::graph::DAGNode*> >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::less<sofa::simulation::graph::DAGNode*>, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
  sofa::simulation::graph::DAGNode::doExecuteVisitor(sofa::simulation::Visitor*, bool)
  SofaCaribou::ode::BackwardEulerODESolver::assemble_rhs_vector(sofa::core::MechanicalParams const&, sofa::core::behavior::MultiMatrixAccessor const&, sofa::core::TMultiVecId<(sofa::core::VecType)2, (sofa::core::VecAccess)1>&, sofa::linearalgebra::BaseVector*)
  SofaCaribou::ode::NewtonRaphsonSolver::solve(sofa::core::ExecParams const*, double, sofa::core::TMultiVecId<(sofa::core::VecType)1, (sofa::core::VecAccess)1>, sofa::core::TMultiVecId<(sofa::core::VecType)2, (sofa::core::VecAccess)1>)
  SofaCaribou::ode::BackwardEulerODESolver::solve(sofa::core::ExecParams const*, double, sofa::core::TMultiVecId<(sofa::core::VecType)1, (sofa::core::VecAccess)1>, sofa::core::TMultiVecId<(sofa::core::VecType)2, (sofa::core::VecAccess)1>)
  sofa::simulation::SolveVisitor::processSolver(sofa::simulation::Node*, sofa::core::behavior::OdeSolver*)
  sofa::simulation::SolveVisitor::sequentialSolve(sofa::simulation::Node*)
  sofa::simulation::SolveVisitor::processNodeTopDown(sofa::simulation::Node*)
  sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocator<sofa::simulation::graph::DAGNode*> >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::less<sofa::simulation::graph::DAGNode*>, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
  sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocator<sofa::simulation::graph::DAGNode*> >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::less<sofa::simulation::graph::DAGNode*>, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
  sofa::simulation::graph::DAGNode::doExecuteVisitor(sofa::simulation::Visitor*, bool)
  sofa::component::animationloop::FreeMotionTask::run()
  sofa::component::animationloop::FreeMotionAnimationLoop::FreeMotionAndCollisionDetection(sofa::core::ExecParams const*, sofa::core::ConstraintParams const&, double, sofa::core::TMultiVecId<(sofa::core::VecType)0, (sofa::core::VecAccess)1>, sofa::core::TMultiVecId<(sofa::core::VecType)0, (sofa::core::VecAccess)1>, sofa::core::TMultiVecId<(sofa::core::VecType)2, (sofa::core::VecAccess)1>, sofa::simulation::common::MechanicalOperations*)
  sofa::component::animationloop::FreeMotionAnimationLoop::step(sofa::core::ExecParams const*, double)
  sofa::simulation::Simulation::animate(sofa::simulation::Node*, double)
  sofa::gui::qt::RealGUI::step()
  QTimer::timeout(QTimer::QPrivateSignal)
  QObject::event(QEvent*)
  QApplicationPrivate::notify_helper(QObject*, QEvent*)
  QCoreApplication::notifyInternal2(QObject*, QEvent*)
  QTimerInfoList::activateTimers()
  g_main_context_dispatch
  g_main_context_iteration
  QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
  QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
  QCoreApplication::exec()
  sofa::gui::qt::RealGUI::mainLoop()
  sofa::gui::GUIManager::MainLoop(boost::intrusive_ptr<sofa::simulation::Node>, char const*)
  __libc_start_main

[ruiliang-gao]

Hi @jnbrunet!
A quick update here. The "caribou_backward_euler.scn" seems to work fine with the original SOFA's integrators and solvers. Again i'm on caribou master and sofa v21.06.

I used the following and the convergence, framerates, mouse-picking all worked. well
<EulerImplicitSolver rayleighMass="0.05" rayleighStiffness="0.0"
<CGLinearSolver iterations="500" threshold="1.0e-8" tolerance="1.0e-10"

But when I tested it with Caribou solvers, the framerates is very low (<10 fps), and it sometimes diverges, with the mouse picking not working.
<BackwardEulerODESolver rayleigh_stiffness="0.0" rayleigh_mass="0.0" newton_iterations="20" printLog="0"
<ConjugateGradientSolver maximum_number_of_iterations="1000" residual_tolerance_threshold="1e-8"
preconditioning_method="Diagonal" printLog="0"

[jnbrunet]

Hey @rgao15 ,

Thanks a lot for the report. The frame drop seems normal to me here:

1.  EulerImplicitSolver is doing only 1 Newton iteration (it is a limitation of this solver), while you are asking BackwardEulerODESolver to do 20 iterations.
2. You ask CGLinearSolver to do 500 CG iterations, while you ask ConjugateGradientSolver to do 1000 iterations.
3. You are using a Rayleigh damping of 5% of the mass with the EulerImplicitSolver, and no damping at all with BackwardEulerODESolver. Rayleigh damping might help reach convergence faster.

In other words, it looks like SOFA integrator solves faster, but they are probably not converging towards a realistic solution. If they do, it's because you are solving only linear terms. It means you can probably relax Caribou's solver attributes. From what you shown me, their criterions are more for non-linear materials.

I will look into this mouse picking issue as soon as I can.

[ruiliang-gao]

Thank you @jnbrunet !
I did not realize EulerImplicitSolver can only do 1 newton iteration and is actually solving only the linear terms.
I just tried lowering the newton_iterations to "1" or "2" in BackwardEulerODESolver and it has similar speed and results as EulerImplicitSolver now.

For the mouse issue, it seems it only happens with BackwardEulerODESolver as i tested the same scene with StaticODESolver and the mouse picking is fine.