-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SofaKernel] Change the way projective constraints are propagated in visitors to fix problem (BREAKING) #216
Conversation
…y and/or position propagation visitors, as it makes it unreliable to put projective constraints in child nodes (required when they apply on the DOFs but with a different/subset topology). All codes (solvers and animationloop) must now explicitly call projection operations/visitors before propagations when required (mostly after OdeSolver::solve())
@@ -190,6 +190,9 @@ Visitor::Result AnimateVisitor::processNodeTopDown(simulation::Node* node) | |||
end(node, node->solver[i], t0); | |||
} | |||
|
|||
MechanicalProjectPositionAndVelocityVisitor(&m_mparams, nextTime, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like a wrong code duplication.
please keep the #ifdef SOFA_SUPPORT_MAPPED_MASS
version.
@@ -491,6 +491,9 @@ Visitor::Result MechanicalIntegrationVisitor::fwdOdeSolver(simulation::Node* nod | |||
//cerr<<"MechanicalIntegrationVisitor::fwdOdeSolver end solve obj"<<endl; | |||
//obj->propagatePositionAndVelocity(nextTime,core::VecCoordId::position(),core::VecDerivId::velocity()); | |||
|
|||
MechanicalProjectPositionAndVelocityVisitor(&mparams, nextTime,VecCoordId::position(),VecDerivId::velocity() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duplicated code?
@@ -1333,15 +1372,12 @@ class SOFA_SIMULATION_CORE_API MechanicalPropagatePositionVisitor : public Mecha | |||
SReal t; | |||
sofa::core::MultiVecCoordId x; | |||
bool ignoreMask; | |||
bool applyProjections; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok to remove all the applyProjections
from all the propagate visitors.
But a doc should clearly state to run the new visitor MechanicalProjectPositionAndVelocityVisitor
before propagation.
I guess there are cases where we want to project only one vector (coord or deriv), but it would be easy to write other visitors for that.
[ci-build] |
@matthieu-nesme: After STC#3 discussions, could you update your review? |
Should be ok with Compliant now. |
Some tests are now failing, it has to be understood before merging. |
[ci-build] |
…Only\1Visitor to force existing codes to be reviewed at compile time to check if MechanicalProject\1Visitor should be called first. This is safer than risking breakage at runtime for code expecting the old behavior of these visitors. FIX: add missing project visitors in Simulation::init() DOC: update comment of the propagate visitors to explicitly indicate that they do not apply projections anymore.
The failing tests were mainly due to a unintended side effect that projective constraints were no longer applied at the end of Simulation::init(). To make sure similar issues were not hidden somewhere else, in the last commit I renamed the propagate visitor to make sure existing codes fail at compilation time. Fixing other codes in private/external repos should be easy:
This information should be added to the changelog, but as far as I understood this needs to be done after the PR is merged. |
[ci-build] |
Thanks Jérémie, The remaining failing tests are our classic failures so this PR seems ok to me. |
Is this PR ready ? Should we merge it now ? |
Yes it is ready as far as I know. |
@guparan I let you merge this one :) |
Well...can someone explain briefly how this PR will affect other person's code, how will they be award something have changed and that they need to update something ? |
@damienmarchal : what you are asking is answered in the PR description, and in my comment above, explaining that now everyone will know if they need to update their code at compile-time, and decide what to do based on what I wrote. Anything else is needed ? |
Hello @JeremieA, the current approach about the changelog management is to have a description of the changes in the PR's description so that @guparan & @hugtalbot can easily integrate them into the CHANGELOG.md file in a (more or less :)) weekly basis. You can add a dedicated CHANGELOG section in the PR description in which there is a summary of the changes and, in case of behavior or API changes, the mecanism used to notify other's and minimal guideline/example on how they should fix their code. You already provided this informations into the comments feeds...but, having that in the comments feed makes them hard to find so it is better if all that is summarized. EDIT: I just updated the PR description up to my understanding. |
We edit it at the same time so I lost my contribution... |
Sorry for the dual edditing... I didn't knew github was not robust against that. I merge the PR because I hate having PR that longs for month and we can still fix the description even when it is merged/closed. Many thanks, |
for(size_t j=0; j<jacobian[i].size(); j++) | ||
{ | ||
size_t index=indices[i][j]; | ||
jacobian[i][j].addapply(out[i],in[index]); | ||
if (i == 0) serr << "out["<<i<<"] + jacobian["<<i<<"]["<<j<<"].addapply(out["<<i<<"],in["<<index<<"]) = " << out[i] << sendl; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
grrrrrr
Description
This PR removes option to apply projective constraints during velocity and/or position propagation visitors, as it makes it unreliable to put projective constraints in child nodes (required when they apply on the DOFs but with a different/subset topology). All codes (solvers and animationloop) must now explicitly call projection operations/visitors before propagations when required (mostly after
OdeSolver::solve())
This PR is changing the behavior as projective constraints because they are no longer applied at the end of Simulation::init(). To clearly make that visible to calling's code the propagate visitor was renamed to make sure existing codes fail at compilation time.
To fix that in private/external repos should be easy:
CHANGELOG for @guparan and @hugtalbot
This PR:
Reviewers will merge only if all these checks are true.