On Wednesday, August 1, 2012 9:31:52 AM UTC-5, Jason Moore wrote: > > I'm of the opinion that you should supply all the necessary information in > the __init__ method of the Lagrange versus having all the setter methods. > Stefan points this out too. The __init__ method should require the bare > minimum arguments (lagrangian, generlized coords) and all the others be > optional, probably as keyword arguments. It can be handled with something > like __init__(lagragian, coordinates, **kwargs). This way the user is > forced to supply all necessary items to the class on it's creation and it > is immediately useful. I've always found it odd that the current Kane > formulation calls for you to create and empty useless object and it only > becomes useful after calling all the extra setter methods.
> Following that, the user should call the .lagrange_equations() method with > no argmuments to do the computation (arguments to this method should > reflect options for the computation like with or without simplification > etc), which has the potential to take a long time. Once these equations are > stored in the class, seems like mass_matrix(), forcing() etc should be > methods not attributes, as they are doing some computing too, i.e. picking > off coefficients and parsing Lagrange's equations. > What methods do you plan to use for the rhs method? I could imagine this > taking arguments for different types of solving methods. > I didn't really think about using different methods actually. I should explore this a little more. > Here is an example of how I imagine the class generation: > > # build the object > lag = Lagrange(lagrangian, coordinates, constraints=con, forces=forces, > frame=N) > > # compute the equations > lag.lagrange_equations(simplify=True) > > # extract the mass matrix > m = lag.mass_matrix() > > # find the right hand side > rhs = lag.rhs(method=guass) > > The preceding seems cleaner to me and more intuitive for the user > following typical standards from other popular python software. > Yup. I agree it is simpler and the changes you suggest are reasonable and sensible to me too. Apologies for repeating myself from above but the only reason I do this is for the sake of uniformity. > Jason > > On Wed, Aug 1, 2012 at 5:21 AM, gadha007 <[email protected]> wrote: > >> I have been working on the addition of lagrangian mechanics to >> sympy.physics.mechanics and I was hoping to get some input, suggestions or >> recommendations on it. Equations of motion are generated using Lagrange's >> equations of the second >> kind<http://en.wikipedia.org/wiki/Lagrangian_mechanics#Lagrange_equations_of_the_second_kind> >> and >> this is what the procedure looks like- >> >> 1.) Upon having done the kinematics and subequently developing a >> lagrangian, the user initializes the lagrange object where the lagrangian, >> L, is the argument. >> >> l = Lagrange(L) >> >> 2.) The user then supplies a list of generalized coordinates using the >> coords method. >> >> l.coords(list_of_gen_coords) >> >> 3.) This is followed by a constraints method where the user can supply >> nonholonomic equations (i.e. velocity constraints) and/or differentiated >> holonomic equations (i.e. differentiated configuration constraints) if >> there are any. By default the constraint equations are set to none. >> >> l.constraints(list_of_coneqs) >> >> 4.) With this done, the user can then call the method >> 'lagranges_equations' where (s)he can supply the non-conservative forces >> (or moments due to non-conservative), if any, along with a reference frame. >> In this way the effect of non-conservative forces such as friction can be >> accounted for. This generates a column vector of the dynamical equations >> using lagrange's method. >> >> l.lagranges_equations(forcelist, frame) >> >> 5.) a.) Following this the user also has the option to either look at the >> mass matrix (i.e. coeffecients of the acceleration terms in the dynamical >> equations) and the forcing terms (i.e. all the other terms in the ) from >> the dynamical equations separately using the 'mass_matrix' and 'forcing' >> methods. >> >> l.mass_matrix >> >> l.forcing >> >> 5.)b)The user also has the option to look at the mass matrix and forcing >> matrix augmented with the appropriate parts of the differentiated >> constraint equations respectively. These methods are called >> 'mass_matrix_full' and 'forcing_full'. >> >> l.mass_matrix_full >> >> l.forcing_full >> >> 5.)c) And finally the user can call the 'rhs' method which essentially >> solves the lagrange equations by multiplying the inverse of >> mass_matrix_full and the forcing_full. >> >> l.rhs >> >> let me know if you have any recommendations with respect to names of >> methods or anything else at all. >> >> Thanks >> Angadh >> >> >> >> > > > -- > Personal Website <http://biosport.ucdavis.edu/lab-members/jason-moore> > Sports Biomechanics Lab <http://biosport.ucdavis.edu>, UC Davis > Davis Bike Collective <http://www.davisbikecollective.org> Minister, > Davis, CA > BikeDavis.info > Google Voice: +01 530-601-9791 > Home: +01 530-753-0794 > Office: +01 530-752-2163 > Lab: +01 530-752-2235 > > > > On Wednesday, August 1, 2012 9:31:52 AM UTC-5, Jason Moore wrote: > > I'm of the opinion that you should supply all the necessary information in > the __init__ method of the Lagrange versus having all the setter methods. > Stefan points this out too. The __init__ method should require the bare > minimum arguments (lagrangian, generlized coords) and all the others be > optional, probably as keyword arguments. It can be handled with something > like __init__(lagragian, coordinates, **kwargs). This way the user is > forced to supply all necessary items to the class on it's creation and it > is immediately useful. I've always found it odd that the current Kane > formulation calls for you to create and empty useless object and it only > becomes useful after calling all the extra setter methods. > > Following that, the user should call the .lagrange_equations() method with > no argmuments to do the computation (arguments to this method should > reflect options for the computation like with or without simplification > etc), which has the potential to take a long time. Once these equations are > stored in the class, seems like mass_matrix(), forcing() etc should be > methods not attributes, as they are doing some computing too, i.e. picking > off coefficients and parsing Lagrange's equations. > > What methods do you plan to use for the rhs method? I could imagine this > taking arguments for different types of solving methods. > > Here is an example of how I imagine the class generation: > > # build the object > lag = Lagrange(lagrangian, coordinates, constraints=con, forces=forces, > frame=N) > > # compute the equations > lag.lagrange_equations(simplify=True) > > # extract the mass matrix > m = lag.mass_matrix() > > # find the right hand side > rhs = lag.rhs(method=guass) > > The preceding seems cleaner to me and more intuitive for the user > following typical standards from other popular python software. > > Jason > > On Wed, Aug 1, 2012 at 5:21 AM, gadha007 <[email protected]> wrote: > >> I have been working on the addition of lagrangian mechanics to >> sympy.physics.mechanics and I was hoping to get some input, suggestions or >> recommendations on it. Equations of motion are generated using Lagrange's >> equations of the second >> kind<http://en.wikipedia.org/wiki/Lagrangian_mechanics#Lagrange_equations_of_the_second_kind> >> and >> this is what the procedure looks like- >> >> 1.) Upon having done the kinematics and subequently developing a >> lagrangian, the user initializes the lagrange object where the lagrangian, >> L, is the argument. >> >> l = Lagrange(L) >> >> 2.) The user then supplies a list of generalized coordinates using the >> coords method. >> >> l.coords(list_of_gen_coords) >> >> 3.) This is followed by a constraints method where the user can supply >> nonholonomic equations (i.e. velocity constraints) and/or differentiated >> holonomic equations (i.e. differentiated configuration constraints) if >> there are any. By default the constraint equations are set to none. >> >> l.constraints(list_of_coneqs) >> >> 4.) With this done, the user can then call the method >> 'lagranges_equations' where (s)he can supply the non-conservative forces >> (or moments due to non-conservative), if any, along with a reference frame. >> In this way the effect of non-conservative forces such as friction can be >> accounted for. This generates a column vector of the dynamical equations >> using lagrange's method. >> >> l.lagranges_equations(forcelist, frame) >> >> 5.) a.) Following this the user also has the option to either look at the >> mass matrix (i.e. coeffecients of the acceleration terms in the dynamical >> equations) and the forcing terms (i.e. all the other terms in the ) from >> the dynamical equations separately using the 'mass_matrix' and 'forcing' >> methods. >> >> l.mass_matrix >> >> l.forcing >> >> 5.)b)The user also has the option to look at the mass matrix and forcing >> matrix augmented with the appropriate parts of the differentiated >> constraint equations respectively. These methods are called >> 'mass_matrix_full' and 'forcing_full'. >> >> l.mass_matrix_full >> >> l.forcing_full >> >> 5.)c) And finally the user can call the 'rhs' method which essentially >> solves the lagrange equations by multiplying the inverse of >> mass_matrix_full and the forcing_full. >> >> l.rhs >> >> let me know if you have any recommendations with respect to names of >> methods or anything else at all. >> >> Thanks >> Angadh >> >> >> >> > > > -- > Personal Website <http://biosport.ucdavis.edu/lab-members/jason-moore> > Sports Biomechanics Lab <http://biosport.ucdavis.edu>, UC Davis > Davis Bike Collective <http://www.davisbikecollective.org> Minister, > Davis, CA > BikeDavis.info > Google Voice: +01 530-601-9791 > Home: +01 530-753-0794 > Office: +01 530-752-2163 > Lab: +01 530-752-2235 > > > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/1aUMs73C9vcJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
