physics.mechanics code output

[gadha007]

As I'm going to begin work on the code output part of the mechanics there are some questions that we (i.e. the people who have worked on mechanics) have that we were hoping people could comment on-

1.) What ode integrator and languages combinations do people commonly use or you would want support for.

2.) From our perspective, the equations that we generate have three kinds of quantities- states, forcing functions and other parameters. Are there any other quantities that would need to be handled specially?

[krastano...@gmail.com]

> 1.) What ode integrator and languages combinations do people commonly use or
> you would want support for.

I would gues that this is one obvious choice: scipy.integrate.odeint

However, whatever you choose, check out all the discussions about
lambdify. It would be certainly nice to have actual code generation,
not hackish monstrosities like lambdify.

[Jason Moore]

On Thursday, August 2, 2012 4:12:58 PM UTC-7, gadha007 wrote:

As I'm going to begin work on the code output part of the mechanics there are some questions that we (i.e. the people who have worked on mechanics) have that we were hoping people could comment on-

1.) What ode integrator and languages combinations do people commonly use or you would want support for.

SciPy must be supported as it is written in the same language and most popular. I'd say that supporting both integrate.odeint & integrate.ode is important, especially if the user needs to use a particular ode method function.

There are also an assortment of other python packages that folks use to integrate ode's. It would be particularly important to support at least one that can handle events, as scipy does not have that functionality (although there is a non-merged PR for lsodar support floating around). Some of the popular ones are:

- PyDSTool
- OpenOpt
- Assimulo
- More on http://www.scipy.org/Topical_Software

If you want to draw from a large use base, I believe you should support Matlab code generation (and defacto Octave and SciLab).

Then for the folks who need speed, complied languages like C, C++, Fotran, etc are critical. Supporting Cythonized routines is also a way to support speed without straying too far from pure python.

The design of the code output functionality should be able to store the integrable equations of motion in a generic format and it be easy for people to write output parsers for their language/function design of choice. I also believe that it would be useful to have a "generic" output that simply gives a text file with the rhs and output equations that is language agnostic (although you can give options for operators i.e. ** vs ^). This generic output can be used to populate custom functions with any language that isn't supported by a current output parser.

I sorta imagine each method class (Kane, Lagrange, etc) having a output method that supply's a standard formatted EoM's to a code output class which has a ton of output parsers capable of writing different language source files.
 

2.) From our perspective, the equations that we generate have three kinds of quantities- states, forcing functions and other parameters. Are there any other quantities that would need to be handled specially?

I'd like to see an easy way to swap out input/forcing functions to a system. Say the code_output generates a nice python class, it'd be nice subclass it and redefine the .input() method or some other clever way to run simulations with different inputs.

You need to handle output quantities, general functions of the states that can supply extra information (different views) of the system.

Make it easy to swap out parameter values.

Jason