Implement (in Python) a modelling and simulation (experimentation) environment composed of:
Structure the simulator so it is easily embedded in different experimentation scripts (such as optimization).
Two prototypes of the experimentation environment must be built:
Both prototypes must allow querying of model information once a model is loaded. In particular, it must be possible to ask which are the model's variables (corresponding to names of integrator blocks) and other named blocks. This information is subsequently used to set whether these must be plotted, sent to file, both, or (by default) none of the two. Data output is generated for times communication interval apart.
At any point in time, it must be possible to save the experimentation environment's state. A small example of state saving in the form of a Python program is MyTool. Note how this is similar to the way the block diagram modelling environment passes information to the experimentation environment.
Simulation can only start once a model has been loaded, parameters and initial conditions have been set, and simulator parameters (such as step-size) have been given. The values used by the time-slicing simulator are determined by a sequence of settings (later overrides former):
Before starting the actual simulation, a check must be made for ``algebraic loops'' and blocks must be sorted. This will involve building a dependency graph. Algorithms can be found in the class transparencies.
The design and implementation of your tool must be documented. This is an important part of the deliverable. Use UML notation for your design.
Your tool must be thoroughly tested. Though you may include a test suite of your own making, you are strongly advised to use the PyUnit unit testing framework for Python. A short overview of PyUnit is found in the Python Library Reference.
Test your time-slicing simulator by means of the equation [(d2 x)/(d t2)]=-x. When x and [d x/d t] are plotted in function of one another (a phase plot), a circle should result.
The above mechanical system consists of a mass m which glides without friction over a surface. The mass is connected to a rigid wall by means of an ``ideal'' spring. In the absence of external forces, the system is in ``rest'' state and the distance of the centre of gravity of the mass object to the wall is RestLength. At any instant in time, the position (distance from the wall) of the mass is x.
An experiment has been carried out whereby the mass m was measured as well as the RestLength of the spring. m = 0.23 kg, RestLength = 0.2 m. To determine the spring constant K[kg/s2] of the ideal spring, the spring is extended to bring the mass at initial position x(t=0) with initial velocity v(t=0). x(t=0) = 0.3 m, v(t=0) = 0 m/s. (note: in many cases, in a simulation, one may have to set x(t=0) and/or v(t=0) to a small, non-zero value to avoid the simulator providing a trivial (zero) solution to the system equations).
This experiment whereby the mass is released and observed during the time interval [0,4[ yields the following measurement data xmeasured in function of time.
Note: this plot was produced in gnuplot from the xmeasured data file (after removal of the first line) with the following commands:
set xlabel "time t [s]" set ylabel "position x [m]" plot "data" title 'measured position x'
When you want a smooth curve rather than points, append with lines to the plot command. To plot column B of the data file in function of column A, append using A:B to the plot command.
With this ``noisy'' data, we need to ``estimate'' spring constant value K which, when used in a simulation of the dynamics of the system x(t) optimally ``fits'' the measured data. Notice how we start with parameter estimation directly and we skip the ``structure characterization phase'' in which the most appropriate mathematical model for this system is determined. This, as we have the a-priori knowledge that this is a frictionless system and the spring is ``ideal''.
Assignment:
Note: to give accurate results, the simulator may need a small step-size. To compare with measured data which is quite far apart, you simulator will have to implement a ``communication interval'' which allows the user to specify how often simulated values have to be output.
Whether you use a very naive exhaustive search as described above or an advanced optimization algorithm (feel free to apply some of your optimization knowledge), an optimal K will result. Simulation with the ``true'' K value will yield a graph as below.
The full analysis, design (using UML notation), implementation (in Python) and simulation results should be documented and put on the web. Explicit links to code and data must be present.
You can work in groups of upto 3 people. Individual work must be indicated. All must understand and be able to explain the whole assignment (discuss your design together before implementing and do a peer review of your code).
The due date is September 26 (before midnight).