Two years ago I’ve written a post on building an object-oriented multibody structure in Matlab. The project has since been sleeping, but since my experiments with Processing I decided to implement a comparable structure there. This means:
- A structure that is hopefully easy to expand and modify
- Code that is running in Java (with the possibility to port it to C++ / Arduino) that should be reasonably fast.
- A slightly modified approach compared to my original Matlab implementation (in some cases with clear improvements)
This approach allows a very elegant interface for simulation: Adding an object is just one line of code, as is simulating one timestep:
The main difficulty in object-oriented multibody simulations is managing very different needs of different software parts:
- those of a ODE solver that wants a model with a state space representation and does not care about individual objects
- those of a stack of individual objects that need to be linked to each other and do not care about a global list of state variables.
I briefly considered writing ODE solvers that accept a object-like structure instead of a state vector – but this will very likely make more advanced solvers (say those that want to calculate a jacobian matrix) rather annoying to implement. So basically I use a wrapper function dydt() and a set of arrays to linking the two.
Note that each object has each own set of state variables (the float y). In C++ this might instead be a pointer to the corresponding entry in the overall state vector – I’m not sure if this can be implemented in a comparable way in Java.
A set of additional arrays is used to assign the global state vector to each object. I felt that there are basically two options here:
- Call each object and ask it to “grab” the state variables from the global state vector (means that each object stores the corresponding index – that’s what I did in my original Matlab implementation)
- Have a global list of which object has how many state variables and push the values to them.
Here I went with option 2) since I felt that for complex models, there may probably be more objects than state variables, possibly reducing runtime overhead here. Then again I might be wrong, but I currently lack a reasonable setup to do benchmarks here.
Java makes linking objects to each other easy, each variable just points to the actual object instance (see this discussion here for a better explanation). So my spring class stores references to both masses it is connected to.
The implementation here will search for the corresponding mass objects based on their names, making model input relatively easy. The same approach is also used for passing the inital state and model parameters, with the goal of allowing model import from a text file in the future.
I’ll see where this will lead in the future. I learned a lot with the implementation here and I feel that this may be robust enough to implement further object types and getting a library of different simulation objects to choose from. Also I’m considering porting this whole thing to C++.
You can find my code here on Github.