Implementation of Joints system (interact. generation) as a Method

[Sahil Shekhawat]

HI everyone,

While discussing unit tests for the system of Joints system, Jason suggested that we can also implement it as a Method like KanesMethod and LangrangesMethod. It will be different from other methods as the kinematics will be defined inside this method and will use other methods to finally compute the eom. As its advantage, pydy.System will not have to change. It will still be initialized by a method class.

But we also plan to add method to add visualization along with this implementation. It will add pydy.viz shapes to the bodies but we can not add it inside the JointsMethod, if we choose to implement it. We would want it to be symbolic only and system is better for implementing it (symbolic + numeric) and our current implementation changes pydy.System.

Please share your suggestions as to which way would be better, it will help us a lot.

Thank you,

[TARUN GABA]

JointMethod is a good idea, but it should be independent of System.

Going by the similarity,  JointMethod should be completely symbolic, like Kanes/Langranges.

Also System should be able to generate visualizations, because that was the motive it was created in the first place:
1. generate eoms
2. integrate numerically
3. generate visualizations

the first part of it (generate eoms) can be refractored to include JointMethod.
Rest all should work as same (ideally).

Thanks
  Tarun Gaba

--
You received this message because you are subscribed to the Google Groups "PyDy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pydy+uns...@googlegroups.com.
To post to this group, send email to py...@googlegroups.com.
Visit this group at http://groups.google.com/group/pydy.
For more options, visit https://groups.google.com/d/optout.

[Sahil Shekhawat]

We want to include visualization on a per-body basis, ie. user can define the shapes associated with a body and their orientation as body.addDecoration(Cylinder) 

To do this way, we have to do this in jointsMethod.

[Jason Moore]

What if the Method class can optionally supply the RigidBodies and Particles to System? Then you can have the optional visualization decoration methods on System.

Jason
moorepants.info
+01 530-601-9791

[Jason Moore]

Another question that I'd like some input on related to this, is whether we are "shooting ourselves in the foot" trying to keep a hard line between symbolics and numerics. Right now it is really nice that you can just work in symbolic land, as that may be all you ever want to do. I'd personally like to keep that dichotomy but maybe it is a big hindrance for some of the other goals.

Jason
moorepants.info
+01 530-601-9791

[Sahil Shekhawat]

>What if the Method class can optionally supply the RigidBodies and Particles to System? Then you can have the optional visualization decoration methods on System.

Yes, its a nice way to do. We have actually make body_list attribute public and system can use it. 

>"shooting ourselves in the foot" trying to keep a hard line between symbolics and numerics.

I don't think that would be a problem. I can imagine that we can separate symbolic and numeric part and I think it's a good way to do things. Generating EoM can be separated and system can use its public attributes.

[Jason Moore]

If we go the route of using Method, then this issue may need to be addressed to set the right foundation:

https://github.com/pydy/pydy/issues/83

Ideally, all Method classes would have some common attributes/methods so that they work universally with System.

Jason
moorepants.info
+01 530-601-9791

[Christopher Dembia]

Does the symbolic/numeric stuff affect the interface or just the implementation? If it only affects implementation, well that makes things cleaner.

[Jason Moore]

I think we are seeing some of the issues associated with trying to mimic Simbody's approach and trying to be able to retain fully symbolic work. So if we want an interface that is similar to Simbody's the most efficient way to get there is probably to design classes that contain symbolics and numerics. But if we want to have an interface that allows the user to work completely symbolically with the joint construction method then some things may have to be different. I'd have to think (and type) some more to put my finger exactly on these details. One example is whether you should attach values for a body's properties to a body. A Body could be a purely symbolic class (as RigidBody is now). The other is do we create Parameter classes that connect symbolic parameters in the model to numerical values and what should they be attached to? Right now, these things are not introduced until you provide numerics in System.

Jason
moorepants.info
+01 530-601-9791

[Christopher Dembia]

It might be worthwhile to find out how Sherm approached this for SD/FAST.

[Jason Moore]

Yes, I told Sahil that he should email Sherm a few weeks back.

Sahil, did you ever contact Sherm?

Jason
moorepants.info
+01 530-601-9791

[Sahil Shekhawat]

No, I didn't. Should I mail him now about symbolic/numeric separation issue?

[Jason Moore]

I think it would be worthwhile engaging Sherm. He may give some really nice insight. I'd just tell him what you are trying to do, in general, and see if he has any recommendations or could tell you how they handled this stuff in SDFast. You can mention the numeric/symbolic separation for sure.

Jason
moorepants.info
+01 530-601-9791