Separating symbolic stuff as JointsMethod from InGen

14 views
Skip to first unread message

Sahil Shekhawat

unread,
Jun 30, 2015, 3:17:42 PM6/30/15
to py...@googlegroups.com
Hi everyone,
Jason, Tarun and myself have been discussing to separate symbolic and numeric stuff and implement a JointsMethod in SymPy. All Joints will be implemented in SymPy itself along with new methods in RigidBody and Particle class to work with Joints classes. Moreover, jointsMethod will take rigidbodies, Particles and Joints as input and use other methods to calculate EoM.
The advantage of doing that is that we don't have to change system at all. It can be passed as a method to system and all of the current visualization stuff will work with it. This way symbolic stuff is very well separated from numeric stuff. How you guys think about this implementation?

After implementing symbolic stuff we will need to add numeric values to symbols in system as well, which we are thinking of how we would do it but nonetheless we would like to hear your thoughts on this. 
Thanks
Sahil

Chris Dembia

unread,
Jun 30, 2015, 3:25:17 PM6/30/15
to py...@googlegroups.com
I know very little about what's going on. The idea of separating symbolics from numerics in the implementation sounds really good. What is most important is how users' code will look. If users want to specify numeric values at the same time they are defining Joints and Bodies, then we should make it possible. If we think it's fine for users to define numeric values later on, then we can allow that.

--
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

unread,
Jun 30, 2015, 3:29:49 PM6/30/15
to py...@googlegroups.com
That's exactly the issue that we are facing. We want to separate symbolic stuff but also want to give user an option to set numeric values at the time of creation of joints. 
But i can say that after separating symbolic things we cannot give user any option to set numeric values at the time of creation.

Sahil Shekhawat

unread,
Jun 30, 2015, 3:31:35 PM6/30/15
to py...@googlegroups.com
What we are thinking is to give an option in system after passing JointsMethod. We can build a class which will add default values smartly if no values are passed and user can change it as well.

Jason Moore

unread,
Jun 30, 2015, 3:57:02 PM6/30/15
to py...@googlegroups.com
We could potentially add some optional attributes to RigidBody, Joint, etc that hold the numeric values of various symbols. This is fine, but they need to be optional and the Methods classes shouldn't care about them at all.

Christopher Dembia

unread,
Jul 1, 2015, 12:57:42 AM7/1/15
to py...@googlegroups.com
I talked to Sherm about this today (Sahil, FYI, Sherm works on the floor below mine). He had some useful things to say.  I suggest you guys check out the input format for SD/FAST. Here is the SD/FAST manual: https://nmbl.stanford.edu/classes/me382/pdfFiles/sdman.pdf.

Sherm said the SD/FAST input file could either take numeric values or use symbols. He said it would look something like this (if the input were XML):

<Body>
   <mass>??</mass>
   <mass_center>0 3 1</mass_center>
</Body>

That is, you could choose, for each quantity, whether to specify the numeric values immediately, or to use symbols and specify their values later (denoted by using ??).

**The important point**: allowing people to specify numbers immediately allowed for optimizations when generating symbolic code that, Sherm said, could lead up to a 3x speed up.

Jason Moore

unread,
Jul 1, 2015, 1:36:21 AM7/1/15
to py...@googlegroups.com
There is nothing stopping anyone from using numeric values with our SymPy objects as it is now. Instead of a*N.x+b*N.y just use 1*N.x+1*N.y. But if you do that, your generated code has harded coded values for the parameters and you can't change them without generating new code. It'll work fine if you do this, but it just will not allow the user to change parameters easily after the code is generated. I can imagine that there would be speed ups.

I think the issue we have is more about how and when to we provide both the symbolic value and an initial numeric value. Right now this happens at the System class level, but it could happen at the Joint class or the Body class, etc.

Christopher Dembia

unread,
Jul 1, 2015, 1:52:19 AM7/1/15
to py...@googlegroups.com
I think the issue we have is more about how and when to we provide both the symbolic value and an initial numeric value.

What do you think about letting the user decide for each individual variable? e.g.

class RigidBody:
    def __init__(self, mass=None, mass_center=None, …):
        “””None indicates use symbolic.”””

Then you could do a mix:

rb = RigidBody(mass=5.3)

I think you already stated this idea in some form, so I don’t think I’m saying anything new.

It sounds like the real challenge is just figuring out how to design classes so that the interface above is possible. One option is to create a new abstraction for quantities that are either symbolic or numeric: HybridQuantity, or HybridSymbol. Then, `mass`, and `mass_center` would both be of type `HybridQuantity`. Such a class could handle all the complexity of figuring out whether the quantity is symbolic or numeric, and the RigidBody class could not worry about it.

Sahil Shekhawat

unread,
Jul 3, 2015, 10:26:41 AM7/3/15
to py...@googlegroups.com
I totally agree with the approach that Jason and you talked about and I want to point out that this is already used e.g. for points we can do point.set_vel( 10*frame.x )
Lets give user a choice to use whatever they think is apt numeric value or symbol. As soon as I am finished writing main unit tests for the API, I am going to quickly create a sample implementation .

Sahil Shekhawat

unread,
Jul 9, 2015, 8:43:03 AM7/9/15
to py...@googlegroups.com
Right now, there is a Body class whose instances are passed to Joints. This Body class is also supposed to contain methods like add_visualization and thus, needs to stay in PyDy where as Joints and JointsMethod will be shifted to SymPy. So, we have following options, let me know which is best:

1. Change RigidBody and Particle itself to add required attributes and keep Body class in with all remaining functionalitites in PyDy.
2. Shift Body to Sympy with everything and instead of adding visualizations right away, add them to an array and let pydy.system to handle that.

For 1 some changes needs to be done in Joints as well as in JointsMethod. currently, 2 will work wihtout any changes.
Reply all
Reply to author
Forward
0 new messages