<Martin Taylor 940413 19:00>
Bill Powers (940413.1430 MDT)
Addendum to remarks on Sequency vs Simultaneity:
In Wolfgang Zocher's "Simcon" program written for use by CSGnetters
and largely ignored (and which makes an analogue computer out of a
digital computer), pains were taken to make sure that all functions
operated effectively simultaneously. This was done by establishing
two output variables for each function: an "old" variable and a
"new" variable. On each iteration, the "old" values of output from
the various functions are used as inputs to whatever succeeding
functions they are inputs to. This results in computing "new" values
for all the functions. Then, before the next iteration, all the
"new" values are copied into the corresponding "old" values.
This is what is done in our Control Builder program as well. In addition
to the extra wrinkle Bill notes in Simcon, of using very small values of
dt, we do one other very important thing. We smooth the values, to ensure
that we don't get computational sampling artefacts (otherwise known as
aliasing). If you don't do that, you can get things happening that would
never happen in true analogue devices.
To make this scheme approximate true parallel operation as in a real
analog computer, it is necessary to use a very small value of dt for
the inter-iteration time. The reason is that effects propagate only
from the input of each function to the output of the same function
in one iteration. If the loop contains 5 functions (but no transport
lags), 5 iterations are needed for a perturbation to propagate all
the way around the loop. The value of dt must be small enough so
that total loop transit time is negligible.
Yes. The time that the compute iteration takes to work its way around
the loop can be a confounding factor in interpreting phase effects.
You want it to be very small compared to the transit lag of the
simulated analogue loop.
There's another, more important issue with sampled simulators in loops:
Aliasing. To avoid aliasing, you must sample fast enough that you get
at least TWO compute "circuits" around the loop during the shortest loop
transit lag you want to simulate, not one. Preferably, you should use at
least 5 (a frequently use rule-of-thumb for sampled systems). Then
you should smooth the signals with an appropriate filter. The better the
filter, the less critical is the number of "circuits" of iteration around
the loop during one loop transit lag, provided the number is greater than
two.
What this means for the possibility of simulation is that the transit lag
of the simulated loop must be at least 10, and preferably 25 compute
iterations, if you are to really trust your results. However, if the
computed loop includes an integrator or a slowing factor, that acts as
a simulated filter, which reduces the aliasing problem and you might be
able to cheat quite a bit (never with complete safety, though).
The results are also likely to be pretty near correct if none of the
input signals has a spectrum with components having a period less
than 10 (25) compute cycles--no step functions should be seen at any
of the points at which simulated waveforms are observed, at least not
on a scale at which you can easily detect dt. In Control Builder, plots
are usually made with dt=1 pixel, so a "step" should be seen as an
exponential of something like 1 cm rise width.
Seeing all functions as operating in parallel rather than in
sequence gives a very different intuitive feel for how a control
system works.
Yes, indeed it does. It's one thing to understand and graph the
equations, and quite another to watch graphs of the waveforms at different
places evolve simultaneously.
Simcon verified that the parallel interpretation does
in fact give the correct results. On such tiny distinctions rest
major differences in understanding.
Very true. Computational artefacts also have led many a simulator astray,
even very astute ones. Not taking acount of the aliasing problem is a
particularly subtle error, the consequences of which can lead to
misinterpretations that may lie hidden for a long time, as we know.
So here's the bottom line:
You really DO want to see everything evolve in parallel, properly synchronized
everywhere around the loop. YOU are the "observer" in my earlier message
of today, and you want to see as simultaneous anything that occurs at the
same moment in the loop. That means making dt short compared to the speed
at which things happen in your loop.
When you simulate, make sure your compute cycle is short enough in simulated
time that you can make at least 10, and preferably 25 iterations in the
time of one transport lag around the simulated loop. And if you can, make
sure your signals are filtered to a bandwidth no greater than 1/2dt, and
preferably 1/5dt.
You can often get away with fewer iterations in the time of the loop transit
lag if you are careful to ensure that your signals change only slowly.
You might even get away with a value of dt that gives you only one
iteration around the loop during the simulated system's loop transit lag,
but you leave yourself wide open for unexpected artefacts if you try it.
In the Control Builder, we use a trivial leaky exponential filter to
smooth all signals, which is far from ideal, but provides some measure
of safety. If you don't ensure that you avoid aliasing, your results
may well be close to right, but you won't know if you are being misled
in ways that are hard to detect.
One clear sign of a problem is the occurrence of fast oscillations
period 2dt-4dt, perhaps slower). But you may have problems even though
you don't see such oscillations.
Just a word to the wise, based on experience as well as analysis.
I think both Simcon (for IBM-compatible PCs) and Control Builder (for
Macintosh) are available for ftp from Bill Silvert's archive
machine. The Internet address for the Control Builder is
biome.bio.ns.ca:/pub/csg/mmt/Control_Builder_1.3b6.sea
for Simcon, it is
biome.bio.ns.ca:/pub/csg/pctdemos/simcon
(or simcon.zip; plain "simcon" may be a directory--I can't tell from here--
but simcon.zip is unlikely to be. And I know that Control Builder isn't.)
Happy simulating!
Martin