Re: Lahman, how ya doing?

In article <746ge.38$ix3.14@trndny07>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...

When I was almost finished composing a reply my modem disconnected and my
reply was lost. I ssh to a shell account. It's a disheartening
experience, and I don't really want to try to reproduce everything.

>> I think I can connect to this by way of the CAMAC counters-- the counters
>> hold the snapshot. As long as it stops and starts counting the particle
>> detectors and the clock at the same time it doesn't matter, to a first
>> approximation, how long it takes to get the data out and process it.
>
>I was assuming the counters (plural) needed to be synchronized (i.e.,
>they all counted over roughly the same time slice). That implies
>someone is starting them (i.e., an event goes to each CAMAC) at the same
>time and someone else is reading them (i.e., the event goes to the
>reader) at the same time. If that isn't the case, I was addressing a
>different problem.

All of them count over exactly the same time slice-- they all get their
start and stop signals from the same copper traces on the bus. Just FYI.

>> That |= symbol, mainly. I didn't even recognize it.
>
>In C/C++ it is the bitwise OR operator. The dual "|=" operation is
>essentially a shorthand equivalent to
>
>deferredBitmap = deferredBitmap | (1 << i);

And I've used += and -= many times, I should have guessed it.

>>>Finally, I thought you indicated that the "block" had the responsibility
>>>to decide whether its processing should be skipped for the current tick.
>>> If so, then I think that is a substantial dependency since Thermometer
>>>necessarily needs to understand /how/ Timer does its scheduling just to
>>>make that decision.
>>
>>
>> No, I was just assuming that it would be told an elapsed time when it's
>> triggered. I had Timer taking care of all the timing functionality,
>> including determining the elapsed time and passing it.
>
>Right, but it is still making a decision based on that elapsed time.
>The fact that it /is/ an elapsed time is what is bleeding cohesion --
>the "block" needs to understand something about scheduling semantics in
>general and the specific design context in particular. Avoiding that
>was why I belabored the difference between passing time vs. passing just
>the data to be processed (i.e., passing the data at the right time).

Decision making? That's based on the event type which is interpreted in
the dispatch() member function. If the event type needs the elapsed time,
the elapsed time is taken from the event and passed to the handler
function. If you're calculating something like a change over the time dt
in temperature dT of a thermal mass with heat capacity C and summed input
power P, that would be

dT = P*dt/C

That's not a decision, it's a parameter.

>> Remember that 8 pound sledge hammer? In my case, I've decided not to use
>> an event queue because the strategy of the program has Timer as the sole
>> passer of messages. There's no event that can be passed which can't be
>> processed immediately. I've also changed the message passing to be closer
>> to the example that you gave, and simplified it a little since it's a
>> simulation and not R-T and so everything is carefully controlled. And I
>> also load an elapsed time in the events before I send them off, which
>> wouldn't be necessary if I'd used ticks as the time unit as you did, but
>> I've decided to stay with seconds because it's closer to the real world,
>> it's easier to change the time resolution, and because I don't really
>> expect the processing time to become onerously long because of it. And
>> what the heck is the difference between an event and a pure data transfer
>> interface?
>
>If Timer /does/ provide all the coordination, that's fine. But recently
>you indicated a possible problem with "witching" ticks where multiple
>activities can be triggered. That resulted in some processing not being
>done on some ticks in the real controller. If you want to simulate
>that, then using a separate, lower priority thread for the processing
>that isn't critical to the timing will give you those skips -- if the
>processing is event-based AND you daisy-chain the non-critical
>processing using peer-to-peer events (as we talked about) rather than
>events generated from Timer.

I'm not sure I get you.

I can imagine a high priority queue for analog peices whose evolution is
determined by the laws of physics, and which are ignorant of timing
delays, and a low priority queue for delayable digital parts. If the
control action occurs every 7/60 seconds and the data is sampled every
60/60 seconds, the witching ticks will occur every 420/60 seconds and I
can imagine registering events something like

timer.add_event(&analog_part, 1/60, kEvolveEvent, kHighPriority);
timer.add_event(&controller, 7/60, kEvolveEvent, kLowPriority);
timer.add_event(&timer, 420/60, kDelayEvent, kLowPriority);
timer.add_event(&chart, 60/60, kSampleEvent, kLowPriority);

