API Design (Interactive Generation of System)

25 views
Skip to first unread message

Sahil Shekhawat

unread,
Jun 6, 2015, 1:30:19 PM6/6/15
to py...@googlegroups.com
Hi everyone!

I am working on the API design for the generation of system using joints. We have two choices to implement the API

  1. We can implement an API using new individual classes to users. Its advantage is that users will have exact classes to use. He will not have to dig into classes to find methods and a new user can easily find a way into .This kind of implementation is somewhat similar to what Simbody does. Example: I have created a working example . It generates equations of motion of a simple pendulum in just 5 lines using Pin joint. The code base lives here: https://github.com/sahilshekhawat/pydy/tree/interactive_generation_of_system_gsoc_15 . Its in  pydyIngenExample.py .In the example I have used visualisation code from our double_pendulum example to visualise it form the EoMs  but it will be replaced with an "addDecorator" method and will integrate with our current visualisation.. As you guys can see I have new classes for RigidBody, System etc and they play really well together but its disadvantage is that we have many redundant classes though we can always extend this method into specific classes of Joints and Forces.
  2. Secondly, we can extend our current classes and present new functionalities as methods. They might not play very well but they will integrate well within our current codebase. i have not worked my way into this method but this surely is possible. As, classes like RigidBody and Particle can easily be extended to include the functionalities provided by the new classes. This might break some backward compatibility.
Please spare some time to give which way you think is better. It would really help.
Thanks

Christopher Dembia

unread,
Jun 7, 2015, 1:11:51 PM6/7/15
to py...@googlegroups.com
I favor option 1. It will be much clearer to implement, and it will be much easier to implement correctly. As you have already done, you will be using a separate module and so name conflicts aren’t much of an issue. Down the road, we can investigate if integrating the two API’s is worthwhile.


Now, it’s possible that “System” can be integrated with your new work. E.g., LinkageSystem/MultibodySystem is a subclass of System.


I don’t know if I like the “ingen" module name though. I didn’t know what it meant at first. I’d prefer a single word without an abbreviation.


--
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 7, 2015, 1:23:37 PM6/7/15
to py...@googlegroups.com
Thats what I am thinking. This interface is clean, clear and easy to implement. Thanks for your views.
Also did you saw my implementation of PinJoint? As joints will actually add constraints and velocities, we can support changes on the basis of those velocities and points. 

I am not at all good at naming. Let me know if you have anything in mind.
Thanks again

Christopher Dembia

unread,
Jun 7, 2015, 1:55:38 PM6/7/15
to py...@googlegroups.com
Just briefly. Looks good. You should create WIP PR’s often and solicit feedback. Maybe you’ve already been doing this and I haven’t been paying attention. I have a little more free time now so I can try to provide feedback when I get the chance.

To me, the distinguishing factor with this API is that you describe your system as a graph/tree (e.g., joints). So maybe this could inform the naming.

Since “MultibodySystem” is your root class, you could call the module “multibody" or something.

Jason Moore

unread,
Jun 9, 2015, 12:28:44 AM6/9/15
to py...@googlegroups.com
I prompted Sahil to ask this question  the group. In general, I'd like to see something that is integrate well with what we have as opposed to a new module with new implementations of many of the classes we've already created.

