simulation@uflorida.cis.ufl.edu (Moderator: Paul Fishwick) (12/20/89)
Volume: 13, Issue: 2, Tue Dec 19 15:59:05 EST 1989 +----------------+ | TODAY'S TOPICS | +----------------+ FORUM: Discrete Event Methods (1) Combined Simulation Techniques (2) Re: Combined Simulation (3) Unscheduling with Continuous Parameters TOPICS: (4) Simulating CPU's (5) RE: Yet another GVT Algorithm (6) CHI in AeroSpace Systems * Moderator: Paul Fishwick, Univ. of Florida * Send topical mail to: simulation@bikini.cis.ufl.edu OR post to comp.simulation via USENET * Archives available via FTP to bikini.cis.ufl.edu, login as 'ftp', use your last name as the password, change directory to pub/simdigest. * Simulation Tools available by doing above and changing the directory to pub/simdigest/tools. ----------------------------------------------------------------------------- Date: Tue, 19 Dec 89 11:02:16 -0500 From: Paul Fishwick <fishwick@fish.cis.ufl.edu> To: narain@rand.org, simulation@ufl.edu, steve@titan.tsd.arlut.utexas.edu This is a comment on Sanjai Narain's recent posting: Sanjai writes: > The event scheduling view of the discrete-event technique is generally > intended to simulate discrete systems, i.e. those whose state changes only > at discrete instants of time. When continuous parameters are involved, > e.g. position, temperature, voltage, pressure, the technique is suitably > extended. However, sometimes the extension is not obvious for situations > such as the one defined by the following rules: > If a chip is put into the furnace at time T then it is cooked at > time T+300, provided the temperature of the furnace never drops > below 700 at any point of time between T and T+300. > Temperature of furnace at time 0 is 800. > When furnace is switched off, temperature drop is given by the > continuous function f(t). Similarly, when furnace is switched on, > temperature rise is given by the continuous function g(t). >Now, suppose an event "chip put into furnace" occurs at time 0. By the >discrete-event technique, we would schedule the event "chip cooked" for >time 300. Now, suppose an event "furnace switched off" occurs at time >100. Question: > Do we unschedule "chip cooked" for time 300? With current techniques for combined simulation (continuous and discrete), one *would not* schedule the event "chip cooked" when "chip is put into furnace" at time 0. In a combined simulation, the continuous part of the process "drives" the simulation --- that is, time is incremented in small steps. Therefore the logic for the above might be something like: WHILE NOT(event-occur) AND elapsed-time < 300 DO Solve g(t). It is only when elapsed-time = 300, that the event "chip cooked" actually gets scheduled. If the model is correctly constructed, it is not essential to "look back" (at least in a non-distributed simulation). -paul +------------------------------------------------------------------------+ | Prof. Paul A. Fishwick.... INTERNET: fishwick@bikini.cis.ufl.edu | | Dept. of Computer Science. UUCP: gatech!uflorida!fishwick | | Univ. of Florida.......... PHONE: (904)-335-8036 | | Bldg. CSE, Room 301....... FAX is available | | Gainesville, FL 32611..... | +------------------------------------------------------------------------+ ------------------------------ Posted-Date: Tue, 19 Dec 89 11:21:38 CST Date: Tue, 19 Dec 89 11:21:38 CST From: steve@titan.tsd.arlut.utexas.edu (Steve Glicker) To: fishwick@fish.cis.ufl.edu, narain@rand.org, simulation@ufl.edu Subject: DMOD Cc: steve@cs.utexas.edu This is a response to the discussion on DMOD, lead by Sanjai Narain: I agree with Paul in the case of a combined simulation and that it is not necessary to "look back". I think that a similar point can be made in the case where a continuous technique is not required. In this case we would not deschedule "chip cooked" until we knew it would not be cooked at time 300. When the furnace was turned off we would compute f(switch-off-time) and schedule an event to indicate when the temperature was too low. If the "too low" event occurred (was not canceled) we would have to deschedule "chip cooked". Steve Glicker (steve@titan.tsd.arlut.utexas.edu) ------------------------------ To: simulation@ufl.edu, steve@titan.tsd.arlut.utexas.edu, narain%pluto@rand.org Subject: Unscheduling with continuous parameters Date: Tue, 19 Dec 89 11:47:48 PST From: narain%pluto@rand.org Convention: An event is represented as a tuple <C,T> where C is the content of the event and T is its time stamp. The responses I have received regarding my question/doubt about the use of the event-scheduling view of the discret-event technique seem to fall in two categories: (a) Sample temperature at a sufficiently fast rate and when it falls below 700, unschedule <chip-cooked,300>. The problem, however, is that sampling can be very inefficient. (b) When <furnace-off,100> occurs, calculate the earliest time T at which temperature could fall below 700. Schedule an event e.g. <temp-falls-below-700,T>. If this occurs, unschedule <chip-cooked,300>. Also ensure that <temp-falls-below-700,T> is unscheduled should <furnace-on,X> occur for any time 100<X<T. The problem with this approach is the creation of extra events and the surrounding scheduling/unscheduling logic. If you look back, as in DMOD, you only need to write an algorithm which determines whether the temperature has ever fallen below 700 between 0 and 300. The algorithm can be part of the causality rule e.g. <chip-in,T> causes <chip-cooked,T+300> if temperature-does-not-fall-below(T,T+300,700). This rule (suitably transformed into DMOD syntax) can be directly executed. You do not have to break it up into several pieces of code doing scheduling and unscheduling, whose declarative meaning is not very clear anyway. Also, Steve Glicker has requested clarification of terminology in DMOD. This can be obtained from our WSC-89 paper "A logic for simulating dynamic systems". A superset of it will be ready in a few weeks. In particular, it will show how one can formally prove temporal properties of modeled systems. I would just like to add that the output of a DMOD simulation is only the set of events which occurred, NOT all events which were considered for occurrence (scheduled, in common parlance). Furthermore, the notion of causation subsumes those of scheduling and unscheduling. One need not think in terms of these or event queues. Sanjai Narain ------------------------------ Return-Path: <news@cs.umu.se> Date: Tue, 19 Dec 89 12:05:18 +0100 From: news@cs.umu.se (News Administrator) To: comp-simulation@sunic.sunet.se Newsgroups: comp.simulation Path: dvlsbd From: dvlsbd@cs.umu.se () Subject: Processor simulation Keywords: Processor simulation Sender: news@cs.umu.se (News Administrator) Reply-To: dvlsbd@cs.umu.se () Organization: Dep. of Info.Proc, Umea Univ., Sweden Date: Tue, 19 Dec 89 11:05:07 GMT Hello out there - I hope this is an appropriate newsgroup for my question. What I wonder is: does there exist any programs which simulate processors out there? PD or commercial? I am particualy interested in simulation of MOTOROLA processors (e.g. 68000 inchip), but everything is of interest. Please email - and... thanks! /S. -- | usenet: dvlsbd@cs.umu.se # The limits of my language mean | | # the limits of my world. | | # - L. Wittgenstein | ------------------------------ Date: Tue, 19 Dec 89 08:42:11 PST From: reiher@onyx.Jpl.Nasa.Gov (Peter Reiher) To: simulation@bikini.cis.ufl.edu Subject: Re: Yet another GVT Algorithm If I understand your proposed GVT algorithm correctly, it makes certain assumptions about message delivery. In particular, it seems to me that it does not take into account messages "in transit", messages which have been sent by the sending object but have not yet arrived at the receiving object's input queue. If your system can guarantee that all such messages will be put in the receiving object's input queue within the time required to make two circuits, it will probably work. If not, the underlying message subdelivery system may choose to deliver a message with a pre-GVT value sent just before the GVT calculation started just after the calculation completes. (Messages in transit have always caused the greatest problems with GVT calculations here at JPL.) Let me try a scenario to make sure I understand. There are two processes, A and B. A is the GVT master. A sends a message to B with receive time 100. A then starts executing its next message, at receive time 200. Upon completion, A decides to start a GVT calculation. It gathers its own clock value (say it's 250) and B's (150, say, because the message A sent to B has not yet been delivered). A proposes 150, passes the token to B, and marks itself white. B looks at its queues, finds no messages earlier than 150, saves the value "150", passes the token back to A, and marks itself white. The token is still white, since no one has disagreed with the proposed value. A passes the token to B. B still has not received the message at time 100, so B leaves the token white and passes it to A. A has not rolled back, either, so it leaves the token white. A notices at this point that the token has made two complete trips, so it sets its GVT to 150, the proposed value, and broadcasts that value to B. B sets its GVT to 150 and garbage collects an input message at time 125. Now the tardy message delivery system chooses to deliver A's message to B with timestamp 100. B rolls back before GVT and chaos ensues. Unless some mechanism ensures that the timestamp 100 message gets delivered before the token makes its second appearance at B, the algorithm will fail. Am I missing something? I don't think one can get around the need to keep track of the receive time of undelivered messages unless there is some guarantee about ordering of delivery or the maximum time required to get a message into an input queue. If one has no such guarantees, then a message can hang around arbitrarily in the ether waiting for delivery, while neither the sender nor the receiver take responsibility for it in the GVT calculation. Peter Reiher reiher@onyx.jpl.nasa.gov . . . cit-vax!elroy!jato!jade!reiher ------------------------------ Date: Tue, 19 Dec 89 15:52:25 -0500 From: Paul Fishwick <fishwick@fish.cis.ufl.edu> To: simulation@ufl.edu >From uflorida!uakari.primate.wisc.edu!samsung!uunet!ssbell!mcmi!denny Thu Dec 7 09:42:15 EST 1989 Article 127 of comp.simulation: Path: uflorida!uakari.primate.wisc.edu!samsung!uunet!ssbell!mcmi!denny >From: armstron@bmers11 (Steve Armstrong) Newsgroups: news.announce.conferences,comp.cog-eng,comp.graphics,comp.windows.misc,comp.realtime,comp.simulation,sci.space Subject: CHI '90 Workshop: Computer-Human Interaction in Aerospace Systems Date: 5 Dec 89 01:00:11 GMT Expires: 01/30/90 Sender: denny@mcmi.uucp (Denny Page) Organization: Bell-Northern Research, Ottawa, Canada Approved: denny@mcmi Xref: uflorida news.announce.conferences:842 comp.cog-eng:1293 comp.graphics:8287 comp.windows.misc:1376 comp.realtime:340 comp.simulation:127 sci.space:13469 Call for Position Papers CHI '90 Workshop: Computer-Human Interaction in Aerospace Systems A limited attendance, invitational workshop on Computer-Human Interaction in Aerospace Systems is being organized for the CHI '90 conference in Seattle, Washington, 1-5 April, 1990. The workshop will be 1-2 April 1990. The purpose of the workshop is to explore issues facing designers and users of decision support systems in real-time, high-risk aerospace systems. The workshop will focus on the following issues: how do we model the user/operator in complex time-critical environments; how do we design the human-computer interaction (displays, controls, and aids) to ensure that the user is integrated into the decision process; what comprises an intelligent computer interface for a supervisory controller; how do we provide timely, context-sensitive information in real time without overloading or distracting the human operator; how do we design operator aids/tutors using knowledge-based technology that enhances the human-computer interaction and overall system effectiveness rather than replacing the human decision maker. Application domains include the design of human-computer interaction (e.g., displays, controls, aids, tutors) in satellite ground control systems, shuttle and space station control systems, and advanced aviation in both the cockpit and air traffic control. Workshop participation is limited to twenty people. Individuals wishing to attend the workshop may request an invitation by submitting a 3-5 page position paper discussing their experiences or research in the area of human-computer interaction in real-time complex dynamic systems (particularly aerospace applications). We encourage both human factors and systems designers, as well as other knowledgeable individuals to participate. We wish to obtain a balanced university/government/industry representation and interaction. The position papers of the invited attendees will be reproduced and distributed to the attendees prior to the workshop. Selected papers may be submitted for publication in the SIGCHI Bulletin. Also, workshop results will be reported in the Bulletin. Participants will be charged a $50 workshop fee to help defray the costs of coffee breaks and A/V equipment. Position papers are due no later than January 30, 1989. Three copies, double-spaced, should be sent to: CHI '90 Workshop on Computer-Human Interaction in Aerospace Systems Christine M. Mitchell Center for Human-Machine Systems Research School of Industrial & Systems Engineering Georgia Institute of Technology Atlanta, GA 30332-0205 Phone: (404) 894-4321 E-mail: mitchell@chmsr.gatech.edu Fax: (404) 894-2301 Invited Participants will be notified by March 1, 1989, and will also be sent copies of the selected position papers together with a final agenda for the workshop. -- Good health is merely the slowest rate at which one can die. ------------------------------ END OF SIMULATION DIGEST ************************