I'm working on methods to linearize the equations of motion (EOM) generated in sympy.physics.mechanics. The goal is to have a function `linearize` that can take in a `KanesMethod`, `LagrangesMethod`, or any other system of equations (and ideally a matrix of equations, I think that can work too), and spit out the linearized system. Here are my thoughts on the interface:
*1.) A `Linearizer` Class:* This will hold the generalized form of the nonlinear equations. All systems should be describable by the Kinematic Differential Equations, Dynamic Differential Equations, and Configuration, Motion, and Acceleration Constraint equations. Or lack of these. Once in this form, a method `linearize` or `linearize_about`, or something else (see below) will actually perform the calculation. *2.) A `linearize` function:* This will wrap the creation and use of the `Linearizer` class. Will sub out to various methods to put to the system into the generalized form in `Linearizer`, have it perform the linearization, and return the results. *3.) Class methods for KanesMethod and LagrangesMethod that wrap the `Linearizer` class and do the same as above.* ***Questions:*** *1.)* In general the linearized EOM are only valid if the point they are linearized about satisfies all the constraints. Should we check for that? I think we should, but it gets kind of tricky if symbolic linearization is performed. For example, suppose we have a constrained system with 5 generalized coordinates (qs) and 4 generalized speeds (u). The system only has 2 DOF, so it has constraint equations that relate the dependent (q3, q4, q5, u3, u4) to the independent (q1, q2, u1, u2). Thus, any point is "fixed" by choosing q1, q2, u1, u2; the remainder are solved for by the constraint equations. If linearization is purely symbolic, the dependent variables must satisfy these equations, even if they're not expressly stated in the final form. Possible solutions: *a)* Have 'linearize' take the trim condition (point of linearization) and validate it against the constraint equations. Notify the user if it is over specified (5 values given, only 4 are free). Then perform the linearization. This issue with doing it this way is that checking symbolically may be difficult at times, and users may also wish to solve for the linearized system in a completely generalized way (i.e. sub in a point after the fact). The benefit of subbing beforehand though is that with fewer symbols, the computations will go faster. *b)* Always perform completely symbolic. No checking. Provide composed function in output to validate before subbing in. Use would be: linearized_eom, validator = linearize(eom, ...) trim_conditions = something if validator(trim_conditions): linearized_eom.subs(trim_conditions) Benefits of doing it this way are that the linearization is done only once, and values are substituted in later. However, the initial linearization will be more time consuming than if values were presubbed. *c)* Similiar to b), but return an object `LinearizedEom`, with an `about` method, that validates, and then subs in values if they pass. Issues with this are the linearized system isn't in matrix form (although a `to_matrices` method could be provided). Same issues as b) as well. *2.)* Using the same example as above, suppose the user knows they want to linearize about q1 = 2, q2 = b (some constant), u1 = u2 = 0, and the derivatives all to be 0 (equilibrium condition). This would constrain the remaining generalized coordinates and speeds to some value. One thought would be to have this specified in a dictionary, and try to solve for any terms that weren't submitted. If solve can find the missing ones, then proceed with the linearization/validation/substitution (depends on decision from above). Otherwise through an error that the trim condition was over/under specified. Or would it be better for the user to have to solve for a complete trim condition? This would be simpler, and may be less surprising. If it did solve for the condition, the result would have to be made available to the user so they knew what it was linearized about. ------- Let me know what your thoughts are on these, and if you have any questions or suggestions for improvements. -Jim -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d19e168e-6e18-4640-b715-07442845f880%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.