Keep in mind that we are still on version 0.3.0 (I've been trying to follow semantic versioning to some degree). We don't really have to guarantee API backwards compatibility until we start moving into the X.0.0 numbers. But, if we want to keep the few users that we have, it is a good idea for us to try out best to stay backwards compatible (SymPy still hasn't reached 1.0 and they do a pretty good job of maintaining backwards comaptibily).

I'm finw tih creating a whole new module to experiment, but we can't merge it into a release unless we very explicitly call it experimental or we agree to hold some backwards compatibility with it.

I'd really like to see how we can extend out current classes. My guess is that we can use the current Particle, RigidBody, and System classes with no or minor backwards incompatibilities either as is with new methods or as at least subclasses. We will need new classes for Force, Joints, Constraints, etc. as they do not exist. I'd like to see Force/Torque in sympy.physics.mechanics.


> Down the road, we can investigate if integrating the two API’s is worthwhile.

Is that good idea? We could probably put a little thought into it now and make a reasonable decision. It is much less likely that we will merge two APIs down the road versus trying to do it now.

I also do not understand what "ingen" means. This module allows a user to construct multibody models with high level abstractions. Maybe "model_builder" or something along those lines.

I really dislike the two systems in pydyIngenExample.py. To me, there should be a single system and the KanesMethod object shouldn't even be seen by the user in a public way. I feel fairly strongly that we should extend our current System class in some way. I will also be fine with backwards incompat if we do a good job at designing the new class. But I think you can just have a system that takes None for all its args and you have to add joints, bodies, etc which will construct a Method object behind the scenes.

Christopher Dembia

unread,
Jun 9, 2015, 1:11:11 AM6/9/15
to py...@googlegroups.com
Okay you’re right, the idea of “later on we can revisit” is risky since it’s almost 100% guaranteed that no revisiting will occur.

There have been two times that I’ve tried to take someone’s code and reform it into the structure I think is best. From this, I have decided that the best workflow is:

(1) Create/brainstorm/prototype your new design separately from whatever already exists.

(2) Implement your design by morphing the existing code into what you want.

The reason for this is that I think you will end up with a subpar design if you start out with the constraints of the existing system. Also, I find it very hard to think about the new design clearly if I’m constantly bogged down with thinking about how it’ll tie in.

The reason for (2) is that it’s unreasonable to start the project from scratch; the only reasonable way to implement something is incrementally, and that’s why it’s important to start from what exists.

One reason I suggested Sahil’s option 1 is that I thought it sounded similar to what we had discussed in 2013 when I started working on that linkage module: a higher level API that simply used the lower-level API. I’m a little too far removed from Sahil’s project to know exactly how his project fits in, though.

For users, I think it’s also useful to have two very conceptually distinct API’s: the traditional symbolic API where you write the velocities of points and bodies explicitly, and the traditional numeric/tree-hierarchy API (simbody, physics engines, etc.). If both uses are in one API and the distinctions aren’t clear, it might be really difficult for me to understand as a user.

It seems like some prototyping may be necessary to see if Sahil’s option 2 is viable. That is, write an example file that assumes the additional Force, Joints, Constraints classes that are just additional to the current interface, and see if it’s clear.

Jason Moore

unread,
Jun 9, 2015, 2:00:30 AM6/9/15
to py...@googlegroups.com
I agree with all you said in principal. Maybe Sahil just needs design for the optimal case and then once there is a little more design fleshed out we can discuss how the current classes could be used.

I'm just worried that having two RIgidBodies, two Particles, two VisualizationFrames, two Systems will be super confusing. I think the optimal design is that we have for each of those. I'm willing to introduce backwards incompatibilites if we can figure out how to not have redundant classes.

Jason Moore

unread,
Jun 9, 2015, 2:12:42 AM6/9/15
to py...@googlegroups.com
Also Chris. Do you think it is a good idea to copy Simbody's abstraction verbatim? That's basically what Sahil is moving toward.

Christopher Dembia

unread,
Jun 9, 2015, 2:44:57 AM6/9/15
to py...@googlegroups.com
I don’t think we should have two Systems, or two VisualizationFrames. Maybe we need to consider inheritance for each of these types. There could be an abstract base class RigidBody, with two subclasses. I don’t know if this is a good idea. Might be good to look at the design patterns book.

Yeah maybe not verbatim, but in general I think that would be fine. At some points it’s more complex than necessary (e.g., there’s a MassProperties class that is separate from Body).

Also, be careful when it comes to frames. Simbody frames/transforms are 4x4, while Kane (reference) frames only contain rotation info. 

Sahil Shekhawat

unread,
Jun 9, 2015, 8:48:46 AM6/9/15
to py...@googlegroups.com
I can extend sympy.RigidBody class to support the functionality which this new RigidBody but I don't know if thats what we really want. The reason that I started with a separate module is to have a clear idea about how things will play out. Our current interface is great and a more mathematically inclined or advance user will want to use it. Also, in the future we wish to support many specific bodies as well which will have most of the things predefined for quick prototyping , thus, I think its best to have a separate subclass of RigidBody.

About having two systems and Visualization frame, its best to extend classes's functionalities only. It will break the backward compatibility but as Jason mentioned, "KanesMethod object shouldn't even be seen by the user in a public way", this will be at a higher layers than our current system. I can implement it that way too and at present looks like the most promising one. 

About copying Simbody's abstraction verbatim, I am not copying anything. I am just taking ideas and using them. Like Chris mentioned most of the their implementation is more complex than necessary and I cannot copy it even if I wanted to. Hence, I am just taking idea from there and implementing the best interface for us.

Jason Moore

unread,
Jun 9, 2015, 11:46:05 AM6/9/15
to py...@googlegroups.com
This is what I suggest from hearing from everyone:

1. Prototype a new RigidBody class that is seperate from sympy.physics.mechanics.RigidBody. Once we see what your class needs to do we can decide it it should be integrated more closely to the existing RigidBody.
2. Modify or extend System to work for your new module.
3. Come up with a new name for the module.
4. New classes for Joints, Forces, etc.
5. Make sure decoration methods utilize VisualizationFrame, don't create something new. In fact, VisualizationFrame is a lot like what you wnat your new RigidBody class to be. Maybe that is the class that needs to be extended to build RigidBody.

Jason Moore

unread,
Jun 15, 2015, 7:44:23 PM6/15/15
to py...@googlegroups.com
I just realized this. We have never released System in an official release, so we could do whatever we want with it until 0.3.0 comes out (which is hopefully today). Would it be worth changing System now so that it is ready to support Sahil's new design???

Chris Dembia

unread,
Jun 15, 2015, 8:09:17 PM6/15/15
to py...@googlegroups.com
If the timeline for the 0.3.0 release doesn't allow enough time for that designing, another option is to very clearly document the class as experimental, and tell users that its API may change.
Reply all
Reply to author
Forward
0 new messages