Question about Constraint types

[Moon Ki Jung]

Hi, Sherman.
According to your advice, I tried to make my own custom force. But when I looked at the Advanced Programming Guide on the SimTKcore document page, I found that I should override ‘calcForce’ and ‘calcPotentialEnergy’ functions. I thought that I may make some mistakes during that work.

So, I tried to find an alternative method. First, I defined a ‘MobilityConstantForce’ object to a Pin type Mobilizedbody. And I got its ‘ForceIndex’. Then I defined a class that is inherited from ‘TriggredEventHandler’. The role of this event handler is that when time is over 1 second, the MobilityConstantForce object should be disabled using its ForceIndex.

To check the kinetic energy of the system, I defined a class that is inherited from ‘PeriodicEventReporter’. By using ‘calcKineticEnergy’ function, I could get the total kinetic energy of the system.

But I found some problems. In the previous thread, after I added a code like ‘integ.setMaximumStepSize(0.1)’ I thought that the problem of mechanism error disappeared. But if I set the TimeStepper’s end time larger, the mechanism stopped after a certain amount of time. When I checked its kinetic energy, it was not constant after the problem had occurred.

I’m very sorry for bothering you. But would you please check my modified version of source code again? The link of the modified source code is here:
https://docs.google.com/leaf?id=0B-t2k1 ... MWI0&hl=en

Thanks very much in advance.

Best regads,
Moonki

[Jean-Olivier Racine]

Hello Sherm,

Very interesting solution you suggest there. This brings a comment and a question:

Comment:
The documentation, and more specifically the user's guide (section 2.3.1), suggest cutting a *joint* and not a body. It would be a nice addition to change that to this solution.

Question:
Wouldn't it be simpler (and equivalent) to use a null-mass, null-inertia body? In which case, you do not need to modify the affected body in any way.

Keep up the good work!
J-O

[Michael Sherman]

Hi, Moonki.

I am still investigating this problem, but have made some progress. I have determined that there is a bug in Simbody's velocity constraint projection code in the case that the constraints are inconsistent. What's happening in the Bricard mechanism is that the position constraints are being solved loosely, leaving a slight inconsistency in the velocity constraints so that the only solution is velocity=0(!). I am working on a fix for the problem.

In the meanwhile, I found that I could simulate to 1000s with KE conserved if I satisfied the constraints to a very tight tolerance of 1e-12 or 1e-13. You can do that as a workaround until I can come up with a real fix. So try tightening the integration accuracy and constraint tolerances:
integ.setAccuracy(1e-6);
integ.setConstraintTolerance(1e-12);
That makes it run more slowly but it keeps the constraints consistent at all times. My fix will allow it to run at full speed.

I have another suggestion that I'll post separately since it is independent of this problem.

Regards,
Sherm

[Michael Sherman]

Moonki -- instead of using a Free mobilizer for the first body, try using a Weld mobilizer (not a Weld constraint). That simply makes the first body act as though it were part of the Ground. I changed:
MobilizedBody::Free EVEN_PART_1_body(...);
to:
MobilizedBody::Weld EVEN_PART_1_body(...);

That way the mechanism doesn't move around in space. The alternative of a Free mobilizer plus a Weld constraint also works but adds 12 equations to the system; the Weld mobilizer uses 0 equations!

Sherm

[Michael Sherman]

Hi, J-O. Thanks for pointing out the inconsistency between the user's guide and my advice. I will fix the user's guide to do it my way!

Introducing a massless body would be a very nice way to do this, but unfortunately it won't work. Simbody can't work with an inertialess or massless body as a terminal body in the multibody tree, because that makes the system mass matrix singular. The solution method that Simbody uses allows for singular constraints but requires that the underlying tree is non-singular.

I think it would be possible to somehow recognize that a terminal massless body's motion is fully constrained and allow it, but I don't know how to do that reliably. So for now the best solution is to make the terminal bodies as massive as possible to produce a well-conditioned tree.

Best regards,
Sherm

[Michael Sherman]

(Everyone please note; this may apply to you too!)

Moonki, I noticed that you forgot to put a try/catch block around your main program. That is absolutely essential for any SimTK program if you hope to get diagnostic information. That is the only way SimTK can report error messages to you.

Your main should always look like this:
int main()
{
try {
// all your SimTK code
// ...
} catch (const std::exception& e) {
std::cout << "std::exception: " << e.what() << std::endl;
} catch (...) {
std::cout << "UNKNOWN EXCEPTION\n";
}

return 0;
}


Regards,
Sherm