One other unrelated comment:
The VerletIntegrator is almost always a bad choice for a multibody system. I would suggest that you use RungeKuttaMersonIntegrator instead for most purposes.
Regards, Sherm
Prescribed motion
- Kishor Bhalerao
- Posts: 21
- Joined: Thu Mar 13, 2008 12:52 pm
RE: Prescribed motion
Hi Sherm,
Just to follow up on this discussion. Right now, we have got the prescribed motion working with the RNA problem in Simbody and the system seems to behave as expected. I am now attempting to use it in my DCA solver.
In main(), after defining the PrescribedMotion (this is a function of time), I expected that on calling the function system.realize(state,Stage::Velocity), the state of the system would be updated to reflect the changes due to the prescribed motion. However this does not seem to be the case. Here is what I have been doing.
// defined on MobilizerQIndex(4)
Constraint::PrescribedMotion con_1(....)
// defined on MobilizerQIndex(5)
Constraint::PrescribedMotion con_2(....)
system.realizeTopology();
State& state = system.updDefaultState();
cout<<state.getQ();
// Change the value of time without changing anything else in the system
// I expected this to change the values of both Q(4) and Q(5)
state.updTime()=10.0;
system.realize(state,Stage::Velocity);
cout<<state.getQ();
The Q in both the cases is the same. I am not sure why this is the case. The prescribed motion function defined in con_1 and con_2 is definitely being called and the values generated by calcValue() and calcDerivative() are exactly what I expect them to be. But these do not get reflected in the state.
Do you have any suggestions ?
Thanks,
Kishor.
PS: The search feature in the doxygen docs for simtk2.0 is very useful !
Just to follow up on this discussion. Right now, we have got the prescribed motion working with the RNA problem in Simbody and the system seems to behave as expected. I am now attempting to use it in my DCA solver.
In main(), after defining the PrescribedMotion (this is a function of time), I expected that on calling the function system.realize(state,Stage::Velocity), the state of the system would be updated to reflect the changes due to the prescribed motion. However this does not seem to be the case. Here is what I have been doing.
// defined on MobilizerQIndex(4)
Constraint::PrescribedMotion con_1(....)
// defined on MobilizerQIndex(5)
Constraint::PrescribedMotion con_2(....)
system.realizeTopology();
State& state = system.updDefaultState();
cout<<state.getQ();
// Change the value of time without changing anything else in the system
// I expected this to change the values of both Q(4) and Q(5)
state.updTime()=10.0;
system.realize(state,Stage::Velocity);
cout<<state.getQ();
The Q in both the cases is the same. I am not sure why this is the case. The prescribed motion function defined in con_1 and con_2 is definitely being called and the values generated by calcValue() and calcDerivative() are exactly what I expect them to be. But these do not get reflected in the state.
Do you have any suggestions ?
Thanks,
Kishor.
PS: The search feature in the doxygen docs for simtk2.0 is very useful !
- Michael Sherman
- Posts: 806
- Joined: Fri Apr 01, 2005 6:05 pm
RE: Prescribed motion
Hi, Kishor.
Prescribed motion in Simbody is currently treated exactly like any other constraint. Realizing calculates the constraint *errors*; it does not enforce the constraints (except acceleration constraints which are used to calculate the udots and multipliers).
The realize(state,stage) method takes the state as a "const" value -- it can't make state changes. For state changes you need what Simbody calls a "solver", meaning some method that takes a writable state. The solver you are looking for in this case is system.project() which takes a state that violates position and/or velocity constraints and projects it onto the position and velocity constraint manifolds. This is the solver used by the integrators' initialize() methods prior to the start of a simulation.
Unlike "real" prescribed motion (which I'm working on slowly) the Constraint::PrescribedMotion has to fight equally with other constraints in the system, so it is subject to the usual assembly and velocity analysis caveats: you might have to be reasonably close to a solution to get there, e.g.
project() takes several odd arguments; you might find it easier to create an integrator and call initialize() since the integrator will know how to set up the call.
Regards,
Sherm
Prescribed motion in Simbody is currently treated exactly like any other constraint. Realizing calculates the constraint *errors*; it does not enforce the constraints (except acceleration constraints which are used to calculate the udots and multipliers).
The realize(state,stage) method takes the state as a "const" value -- it can't make state changes. For state changes you need what Simbody calls a "solver", meaning some method that takes a writable state. The solver you are looking for in this case is system.project() which takes a state that violates position and/or velocity constraints and projects it onto the position and velocity constraint manifolds. This is the solver used by the integrators' initialize() methods prior to the start of a simulation.
Unlike "real" prescribed motion (which I'm working on slowly) the Constraint::PrescribedMotion has to fight equally with other constraints in the system, so it is subject to the usual assembly and velocity analysis caveats: you might have to be reasonably close to a solution to get there, e.g.
project() takes several odd arguments; you might find it easier to create an integrator and call initialize() since the integrator will know how to set up the call.
Regards,
Sherm
- Kishor Bhalerao
- Posts: 21
- Joined: Thu Mar 13, 2008 12:52 pm
RE: Prescribed motion
Hi Sherm,
This clearly explains the results i was getting from my code. I suppose, in the current example, the easiest way for me would be to simply use state.setQ() and state.setU() directly. I should perhaps not include the Prescribed Motion constraint on the system at all since, i do not expect to realize the system to acceleration stage using simbody methods.
Thanks for your help.
Kishor.
This clearly explains the results i was getting from my code. I suppose, in the current example, the easiest way for me would be to simply use state.setQ() and state.setU() directly. I should perhaps not include the Prescribed Motion constraint on the system at all since, i do not expect to realize the system to acceleration stage using simbody methods.
Thanks for your help.
Kishor.