Getting involved with System, code generation, etc.

[Benjamin Margolis]

Hello,

I'm a graduate student who has been using Python for research on dynamics and controls for the past year or so. When I first was getting setup, I was having problems installing PyDy on my windows machine so I ended up rolling my own framework which has the primary function of taking EOMs of a plant and (callable of a) controller and simulate. I'm interested in seeing if those features could/should be integrated into PyDy or if it would be better off as a separate library. I just published my repo here: https://github.com/sixpearls/NonlinearDynamicalModelingSimulation

Like PyDy, I'm interested in the junction of the symbolic and numeric. Here are a few goals/features I have:

 - A method of "connecting" multiple systems and/or callables into a single ode function. Ideally all symbolic expressions could be passed through a code generator together so CSE and other efficiencies could be used. I'm thinking of this as a text-based simulink, where each system/callable is a "block" and the user simply defines the connections. I would also like it if systems had output expressions which could be used for connections. Some cleverness of not computing unused connections until after integration would also be possible.

 - A simulation function that handles discrete time systems and controllers, and discrete/continuous time hybrid systems i.e., a discrete time controller on a continuous time plant. I found that having callbacks and way of passing extra information back and forth was helpful for developing algorithm-based controllers which are computationally expensive.

 - a way of handling stochastic inputs/specified signals

 - Incorporating some classical nonlinear control design/analysis. At this point, I'm mainly thinking of describing functions and phase portraits. But perhaps moving linearization from KanesMethod might make sense, too.

If any of these seem like they might be a good fit for PyDy, I'd love to figure out how I could start implementing them and contributing to the project. If not, I can keep those features in a separate project. Either way, I would be interested in leveraging some of the system and code generation modules as it's a bit more sophisticated than what I have. However, in order to use it I would want de-couple System from the eom_method framework.

Based on https://github.com/pydy/pydy/issues/83, it seems there was an interest in decoupling from the KanesMethod. Is there any reason not to decouple from all methods and just accept the RHS and optional mass matrix as inputs? I would think this kind of decoupling would be ideal, but I couldn't figure out where (if at all) the *Method was being used apart from the RHS and mass matrix expressions.

Thanks for reading. I look forward to your feedback!
Ben Margolis

[Jason Moore]

Ben,

All this sounds good. Some comments below.

Jason
moorepants.info
+01 530-601-9791

On Tue, Apr 5, 2016 at 9:55 AM, Benjamin Margolis <b...@sixpearls.com> wrote:

Hello,

I'm a graduate student who has been using Python for research on dynamics and controls for the past year or so. When I first was getting setup, I was having problems installing PyDy on my windows machine so I ended up rolling my own framework which has the primary function of taking EOMs of a plant and (callable of a) controller and simulate.

If you recall the problems we'd love to have an issue report about them. PyDy is a pure Python library so it should install on any OS without a lot of trouble. We recommend installing the dependencies using your Os's package manager, a Python distribution (Anaconda, Canopy, Python(x,y), etc), or using Pip and the binary wheel format. Some of the dependencies are no fun to compile, especially on Windows.

 

I'm interested in seeing if those features could/should be integrated into PyDy or if it would be better off as a separate library. I just published my repo here: https://github.com/sixpearls/NonlinearDynamicalModelingSimulation

I think that there are likely things we'd like to include in SymPy or PyDy. It will be best if you can section out the different features and submit pull requests to the respective repo (pure symbolic stuff should likely go into SymPy and things that aren't should go into PyDy). This can be a function by function, class by class, module by module depending on how big the things you have are. We like "atomic" pull requests so they are easier to digest and review. If you list your current features we can give you a hand thinking about the best PRs to make.

 

Like PyDy, I'm interested in the junction of the symbolic and numeric. Here are a few goals/features I have:

 - A method of "connecting" multiple systems and/or callables into a single ode function. Ideally all symbolic expressions could be passed through a code generator together so CSE and other efficiencies could be used. I'm thinking of this as a text-based simulink, where each system/callable is a "block" and the user simply defines the connections. I would also like it if systems had output expressions which could be used for connections. Some cleverness of not computing unused connections until after integration would also be possible.

The is a great idea and will be very powerful. I have a student here at UCD that wants to implement a Bond Graph class hierarchy with the symbolics that would allow for this kind of system building. Maybe you two could work together. Another thing to look at here is the JModelica project. The modelica language allows you to describe systems like this and then generate code from the descriptions. We could build something that outputs modelica models from SymPy objects and expressions and then use the many tools available to simulate modelica models.

 

 - A simulation function that handles discrete time systems and controllers, and discrete/continuous time hybrid systems i.e., a discrete time controller on a continuous time plant. I found that having callbacks and way of passing extra information back and forth was helpful for developing algorithm-based controllers which are computationally expensive.

Sounds good. We have a simple callback mechanism in the ODEGenerator class that allows you to write arbitrary Python functions that describe your controller output given the system state but there is a lot of room for improvement there. As for simulating discrete time systems, we don't have an canned stuff built in for that. This would be welcome too. It'd be nice to convert systems that are described symbolically with SymPy objects to a discrete version using different transforms and then have a simulation framework that can handle those. The Python control library has discrete transfer functions, it would be cool to generate them symbolically with SymPy and then output Python-Control objects for use in their simulation tools.

 

 - a way of handling stochastic inputs/specified signals

