Re: Haven't done anything real with OOP yet.

From: Gregory L. Hansen (glhansen_at_steel.ucs.indiana.edu)
Date: 11/03/04 

Date: Wed, 3 Nov 2004 21:54:24 +0000 (UTC)

In article <Qpbid.6$ii1.4@trndny04>,
H. S. Lahman <hsl@pathfindermda.com> wrote:
>Responding to Hansen...

Back in the real world, it seems I'll have to become an expert on
photoemission spectroscopy in a short time, so I'll have to de-emphasize
programming and OOP. But...

>> I'm sure we must be thinking of different things. The time steps are
>> independent of the time it takes to execute a particular computation. If
>> I want a time step of 1/10 second, I would tell the model system that 1/10
>> second passed, e.g. by plugging t=0.1 into the filter formula above.
>> Whether it takes a microsecond or a year to complete the calculation of
>> that time step, it would return a number that says what the output would
>> have been given the initial conditions and the passage of 1/10 second.
>
>OK, I wasn't as precise as I should have been. I was making an
>assumption that the simulation would be used in comparative analysis
>(e.g., What If scenario comparisons), which means varying various
>parameters and observing the results.

That's exactly what the simulation would be used for.

>You are already committed to a
>7/60th second frequency (or whatever parameter the user supplies) for
>computing the beam values. You also have to employ a finer granularity
>for the heat flow calculations for whatever reasons.

Sampling time for the controller. The beam turns on and off on the order
of ten minutes or half an hour. The sampling time could in principle be
anything, but 7/60 reduces cross-talk with power lines.

>So you can decide you will do 10 heat flow calculations for each beam
>calculation. That provides the relative scale between heat flow and
>beam calculations, as you describe. And it doesn't matter how long each
>calculation takes, so long as that 10:1 ratio is maintained. But you
>have to enforce that /synchronization/ explicitly in the software.

Absolutely. If the peices aren't synchronized, the results will be
essentially meaningless.

>If
>you simply put the calculation is two concurrent threads you will get
>the 10:1 calculation only if it takes 1/10th the time to compute the
>heat flow that it does to compute the beam values. If there is any
>significant difference, the threads will be out of sync when the beam
>calculation samples the results of the heat flow calculation.
>
>Now you can trivially enforce the 10:1 ratio synchronization by the way
>you nest iterations. (Though that isn't always that easy to do in hairy
>simulations, as I can attest from painful experience.) The problem that
>I see here is not that sort of synchronization; it is the
>synchronization with the hardware.
>
>Let's say you employ a ratio of 1000:1 parametrically in a simulation
>scenario. You calculate the beam values every 116.67 ms (7/60th s).
>Your calculation of the heat flow is then done every 116.67 us. You
>have no problem doing the calculations quite accurately even if it
>actually requires 500 us to perform heat heat flow calculation because
>the ratio has scaled things so they are synchronized with the beam
>calculation. So far, so good.
>
>However, suppose the hardware requires 200 us to propagate the heat flow
>observation from the Resistor, though the Cell, Thermometer, and
>Controller to the beam calculation in Computer. That could be a
>combination of inherent hardware delays or simply the computation times
>for the software actually in the system. (E.g., clearly one fixed delay
>is the time it takes for a beam stimulation to be manifested at the
>Thermometer.) In that situation you have a simulation error because the
>hardware can't provide the same accuracy as the simulation so the
>simulation results will not correctly reflect the way the hardware
>actually works. That's because the simulation models the hardware _as
>if it could propagate signals along that path in 116.67 us_.
>
>Propagation delays in bench-top hardware of 116 us for such a path are
>pretty common. You can argue that 1000:1 is unrealistic for your
>situation, but that isn't the point. My issue here is that when one
>simulates hardware, one needs to consider the /possibility/ of such
>effects. So my first point here is that one cannot make generalizations
>that the relative time simulation will always work. It won't always
>work because the hardware runs in real time, not relative time.

If propagation delays might be important, they must be modeled and
simulated. Not reproduced. They can't be reproduced. The computer
running the simulation would have a different processor on a different
architecture, for starters. It would not be reading error signals from a
lock-in. The simulation also neglects other tasks, like periodically
reading data from counters in a CAMAC crate. And parts in the real
equipment like the target cell and the thermal link don't get a
calculation, they evolve according to the laws of physics. You cannot
run the simulation in real time and have any hope whatsoever that any
propagation delays would have anything to do with the actual equipment.

