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.