Sounds useful.

 

 - Incorporating some classical nonlinear control design/analysis. At this point, I'm mainly thinking of describing functions and phase portraits. But perhaps moving linearization from KanesMethod might make sense, too.

Sounds good too. We should think about how to leverage and connect python-control, pydy, sympy, etc. There are a lot of tools but they aren't all quite connected. PyDy could be the connector or we can get another package started. I'm happy to have this stuff start off in PyDy since we have some developers and the testing, docs, and community framework setup, etc.

 

If any of these seem like they might be a good fit for PyDy, I'd love to figure out how I could start implementing them and contributing to the project. If not, I can keep those features in a separate project. Either way, I would be interested in leveraging some of the system and code generation modules as it's a bit more sophisticated than what I have. However, in order to use it I would want de-couple System from the eom_method framework.

One of the summer projects we will have for GSoC this year is to create a more robust EOMMethod class for handling the symbolic definitions of systems described by ODEs and DAEs. The PyDy System class should be able to consume this general form of the symbolic dynamical equations (doesn't have to be limited to multi-body systems). The functionality of the System class is summed up in: converts symbolic descriptions of ODE/DAEs into fast numerical functions, allows for easy simulation, plotting, and other typical numerical analyses. We could certainly separate this into something that converts symbolic ODE/DAEs into numeric versions and then the System class would consume the output of that to allow for numerical analyses work. Let us know more how you'd like things structured and we can think about how to separate things.

 

Based on https://github.com/pydy/pydy/issues/83, it seems there was an interest in decoupling from the KanesMethod. Is there any reason not to decouple from all methods and just accept the RHS and optional mass matrix as inputs? I would think this kind of decoupling would be ideal, but I couldn't figure out where (if at all) the *Method was being used apart from the RHS and mass matrix expressions.

See above, yes we have some plans to support more general ODE/DAE descriptions but no current plans to remove the knowledge of the symbolics from System. Although we are all ears for proposals.
 

Thanks for reading. I look forward to your feedback!
Ben Margolis

--
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 https://groups.google.com/group/pydy.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Margolis]

Hi Jason,

Thanks for your feedback! I'm glad these features sound like they might fit. As I mentioned, most of my interests are right at the juncture of the symbolic and numeric. I think most of what I want to work on will involve numerics, so I'll PR into PyDy. Your guideline also fits with my initial impression that most of this work should go into PyDy. I'm also familiar with the discrete feature per PR approach; these emails discussing multiple features are just to get a sense for a potential roadmap.

I'm definitely interested in some of the asides you mentioned, like the bond graph work and leveraging other dynamics and controls libraries. Right now, I'm interested in developing features in the next few weeks that I can use to help finish my master's thesis. To do that, I think we'll need to clear up the vision for the System class, the EOMMethod class, and the work for the GSoC student.

I generally like the current implementation of System as a consumer of symbolic expressions that helps in numeric situations. What isn't clear to me is why System is holding a reference to an EOMMethod (currently only KanesMethod) instance. It seems that the *Method class is primarily a wrapper around the RHS, mass matrix expressions and state, constant, and specified variables. I think it would be better to decouple System from *Method. Then a System can be created from *Method, hand-written symbolic expressions, or any other modeling tools that can formulate the right symbolic expressions (e.g., the hypothetical bond graph tool). This would also allow System to support symbolic expressions that can't be modeled using an EOMMethod (which may or may not actually be a problem).

It does make sense to me that PyDy would provide a helper function to construct System instances from EOMMethod (or other tools PyDy wants to support). With the decoupling I'm proposing, these EOMMethod helpers would take a *Method, identify the state variables (i.e., generalized coordinates and speeds) and form the proper RHS and mass matrix expressions to construct a System. I couldn't find the GSoC application, but I'm hoping this decoupling would be compatible with current plans.

Best,
Ben

[Jason Moore]

Ben,

I think you have the essentially have the same idea we've discussed for improving the *Method classes and their integration with System. The current plan from us was:

Create a EoMMethod class which houses the symbolic data: states, specifieds, constants, mass matrix, right hand side, etc. This class can be populated manually using any symbolic expressions that you derive.

Subclass KanesMethod, LagrangesMethod, and any other future automated method class from EoMMethod so that they all have a common set of attributes and methods.

The System can consume any *Method class and be able to do the right thing. The current System class was written by Chris and I over a few days to support some of the visualization features for one of the GSoC projects. We basically got it in shape with the minimum set of features for that use case.

I'd be fine with some other decoupling plans, but we need to deprecate things properly and decide if major change is worth the deprecation headache.

Jason
moorepants.info
+01 530-601-9791

[Jason Moore]

Maybe we need a SymbolicDynamicSystem class or SymbolicODE SymbolicDAE. A class that stores symbolic descriptions of system that is described by ODE/DAEs would probably be helpful. It could house all methods that do symbolic operations on these equations but have some higher awareness than simply a sympy expression or tuple/dict of sympy expressions. SymPy has an ODE module that solve linear ODEs, maybe some more general abstractions like those would help.

Jason
moorepants.info
+01 530-601-9791