The easy answer is that the target thermal time constant could be three
seconds for a solid target, or two minutes for a cell full of liquid
helium-3, while the controller might miss its scheduled sample by 1/60
second but not by 2/60 second, and one missed sample isn't a skipped
sample and doesn't reschedule future samples. That sort of thing would be
very minor compared to, say, a gain that's too high and forces the target
into oscillation.

I'm more concerned with noise. I'd be adding simulated electrical noise
to the error signal and simulated temperature drifts to the pot before I
worry about propagation delays in the hardware.

>My second point it that after due consideration, it may well be that a
>relative time simulation will work Just Fine because one /can/ ignore
>that level of hardware effects. However, that consideration only deals
>with what one wants to examine with the simulation /today/. Tommorrow's
>problem may require an analysis that does care about those effects. If
>the cost of implementing a real-time simulation is essentially the same
>as implementing a relative simulation, why not simulate the way the
>hardware actually works directly?

One peice of advice I've learned in experimental physics is "Don't make a
Swiss Army knife." It's easy to spend a lot of time building something
with functionality that you'll never use and will never be important.

>[Caveat. There may be reasons why one can't use a real time simulation.
> For example, to simulate the Thermometer might require very complex
>heat flow calculations that simply could not be executed in the
>available real time slices. But in that case you would have to build in
>the same sort of synchronization as the 10:1 ratio for /every/ important
>hardware effect. When such effects are important, that tends to be a
>major pain in the ass.
>
>FWIW, a trick I have used in similar situations is to simulate the
>bottleneck calculation separately and save the results for table lookups
>in a real time simulation. In your case you could simulate Tnew =
>f(Told, V, dt) for the set of bursts in expected simulation ranges.
>Then those Tnew values are loaded into a table from configuration data
>and there is no calculation to slow down the real-time simulation. My
>point here is that reducing the risks inherent in relative time
>simulations is usually worth some extra effort to find a way to do
>real-time simulation -- when dealing with hardware.]

So far I think I can get away with analytical formulas that model the
system components. Heat capacities of solid are very low at low
temperatures-- their thermal inertia is very low-- so a heat pulse travels
very fast. I did a calculation once of the filtering by the weak link and
it was virtually nothing for periodic heat sources with periods comparable
to the several-seconds thermal time constant of an empty target cell.

But if I did need to worry about the details of heat flow from, say, one
part of the target to another, I suppose it would be finite differences
and a table.