("k" stands for "konstant", a convention I've seen some people use.)

The delay event is passed back to timer, which pauses the low priority
queue, increments tick_count, runs through the high priority queue, then
returns to the low priority queue where it left off.

>> I'm glad you brought that up, because I've found reasons to want to tell
>> one class to get data from another class sometimes through one accessor
>> function, and sometimes through another accessor function. Like the two
>> sides of a thermal link-- the direction of heat flow depends on which
>> thermal mass has the higher temperature, and it would be convenient to
>> specify, say,
>>
>> heatsink.connect(&(link.side1));
>> target.connect(&(link.side2));
>>
>> Which would conveniently make the thermal link just another source (or
>> sink) of heat that can be thrown into a list with the controller, the
>> beam, noise, etc., and dealt with in a uniform way with no decision
>> making, no need to pass a temperature only to thermal link sources of
>> heat, etc. Or record different aspects of a block, like
>>
>> ChartRecorder chart1(&(controller.power));
>> ChartRecorder chart2(&(controller.gain_term));
>
>It is hard to tell without knowing what is going on in the innards, but
>these examples appear to simply be forms of relationship instantiation.
> In both cases I could easily envision the implementation just
>assigning to a particular pointer private variable that would
>subsequently be navigated during collaborations so that the message
>always got to the Right Place.
>
>>
>> And I like the sort-of self-documenting nature of that compared with my
>> original thought to give each class a generic output() member that
>> outputs whatever that block is supposed to put out. But it turns out
>> that in C++ pointers to member functions are a tricky thing. The advice
>> I've found involves static wrapper functions, but you still have to
>> specify which wrapper function, and that doesn't help if I want to select
>> from several potential member functions in the same instantiation of a
>> class. (Although there may just be a solution I don't see.)
>
>This is getting dangerously close to OOP and, as a translationist, I try
>to never go there. B-) This sort of thing is very OOPL-dependent.

I've gotten some help from comp.lang.c++ (imagine that). E.g.

Class a;
double (Class::* f)(double);
f = Class::twice;
cout << (a.*(f))(3) << endl;

And the target might be told to take data from side2 of the thermal link
by a command like

target.connect(&link, ThermalLink::side1);

Which is exactly the sort of thing that I wanted to do, and somewhat
close to how I'd imagined doing it. Except my compiler gives me warnings
about illegal implicit conversions and runs it correctly anyway, and gcc
won't compile it. I'd like to figure that out.

>> Another factor is that I understand my way, and I'm not sure I understand
>> what you're talking about. I mean, relating to my special interface
>> above, would I declare, for instance,
>>
>> heatsink.connect(&(link.new_side1));
>> target.connect(&(link.old_side2));
>
>For me to contrast things you will have to explain what heatsink,
>target, and link are and what the methods actually do in your
>implementation. As I indicated above, this might well be just a form of
>relationship instantiation that I am advocating.

Physically, target is a small metal cell containing a material that
absorbs neutrons and creates heat. It has a thermometer and a heater
resistor that the control system uses to control its temperature. It's
attached by a weak thermal link to another temperature-controlled block.
By controlling the temperature on each side we ensure that a constant
amount of power flows from the target to the sink.

The heat flowing along the thermal link is given by

P = k (T2 - T1)

where the minus sign establishes a convention that positive power on the
T1 side means heat flows in, negative means heat flows out. That's
reversed on the T2 side-- negative means heat flows in, positive means
heat flows out.

In my implementation (not completed) the target sums the input power and
determines its change of temperature. Part of that input power (negative
input power is fine) comes from the thermal link. The thermal link itself
is linked to the target and heatsink, so it can find the temperature
difference. But an accessor function won't know whether an output
power should be positive or negative unless it's told who wants to know,
or at least the temperature of whoever wants to know. None of the other
power inputs require that, and I didn't want to have to make a special
case for heat coming through the weak link. I wanted to just sum it up,
something like

for (int i = 0; i < MAX; i++)
input_power += heat_source[i]->get_power();

--
"I fart for joy and I laugh more than if I had cast my old age, as a
serpent does its skin." -- Aristophanes, Peace, 421 BC
.

Relevant Pages

  • Re: Measuring Power dissipation emperically
    ... the temperature of the water. ... This is how they measure the power dissipation ... the heat would just accumulate. ... The water will heat up. ...
    (sci.electronics.design)
  • Re: Warning about cheap TVs currently on sale
    ... discussion was whether the TV consuming power at 100W would also be radiating energy to the room at 100W. ... So we have less heat trasnfered from the source to the room. ... Insulation will indeed change the rate of flow of heat - it increases the "thermal gradient" or the temperature drop across the boundary. ... So, if your electric fire had a thermostatic control such that it turned off once the room temperature reached 25 degrees, then sticking it in an insulated box would change the power consumed and passed to the room since the internal box temp would very quickly reach 25 and turn the heater off. ...
    (uk.tech.digital-tv)
  • Re: muonic matter questions
    ... I expect the temperature might approach a billion degrees, ... heat can be conducted and radiated from the chip ... If the scale factor is 200, then it's the _power_ that would increase by ...
    (rec.arts.sf.science)
  • Re: Measuring Power dissipation emperically
    ... The water will heat up. ... Its not difficult to measure the initial and final temperature of the ... You may be confusing energy and power. ...
    (sci.electronics.design)
  • Re: Energy Discussion Part 1
    ... In very cold weather, if the heat vents to a room are closed off, it seems like this should reduce heating requirements, however it must be remembered that interior walls of homes are almost never insulated. ... The air pocket between the walls will act as a temperature dampener, depending upon how well the walls have been constructed. ... Assume that there are two heat sources, one for each of the rooms on each side of the interior box wall. ... Except, heat will begin flowing from the heated room, to the unheated room, right through the uninsulated wall. ...
    (misc.news.internet.discuss)