While the idea of a System class is initially appealing, there could be some serious negative implications of attempting this.
For multibody systems, there can be a large number of internal forces in contacts and joints (non-contributing forces). With Kane's Method or Lagrange's Method, you do not need to consider these. However, with the Newton-Euler method, these forces need to be included. If we were to allow for a class which took in a system definition and could return equations of motion using a variety of methods, I think bad things could happen. One example would be people forming their system with Lagrange's (or Kane's) Method in mind, and do not include internal forces. If they then generate equations with one of those, and with the Newton-Euler method, the equations will not match (the latter will be wrong). Alternatively, the user could be forced to include all of these forces somehow, which would negate some of the advantages of the other methods. In any case, I don't think it's a good idea for a class to return both correct and incorrect equations depending on what Method is used. I'm also not sure if code duplication is a major concern. People who use each of these methods have their own conventions, notations, and ways they like to represent their systems. For example, Kane's Method uses generalized speeds, which are not necessarily compatible with Lagrange's Method. I would imagine making one class which had to handle all of these potentially different use cases would have more code (which would be more complicated) than 3 separate classes. I'm not saying that a System class is a bad idea, but I think it requires more consideration than just using one class to define dynamic systems and having multiple equation output methods. Perhaps an useful alternative would be to ensure that the classes for each Method have interfaces which are as simple and consistent as possible? -Gilbert On Apr 3, 9:18 am, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le lundi 02 avril 2012 à 13:23 -0700, Luke a écrit : > > > > Did you see my email about the Euler-Lagrange equations of motion that > > > I sent earlier today? One important point is that there is absolutely > > > no reason to have a custom Lagrangian class. You can just build the > > > Lagrangian as a standard sympy expression. > > > One reason to have a custom Lagrangian class is that it helps keep > > track of systems where you have a large number of > > particles/bodies/constraints/interacting forces. For simple systems > > you can surely write the Lagrangian in a line or two, but for more > > interesting systems, it becomes onerous and error prone to do this > > "manually". Having a class which allows you to pass it a list of > > particles/bodies, and the forces/torques acting on them, as well as > > any kinematic constraints that may be present, greatly simplifies the > > work the user must do and reduces the likelihood of making a mistake. > > These are reasons to have a System class, with method(s) to create a > Lagrangian. > > > I see many reasons to have a custom Lagrangian class. > > I don't see how it would help. I think that it might rather cause code > duplication and confuse the notion of what a Lagrangian is. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