>>
>>>>Sometimes the control loops do miss their scheduled time, depending on
>>>>when the system clock is updated relative to when the control loop is
>>>>entered, and how much other stuff is scheduled on that tick. But then the
>>>>loop iterates again and they pick up the slack before overrunning the next
>>>>sampling time. If we thought that was important it could be added to the
>>>>simulation-- not by running in real-time, but by empirically
>>>>characterizing it on the real equipment and then transfering that into
>>>>the simulation. Then on some iterations the control objects would be told
>>>>to skip.
>>>
>>>Let's say you have characterized the propagation delay in the
>>>Thermometer and know that the samples being processed by Computer are N
>>>ms behind the actual Cell temperature at the moment the beam computation
>>>is triggered. Also suppose the present system has a marginal overshoot
>>>problem. How do you determine if the overshoot problem is due primarily
>>>to the propagation delay, primarily to an inadequate filter, or
>>>primarily just the need to rethink the way the delay is handled? I
>>>don't see how you answer that question without simulating both
>>>Thermometer and Controller accurately and parameterizing What If scenarios.
>>
>>
>> That's how to do it. But I don't have to wait for an hour of real time to
>> simulate an hour within the model.
>
>You still have the potential problems above if hardware issues are
>important to the simulation problem.
>
>Scaling real-time simulation is often fairly easy, in principle; all you
>need to do is provide a new frequency attribute value to the timers.
>[Doing so, though, introduces similar risks as relative time simulation
>because one has to scale the elements that are fixed in absolute time
>explicitly. However, at that level one has already explicitly modeled
>those elements so they are usually pretty easy to identify. And such
>scale factors can be supplied parametrically just like the timer
>frequencies.]
>
>>>>>Another consideration is more about OO thinking. The object has a
>>>>>responsibility to do something. It is really up to someone else to
>>>>>determine when they do it (i.e., some set of preconditions for execution
>>>>>prevails as a result of some other activity). If the object has to
>>>>>decide whether it really needs to do something or not in response to the
>>>>>"tickle", that is giving it a new responsibility. So I would isolate
>>>>>that When issue in the timers. They should be responsible for all the
>>>>>rules and policies for when their associated objects do their thing. So
>>>>>they issue a trigger only when someone cares (i.e., the object really
>>>>>does need to do something).
>>>>
>>>>
>>>>Sampling time is a property of the controller; it's a user-determined
>>>>value that could be anything, and each controller runs on its own time.
>>>>It didn't seem satisfying that each instance of the controller would need
>>>>its own instance of a timer which does nothing except trigger the one
>>>>controller. I didn't see much of a difference between pulsing the
>>>>controller, and pulsing a timer that pulses the controller.
>>>
>>>I believe there's a big difference. The Timer isn't being "pulsed" per
>>>se. It has the responsibility of knowing when pulses need to be
>>>generated. Basically it enforces one business rule: the frequency of
>>>pulses. The user may define the value of that frequency, but it belongs
>>>to the Timer during the execution. In that sense Timer is pretty dumb
>>>object that knows nothing of the simulation semantics. How pulse
>>>generation is implemented doesn't matter. It could have a continuous
>>>polling loop in its own thread for the system time or it could delegate
>>>to an OS timer.
>>
>>
>> I can tell you how my timers would be pulsed. My system with MacOS 9
>> doesn't handle multithreading very well, and I wouldn't want to leave it
>> to the system clock anyway because I would want each time increment in the
>> system controlled and known, all components to evolve together. So I
>> would have an array of timers and, with each iteration, shoot a pulse to
>> them one at a time. Which is essentially what the OS would do if they
>> were all running as independent objects and accepting OS-level events.
>
>OK, but that is still an implementation issue. From the viewpoint of
>the functional requirements of the simulation problem, all the solution
>logically needs is an entity that has the responsibility for pumping out
>events with a defined frequency.
>
>[At the risk of confusing things, in an OOA model the timers usually
>would not even appear as entities in, say, a Class Diagram. They would
>be manifested as external events that magically appear with a
>predetermined frequency. IOW, from the perspective of the resolution of
>functional requirements, the timers themselves are part of the computing
>space implementation rather than being problem space entities needed to
>solve the customer's problem. (Alas, I have not been accurate in some
>of my descriptions of them simply because I didn't want to confuse
>things with tangents about OOA vs. OOD/P.)]
>
>>
>>
>>>The key issue here from an OO viewpoint is separation of concerns and
>>>cohesion. Timer is dumb but it is also very cohesive. It encapsulates
>>>an implementation that may turn out to be moderately complicated in
>>>detail. More important, that implementation may change and when it
>>>does, nobody else is affected. Similarly, Controller (actually, I
>>>though it was Computer and Controller just did the thermometer error
>>>filtering; whoever) has a limited responsibility to compute the beam
>>>pulse voltage and duration _when asked_. That is also a cohesive
>>>concern that is simple as a responsibility but may have a complicated
>>>implementation. And its implementation can be modified without affecting
>>>things like the synchronization of activities.
>>>
>>>If Controller owns both responsibilities (performing the computation and
>>>determining when to do it), then it will be less cohesive. The
>>>responsibilities will likely be interleaved in the same method scope.
>>>So there is risk that when one responsibility is modified, one may break
>>>the other. Separation of concerns just manages that complexity through
>>>abstraction (allocating the responsibilities to different objects) and
>>>encapsulation (ensuring one concern's implementation can't be affected
>>>by changes to the other concern's implementation).
>>
>>
>> Controller needs to know the sampling rate in order to make the
>> calculation. The proportional term in a PID controller is just a dumb
>> multiplying factor, but the derivative term is
>>
>> (T_D/dt)*(V[i] - V[i-1])
>>
>> and the integral term is
>>
>> V[i-1] + (dt/T_I)*V[i]
>>
>> And the filter as above. Here, dt is the sampling time and T_D and T_I
>> are the derivative and integral time constants. If the timer frequency
>> were changed, the controller must be informed of that. So there's some
>> interleaving of responsibilities, anyway.
>
>It needs to know the value of dt for the particular computation; the
>value is simply a parameter to the calculation. That is not the same
>thing as knowing when it needs to do the computation. For one thing,
>the value of dt represents static state while determining when to do the
>computation is related to dynamic state.
>
>IOW, this is a case of the same data being processed by different
>behaviors (functionality). As a practical matter, the semantic
>perspective is different (elapsed time vs. computation frequency) for
>the behaviors and it is likely they would be in separate attributes with
>different values (units = t vs. units = 1/t). [But one value is derived
>from the other so one would have to indicate that dependency in an OOA
>model. Automatic code generators like to know those things so that they
>can enforce data integrity. B-)]
>
>>>Let me make sure that I understand this by walking through s stream of
>>>consciousness analysis. As I understand it the feedback looks like:
>>>
>>>T -> Thermometer -> Controller -> Computer -> V
>>> continuous digitized integration
>>
>>
>> More like
>> __________________________
>> | Controller |
>> Thermometer -> | Computer -> power supply | -> V -> resistor
>> |__________________________|
>>
>> with the error signal e proportional to T-T_{setpoint}. Just to make sure
>> it's understood where the computer is. It's part of the control system.
>> It would be reasonable to extend Controller all the way to the resistor,
>> depending on whether your definition of a controller stops at a control
>> signal or at the controlling action. For this purpose, I'd go to the
>> resistor; the controller outputs heat. But that's just me.
>>
>>
>>>The temperature of the Cell, T, or some equivalent needs to be computed
>>>by the simulation at least every 7/60th second. To a first
>>>approximation the simulation could compute Tnew and feed that directly
>>>to Computer, who would do its think based on a theoretical interpolation
>>>of (Tnew - Told). At that <simplistic> extreme, one just needs to do
>>>this every 7/60th second and the feedback calculation of T just becomes
>>>an attribute of Thermometer that Computer accesses when it is triggered.
>>> In that case, Computer completing its computation could directly
>>>trigger the computation of T, so one only needs one time stream to
>>>trigger Computer.
>>>
>>>As soon as one tries to emulate the continuous analog output of
>>>Thermometer, though, one needs a more incremental (digitized) view where
>>>multiple values of T are produced. But then each value of T in a
>>>digitized computation would correspond to a single error output value.
>>>Controller would no longer need to digitize and it would consume the
>>>error values. It would filter them and present them to Computer.
>>
>>
>> Uh... a more digitized view for continuous analog output? I'm not
>> following you.
>>
>> The error signal is actually 13 bit, but that's as good as continuous.
>
>I guess I misunderstood. I thought error was an analog output to the
>controller who applied an analog low pass filter and /then/ digitized
>the signal. This is just saying the signal is digitized earlier in
>Thermometer. My point here was just that software doesn't do analog
>well, so one has to digitize in the simulation.

