How would you develop the complex choreography for The Fountains of Bellagio without getting wet?
This video associated with this entry has an elegant description of how you might go about constructing a simulation for this very purpose.
I’m not one to get too excited, but this submission really struck a chord with me, and reminded me how we can do some pretty cool things with Simulink.
I spend most of my days working on simulations of motors and their controllers. (Actually to be honest, I spend more time managing files used for the simulation of motors than creating the simulations, but that’s a discussion for another day). It is nice to be reminded that engineers can solve some really interesting problems using tools like MATLAB and Simulink. Not that spinning motor is always dull, but it doesn’t make for very good animations.
But wait! Doesn’t the model contain 100 fountains? And there are lines going everywhere, doesn’t that make it complex?
Okay, maybe it looks complicated. I’ll address that in the last section. However I really like the approach that John and his colleagues took of breaking the hundreds of fountain jets down to a simpler problem, and used relatively simple models to describe the jet dynamics.
John and his colleagues derived a second order transfer function to represent the relationship between the force of the jet and the height of the jet above the surface of the water reservoir. In addition they calculate the force using some lumped parameter analysis to estimate the dynamics of the water pump and the jet.
Sure, one could use sophisticated fluid dynamics models to get lots more detail. But more complex models require more time to create, and generally more time to run. Why spend all of that time and energy when you can get pretty close with a far simpler set of models. Remember the fundamental law of production:
$$Time = Money$$
Simulink really offers a couple of elements that are difficult to find elsewhere.
First it provides a graphical language to lay out the relationships of the various system components.
Second it provides a means to create custom models of these components, and test the components independent of the system model.
And third, you can use MATLAB to automate the simulation and retrieve the simulation data to create custom graphics so you can describe the results to your manager or customer in a concrete fashion.
Since I often have to develop models that I share with other people, I spend a lot of time thinking about how to present models and code in a way that’s easy to understand.
There are a number of features that could potentially make the larger system model easier to look at. However, each has its trade-off.
- For-Each subsystem to replicate instances of the same system component for different inputs.
For example, you could have just three blocks representing the different types of fountain jets. Each block would represent multiple instances of each type of jet.
The tradeoff is you now have to understand the semantics of this particular type of subsystem in Simulink. It makes the diagram more abstract, so while it might look prettier, it could be more difficult to understand, especially if your audience isn’t familiar with Simulink.
- Signals as vectors allow you to concatenate information that is travelling to the same location in a single line.
This makes most sense in the context of the For-Each subsystem where each element in the signal vector represents an input to a different instance of the jet model.
Again the trade-off is neatness for abstraction. You have fewer lines in the diagram, but each line contains more information that can be difficult to surmise just by looking at the diagram.
- Stateflow to develop the sophisticated logic required to turn various jets on and off at specific intervals.
Stateflow is a graphical way to represent the flow of logic. It includes the ability to manage the particular state of a system (such as a switch which can be on or off) as well as the conditions to transition between the various states (turn switch on when it is dark). Those conditions can include the notion of time as well (turn on the switch after 5 seconds).
In this case I believe the trade-off might be reversed from the other two suggestions. It may be easier for someone to understand the logic if Stateflow is used as it may reduce the abstraction introduced by elements like variable delays, but requires the model designer to learn another graphical language to develop the model.
If you would like to leave any comments regarding this post, please click here.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.