simulation@uflorida.cis.ufl.edu (Moderator: Paul Fishwick) (10/25/90)
Volume: 18, Issue: 7, Thu Oct 25 00:08:53 EDT 1990 +----------------+ | TODAY'S TOPICS | +----------------+ (1) 1991 Directory of Simulation Software (2) Simulation for Fault Diagnosis in Circuits (3) Orbital Trajectories (4) JOB: Simulation Position (5) Object Oriented Simulation (6) SPECIAL: Mismanagement of Simulation Conferences * 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 (128.227.224.1). Login as 'ftp', use your last name as the password, change directory to pub/simdigest. Do 'type binary' before any file xfers. * Simulation Tools available by doing above and changing the directory to pub/simdigest/tools. ----------------------------------------------------------------------------- Date: Fri, 19 Oct 90 20:01:21 GMT From: mcleod@Sds.Sdsc.Edu Subject: Software Directory Call for WEntries To: simulation@bikini.cis.ufl.edu X-St-Vmsmail-To: ST%"simulation@uflorida.cis.ufl.edu" CALL FOR ENTRIES 1991 DIRECTORY OF SIMULATION SOFTWARE The Society for Computer Simulation is preparing its "2nd Annual Directory of Simulation Software" for publication in the first quarter of 1991. Listings of commercially available simulation software are invited as well as any promotional literature. Software is not tested nor endorsed nor warranted by SCS, but all entries are subject to verification by the editor, and each entry must include a small submission fee which will be refunded if an entry is not included. Each entry includes: The software name; a 50 word description of the software and what it does; complete address and name of the source for purchase or further information; description of hardware/software/operating system requirements; and the approximate cost. Additionally, each entry is cross-indexed alphabetically in up to four applications areas. For further information, an entry form and a complimentary issue of the 1990 Directory of Simulation Software, write or call: Brian O'Neill, SCS, PO Box 17900, San Diego, CA 92177 (619) 277-3888 or MCLEOD@ SDSC.BITNET. ------------------------------ To: comp-simulation@ukc.ac.uk Path: aber-cs!cho From: "C.H. Orgill" <cho@cs.aber.ac.uk> Newsgroups: comp.lsi.cad,sci.electronics,comp.simulation Subject: Failure modes in large, simple, electrical circuits Keywords: electrical simulation failure faults qualitative graph theory Date: 19 Oct 90 10:46:33 GMT Reply-To: Chris Orgill <cho@cs.aber.ac.uk> Distribution: world Organization: UCW,Aberystwyth,WALES,UK I am currently involved with a project which has a strand which is investigating qualitative representations of simple but large electrical circuits. The components and typical complexity are those to be found in a modern luxury automobile. The complete circuit is littered with switches and relays whose large number of configurations can partition the circuit into many 'active' (i.e. current flowing) states. The circuit can also suffer faults. Proposing that a point in the circuit becomes grounded, connected to battery positive, or open-circuited will produce a circuit with new connectivity. In the simulation of these faults the easiest option is to re-run the simulation on the entirety of the new circuit. What is as yet unknown to us is the existence of some incremental method which can perform the minimum amount of recalculation and still be more efficient than the simple brute-force approach (i.e. the extra complexity of finding the minimum sub-circuit changed must result in an average complexity that is no worse than complete recalculation). Any pointers to interesting graph-theoretic algorithms (the circuit can be seen in graph-theoretic terms as a flow digraph) or relevant application areas (e.g. pcb testing, other work in vehtronics, aerospace &c.) would be of great interest. I would be happy to summarise replies to the groups above. Best Regards, Chris Orgill, tel +44 970 622447 Research Associate, Computer Science Department, cho%cs.aber.ac.uk@uunet.uu.net (ARPA) University College of Wales, cho@uk.ac.aber.cs (JANET) Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. ------------------------------ To: comp-simulation@uunet.UU.NET Path: remtech!slarti!mclean From: remtech!slarti!mclean@uunet.UU.NET (Terry McLean) Newsgroups: comp.simulation Subject: Orbital Trajectories Date: 23 Oct 90 14:18:50 GMT Sender: remtech!news@uunet.UU.NET I am looking for a particular computer code that is being used by several people for the purpose of design optimization methodology for aeroassisted STVs. The name of the code is OTIS, Optimal Trajectories by Implicit Simulation. I have heard of OTIS being referenced in a NASA symposium and an AIAA conference. I also think this code is being passed around by certain vendors in the Wright Patterson area. If anyone knows what I am talking about and where I might get myself more information and possibly a copy of this code please E-mail me or give me a call. I would highly appreciate it. Thankyou, Terry McLean 205-536-8581 uunet!ingr!remtech!slarti!mclean ------------------------------ Date: Tue, 23 Oct 90 23:00:27 pdt From: well!rpi@apple.com (David Reed) To: fishwick@fish.cis.ufl.edu, decwrl!well.sf.ca.us!well!rpi@uunet.uu.net Subject: Re: job opportunity C UNIX programmers and interface designers in high-end full-emmersion simulation systems sought. RPI Advanced Technology Group, POB 14607, San Francisco, CA, USA, 94114. Resume and salary/fee requirements. ------------------------------ Date: Wed, 24 Oct 90 09:28:00 -0700 From: Michael G. Tashker <tashker@erg.sri.com> To: simulation@bikini.cis.ufl.edu Subject: Re: SIMULATION DIGEST V18 N6 Newsgroups: comp.simulation In-Reply-To: <24992@uflorida.cis.ufl.EDU> Organization: SRI International, Menlo Park CA Cc: As a new news person, am not sure just what protocols are to be observed when responding to articles in comp.simulation; i.e. do I respond to the sender, the group as a whole (and if so, how?). [[EDITOR: Respond to the group (in addition to the sender) if the article is of general interest to the Digest. NOTE: If the sender has mentioned that he will collect all responses for a later summary to be submitted to the Digest, then you should not reply to the Digest directly. -PAF]] Anyway, though I'd drop in on comp.simulation to find out what's going on in discrete simulation languages and OOPS. I'd just decided as an exercise for a new C++ convertee to see if I could program up something I'd decided to call sim++ (obviously taken); it would have the simulation constructs of Simscript II.V and of course be totally c/c++ compatible. This was prompted by CACI's announcement of Modsim (MODSIM?), which appears to have II.5 functionality with objects. This seemed to me to be unnecessary, given c++. Examples of silliness: the mention in the manual's preface that "modsim now has dynamic strings with an overloaded + operator". Well, c++ is clearly the language of choice to do things like that. Imagine if you will, c++ (perhaps using the NIH classlib) with sim constructs. Now; has anyone done this? Is anyone interested in this? Am I sending mail to the right person? ------------------------------ Date: Fri, 19 Oct 90 09:54:14 GMT From: mcleod@Sdsc.BITnet Subject: Mismanagement To: cellier@arizevax.bitnet X-ST-Vmsmail-To: ST%"cellier@arizevax.bitnet" Hello, Francois! I note your "protest loudly" about the "mismangement" that allows conflicts in scheduling meetings. That is a problem that has plagued us for 38 years -- since the founding of what is now the the Society for Computer Simulation International. But you are wrong; the problem is not mismanagement, but NO management. Each organization plans their own meeting without knowledge of what others are doing. By the time the dates are announced it is too late to change. No person or organization has the mechanism nor the authority to prevent conflicts. I believe AFIPS made an unsucessful attempt at early publication of selected dates, but now AFIPS is being dissolved. IFIP should perform such a service, as it is truly an international problem. However, as it is, you "protest loudly" to the breeze; no one out there is responsible! While protesting, can you suggest a solution? John McLeod >From CELLIER%EVAX2@Arizona.edu Fri Oct 19 15:39:52 1990 Date: Fri, 19 Oct 90 12:39 MST From: CELLIER%EVAX2@Arizona.edu Subject: Re: RE: Mismanagement To: Fishwick@Fish.CIS.UFL.Edu X-Envelope-To: Fishwick@Fish.CIS.UFL.Edu X-Vms-To: IN::"Fishwick@Fish.CIS.UFL.Edu",UACCIT::IN%"McLeod@Sdsc.Bitnet" Dear John: Of course, I know that I am protesting to the breeze ... why do you think that I am so frustrated? However, I might have a (partial) solution to offer. You are talking about "authority". This sounds too much like a legal problem to me while, in fact, it is a problem of bureaucratic organizations. I believe that every organization has a vital interest to prevent these conflicts since it hurts them as much as it hurts the others. But you are right. Conferences are organized by first making the necessary arrangements with the hotels ... and by the time you have signed a contract you can't pull your neck out of the sling any more. Here my answer. This newsletter is read by MANY (most?) simulationists (such as YOU and ME). If every potential conference organizer would send a message to the digest saying: "I wish to organize a conference on such and such topic. I currently foresee to run it around such and such month. Would anyone who knows about potential conflicts let me know PDQ, p l e a s e ?" chances are that conflicts would become known to the organizer sufficiently early in the game. S/he can then still decide what to do ... no legal authority requested or given ... but at least, conflicts would be known. Second answer. If all simulation organizers would send their conference topics and dates to UFL (or another designated place) NOT for constant publication, but for maintaining the information to be looked up in a central place via anonymous FTP or similar, that might help also. Computers are wonderful organizers if people learn how to use them. The magic buzz word is an electronic bulletin board. Major obstacle: While MANY (most?) individual simulationists have meanwhile learned to make use of electronic mail, electronic newsletters, electronic bulletin boards, electronic conferences, anonymous FTP, and what other electronic gadgets there are ... the main office of our beloved major simulation organization (SCSI) has not !!! John: Since you are so close to them, and since YOU know how to do it right, maybe, you could talk to them, pat them fatherly on their shoulders (does a legal person have shoulders?), and get them onto the right track. Would you do this for us? You would serve your community greatly. Yours fondly Francois Dear Francois-- I thot your note about the conflicts between conferences was pretty much on target, except for the issue of "mismanagement," which I'd submit is not the case at all. Mike Chinni articulated the issues quite well and offered a constructive--if not burdensome to him--idea which would partially solve the some of the difficulties. His focus though is on simulation conference conflicts. We try to keep apprised of ALL potential conference conflicts and where possible make a decision on timing that we believe will serve the most members. You mentioned IMACS' Triennial Conference overlapping the SCSC in July. We knew about the conflict, but the IMACS folks were the ones who created it, perhaps unavoidably due to the constraints of hotel and convention sites and their availability. The SCSC is always held in July and annually and always (so far) in the U.S. or Canada. Our conferences are usually scheduled out four years or more, and that means every three years we'll have the potential for a conflict with IMACS or others who choose to hold their events in a time frame pretty well established for most of our conferences and (at some relief to our members in their planning and scheduling and budgeting for educational events). If we were able to work around only other simulation conferences, users group meetings, seminars, local and regional meetings, etc., the problem might be manageable. But inevitably, and operating in an interdisciplinary field we also confront the possibility of conflicts with our sister societies' conferences, the impact of which is oftentimes more devastating to attendance. More than once, I know we've rescheduled some events to avoid a major AIAA meeting, the Design Automation Conference, the NCC (when it existed), and the IEEE AI Conference. Those organizations have done the same thing. But we're all trying to provide services to different segments of the same marketplace with all the constraints of hotels, space, price, and location. I know one organization that is scheduling out 20 years in advance on its annual meeting! And when a group like the IEEE schedules 35%+ of its total annual number of conferences (numbering into the hundreds) into an 8-week window of mid-September to mid-November--a convenient time for most professors and paper presenters--conflicts are unavoidable. Less than 2% of IEEE meetings are scheduled in August, by the way, and we all know what its like in Europe in August! This is not to say that improvements cannot be made. Umbrella organizations like IFIP, AFIPS, AIP, AAAS, and others have started preparing consolidated calendars of events of their constituent organizations. We consult them frequently, but they are only as good as the information provided to them by the original society. The problem is universal; IFIPS' own working group meetings occupied something like 17 pages of the last calendar I saw! There is no central clearing house for ALL the meetings going on ALL over the world, notwithstanding several dozen monthly requests I personally get from the commercial boys saying they have THE definitive book on upcoming world events. No solution here, Francois, but also not mismanagement. If anything, it's healthy competition. Regards, Chip Stockton ------------------------------ END OF SIMULATION DIGEST ************************