The filter is in the lock-in amplifier-- that's what turns the AC input
into a DC output. It's digitized after filtering, and the computer reads
it through the GPIB.

>>
>> Let me show you why I didn't like a propagating event. A reasonable
>> system to simulate might look like
>>
>>
>> pot
>> |
>> v
>> controller -> heatsink -> thermometer -
>> ^ ^ |
>> | | |
>> |_____________+_____________________|
>> |
>> link
>> |
>> v
>> controller -> target -> thermometer -
>> ^ ^ |
>> | | |
>> | beam |
>> |_________________________________
>>
>> The problem is essentially geometrical. You might have a timer to trigger
>> the target, that goes around the loop, through the thermal link, around
>> the other loop, into the branches... where does it stop? How to ensure
>> everything is triggered only once for each time step? I can think of a
>> few ways that are messier than I'd like. E.g. each object has a counter,
>> and the iteration number is passed around. Or a path is defined by fiat
>> and built into the network-- start at beam, target informs link and
>> thermometer (but not beam or controller), etc. Ugh, might as well use an
>> algorithm as that.
>
>Both loops do essentially the same thing and their control is completely
>independent. The beam is going to pump out {V,dt} based on the actual
>measured cell temperature whether the heatsink is there or not.
>Similarly, the pot is going produce the same values regardless of what
>the beam is doing. I am arguing above that those control loops can each
>be triggered by a single timer event and all the rest of the
>computations can be daisy-chained from that event on a given cycle.
>
>However, the /simulation/ has a synchronization problem because it needs
>to compute T rather that measure it and that computation depends upon
>heat flow across the link /after/ each loop has done its thing in the
>feedback cycle. IOW, the beam and the pot provide {V, dt} based on the
>values of T computed for the /last/ cycle. Those T values essentially
>predict the cell temperature for the next cycle. The simulation needs
>to compute the new values of T for the current cycle before the the next
>feedback cycle is triggered. The two loops need to be synchronized in
>the simulation such that the new target cell temperature is only
>computed after both loops have computed their new {V, dt} values.
>
>Since the key to the synchronization problem is the heat transfer across
>the link, let's let Link do the final computation of target cell
>temperature. Let's also assume both feedback loops execute concurrently
>in their own thread. Then we just need one timer that triggers both
>feedback cycle computations. For example, the sequence might go:
>
>Timer triggers; sends event to Link
>Link computes T values:
> get {V, dt} values for both sides of Link
> compute heat transfers over link
> interpolate the target cell temperature
> save the T values predicting the target cell temperature
> send events to both Thermometers when done
>Thermometer computes error values:
> iterate over T values from Link
> compute corresponding error values
> send event to Controller when done
>Controller {V, dt}:
> filter error values from Thermometer
> compute {V, dt} from filtered values
>
>Assuming the both feedback cycles always complete before the next Timer
>trigger, Link is always synchronized.

Is it faithful to OOP to have the link tell the cell what its state is
going to be? I wanted to think in terms of the cell getting heat inputs
from every thermal source/sink it's connected to and determining its own
temperature-- the interface mimicking the real world.

>
>BTW, are there really two Thermometers? If the feedback for both beam
>and pot is driven by cell temperature, wouldn't you only need one
>Thermometer? Or is temperature measured on each side of the cell?

Target and Heatsink are both seperately temperature controlled so that we
know the amount of heat flowing from Target to Heatsink remains constant.
That's important.

>
>>>>Speaking of reviewing C++, the textbooks say a little about OOP, and then
>>>>all the example programs define some objects and then run a main() to do
>>>>things to them one at a time. Seems kind of like procedural OOP.
>>>
>>>Keep in mind that C++ is the most technically deficient of all the
>>>popular OOPLs because it was designed to be close to the computing
>>>hardware. (A more cynical soul might suggest that it was designed so
>>>that C programmers could continue doing things as they always had, but I
>>>would never say such a thing.)
>>
>>
>> It seems Bjarne Stroustrop would, though. Pick up C++ a little a little
>> at a time, he's said.
>
>Stroustrop was also C++'s author. The prosecution rests. B-)
>
>> And in the book on OOA/D I got from the library, the author mentioned some
>> thinkers that thought it's not really possible to mixing OO and procedural
>> paradigms. But it seems like that's exactly what's done in typical
>> examples in a C++ textbook. Heck, even if you stay mainly procedural,
>> objects look like great things to stick in there because you can do your
>> procedures on self-contained chunks of data and functionality. I don't
>> see a fundamental conflict.
>
>Good for the OOA/D author! I agree completely that the construction
>paradigms are incompatible. The biggest challenge facing converts to OO
>development is to forget everything they ever learned about procedural
>development. Alas, they rarely do. The OOness of the application does
>not exist in the OOPL syntax; that just provides stronger typing for a
>Better C. It exists in the way the problem space is abstracted and the
>way collaborations are defined.

Well, classes still seem mighty convenient for the procedural programmer,
but maybe he should refrain from calling them objects! 

-- 
"Outside the camp you shall have a place set aside to be used as a 
latrine.  You shall keep a trowel in your equipment and with it, when you 
go outside to ease nature, you shall first dig a hole and afterward cover 
up your excrement." -- Deuteronomy 23:13-14

Relevant Pages

  • Re: Havent done anything real with OOP yet.
    ... >>While for some of the simple simulation goals we've discussed relative ... Thermometer and Controller accurately and parameterizing What If scenarios. ... >>they issue a trigger only when someone cares (i.e., ... It has the responsibility of knowing when pulses need to be ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... >> separate timer. ... >We are back to the issue of simulation strategy definition. ... Sampling time is a property of the controller; ... >objects do nothing different in response to their triggers either way. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... A device driver is software that is dedicated to talking to a particular hardware unit. ... Nothing about how that value gets there is relevant to how the controller software deals with it once it is there. ... For the simulation you will replace the hardware producing the delta-V with heat flow computation software that will probably be encapsulated in an object that abstracts whatever thing has a temperature. ... writing data doesn't depend on it being the 600th tick; it depends on there being a proper collection of data available and the rest of the system happens to ensure that it is there and consistent on the 600th tick. ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... and nothing to control and nothing to wait for. ... It's a simulation. ... >synchronized exactly as they are in the real hardware. ... >Thermometer and Controller accurately and parameterizing What If scenarios. ...
    (comp.object)
  • Large scale engineering calucations performance bottlenecks
    ... optimizing variables. ... DRAM -- I should have enough physical memory, but Excel ... but the calculation time even without ... this simulation is best ...
    (microsoft.public.excel.misc)