YetiSim Blog

Today was my last day at Spring Sim.  I attended most of a talk in the morning, which was actually a workshop on conceptual modeling.  I arrived late (I’m so exhausted from this conference, I didn’t expect that).  When I arrived, Dr. Heavey was presenting his work, and he discussed various approaches studied.  These included Petri Nets, and UML State Machines.  After his talk, I commented on how UML state charts are very similar to what he was describing.  This brought an eruption of laughter from the audience, although I had not finished my comment and question.  It was rather annoying, since YetiSim uses a modified version of UML for modeling.  I expect that at least some parts of YetiSim’s execution graphs could be useful.  You see, this is why they are not called state machines anymore, and are execution graphs now.  People presume that they know what you are talking about, when you say “modified version” they don’t ask how it is modified, they assume it’s something small, not a radical shift of ideas.  During the break, I obtained some contact information for Dr. Heavey.  I would like to learn more about his work, and I intend to read his paper.  However the break time conversation was dominated by discussions of the problems, with an emphasis on why UML is horrible for modeling.  I admit I don’t have enough of a background in conceptual modeling to have an intelligent argument, but I would have enjoyed the conversation.  This is why I shouldn’t use the word UML and will never use the word “state diagram” in association with how YetiSim runs.

The workshop featured other presentations, including one from Boeing and NATO.  The talk from NATO was interesting, and the presenter outlined their goals.  The presenter from Boeing was very energetic, although the bottom of his slides had something stating to the effect that disclosure of details was forbidden except under conditions presented in the title slide (which I wasn’t in the room to see).  In my opinion, such disclaimers have no place at an academic conference  They belong to select groups behind closed doors.  The presentation from Boeing was very interesting, I just didn’t like the caption at the bottom of the slides.  It’s interesting just to hear how much Boeing uses simulation.

Otherwise, I checked out of the hotel today and spent some time reading before departing on the train back home (which is where I’m writing this right now).  Deborah has expressed interest in forming a working group at U of T on conceptual modeling.  I think that would be a great idea, and the work of the group could benefit both YetiSim, and give an opportunity for U of T to become more involved in simulation.  U of T is fairly open to interdisciplinary pursuits in my experience, and it would be wonderful to have a group composed of engineers, computer scientists, cognitive scientists, and others to examine methods of simulation modeling.

Another problem with YetiSim came up today.  It has no ability to pre-empt tasks.   I have to figure out a solution to this one.  Also the interconnection of entities is not something that has been well planned, when you have things that are interacting with each other.  The example presented was a tug boat and a tanker, which require interactions with each other for an effective simulation.

A few presentations discussed semantic web, and it sounded like something interesting to explore.

Overall it was an interesting experience, this was my first conference.  I look forward to collaborating in future with the people I met at the conference.

Today I attended a talk on DEVS.  The presenter implemented a DEVS-RMI model for his PhD.  It was early in the morning and I was tired, others were yawning too (it was a late night).  The presentation didn’t focus enough on DEVS itself, it was supposed to be a tutorial on DEVS, instead it was a sales pitch for DEVS-RMI.  I don’t know anything about DEVS, so it was tricky to follow although I got some interesting ideas.  Some of the slides were missing labels on the axes, so it was really hard to figure out what I was looking at.  From what I saw about DEVS, it looks interesting although overcomplicated.  I want to look at ADEVS and CD++ to see how they implement time increments.  I’d also like to benchmark YetiSim against them to see how it performs.  DEVS seems to lack parallelization within its formalism, so that would be a problem.  One question I had, that wasn’t answered by the presentation was whether or not the DEVS formalism can implement a Turing machine.  I suppose that a Turing machine can be simulated, but it’s not quite the same.  I suspect that since DEVS is based on state transitions, this is not the case.  I will have to research further to understand this.  The DEVS tutorial really pushed the point that the simulator could be separated from the model and system, and I took that to mean the class design and simulator.

This presentation let me see something in YetiSim I overlooked…I have no method  of obtaining a signal from the outside environment without waiting for it explicitly.  It just occurred to me during the discussions that I forgot to plan for this functionality.  Another part of the talk that was interesting was the fact that DEVS can model both continuous and discrete systems.

Deborah and I presented YetiSim today.  Unfortunately the conference did not organize the poster presentations well,  so only a few people really attended it.  The poster session was hosted during sessions, and the coffee for the break was in a different room.  I didn’t get the audience I had hoped for, but ah well enough people were interested!

I talked with someone who had a very interesting insight, he labeled YetiSim as an “application level virtual machine”, which is a very good description of it.  Although YetiSim lacks an interpreted language, in a sense it’s acting as if it is interpreting bytecode.  I wonder if YetiSim could therefore do something like a JIT compiler?  An interesting concept, that I could extract the code I needed, compile it, and dynamically link it in at runtime… and voila I have something that gets faster!  The cost of compilation would have to be recovered however…. although I could certainly allow the user to pre-compile their execution graphs…. an interesting concept indeed…

I received a lot of feedback.  The parallel performance of YetiSim was a disappointment for many, and I expressed that this is the exact reason why research is ongoing.  With sufficient tools, YetiSim will improve.  I already have so many new ideas for how to improve performance from peer feedback, it was really nice to have other simulation people to talk to.  I definitely feel like we are going in the right direction, although I see there are things YetiSim doesn’t do yet that it really should.  I’m anxious to get a new computer to continue to work on YetiSim.  More people were actually interested in TBB than YetiSim though.

After the poster session, I went out with Dr. Buyya for the evening.  We walked to Hull, and back to Ottawa.  We also discussed GRID computing and what GRID-enabled simulation would look like.  We disagree a lot on how GRID technologies should be implemented… strongly disagree actually.  Dr. Buyya is a strong advocate of GRID technologies implemented in .NET, and this is the wrong approach to me.  Quite simply, I do not trust any corporation which would flaunt software patent violations without merit, and threaten the industry with lawsuits.  Perhaps I have a prejudiced against .NET for fear of company software patent intimidation, and hence the potential problems with the use of mono.  If I were implementing GRID stuff, I would be using Python and C++.  Language and platform debates will always be there, but we agreed on concepts.  We went for dinner at an Indian restaurant, it was pretty good (but spicy, and I wasn’t used to it).

This week I am attending the SCS Spring Sim ‘08 conference in Ottawa, Ontario. This is the first conference I have attended, and tomorrow Deborah and I are presenting a research poster on YetiSim. Along with the poster, a short paper on YetiSim has been published with the proceedings of the conference.   I have been to Ottawa a few times, so I wasn’t too excited to see the city, but next year the conference is in San Diego which would be neat.

I attended a talk by Dr. Rajkumar Buyya about GRID computing and GRIDSim.  I remember looking at GRIDSim some time ago, when I originally researched GRID and Beowulf simulators.  It is implemented in Java, so the performance of the simulator likely will not be very efficient, at least if it is a discrete event simulation with a large number of entities.  I also attended the keynote talk, but it was early in the morning and I needed some coffee (apparently in short supply here).  The keynote talk focused on psychology experiments with the effectiveness of HUDs on reaction time.  Unfortunately not quite in my interests, but there were some pretty pictures, and it would be neat to play with a helicopter simulator just to see how quickly I crash it.

This afternoon I had a break from proceedings, since there weren’t any papers that looked very interesting (and my attention span is really short I’m afraid, unless the topic is super interesting).  I met representatives of CAE today during my break.  Their research and products seem to be inline with the type of simulation work I am doing.  It looks like it would be an interesting place to work for a summer, but I wouldn’t sign a contract which limited my ability to work on YetiSim, so it wouldn’t be likely.  I also met some people from Concurrent  who gave me a Tux penguin toy (which I like very much).  They are doing a real-time Linux operating system, but they do some type of electronics simulation that gave me an interesting idea.  Really what they do, is allow simulated electronic inputs or something to be part of the simulation (sorry, attention span is skipping some of the details there).  But anyhew, YetiSim could easily be extended to receive input from virtual devices or real ones for simulation by allowing the state executions to be an input.  Wouldn’t be that bad to do actually, and might still benefit from parallel processing.

I got a lot of interest  in YetiSim today, and sat down with professors from Dalhousie and Victoria University.  I met a few people who are interested in health care simulation, Deborah’s field of research.  We went over YetiSim in great detail for about an hour and a half.  It would be awesome if I could get funding for the summer to just work on YetiSim full time, there seems to be some excitement about it.  We’ll see tomorrow when we do our actual presentations what the interest level is.  I hope that people will be as excited about YetiSim as I am.  I’ve actually been surprised how interested people are in something like YetiSim which is open source and all about performance.  It’s very encouraging.

I met Dr. Buyya, which I discussed a bit earlier.  A very nice man from the quick conversation I had with him, I’d like to spend some time with him to just discuss ideas.  I actually had considered doing my masters with him at one point, maybe I still might who knows.  I would love to study in Australia.  An interesting conference overall, not enough food though, or social events to mingle.  Lots of ideas and energy floating around though.

A few years ago, I read about the Intel Itanium processor.  One of the ideas that stuck with me was branch prediction.  The concept in my head is likely different now than what the processor actually does, but the idea is what is important here.  When a branch is encountered if we guess an execution path, we can start processing as if we should proceed down that path.  If our guess is wrong, we take a minor hit in performance.  A correct guess could result in a substantial performance gain.

The YetiSim state machine has guarded transitions, that are a lot like branches.  If we are able to guess which branch we will proceed along, then we could begin processing as if that is the correct path.  This is an example of how YetiSim performance can improve by further refinement of the implementation, without affecting the user interface.  I like this capability within YetiSim, since I believe simulation users (like processor users) should not be overly affected by the new architecture.  Readers knowledgeable about the Itanium could certainly point out problems with my analogy right now, but let’s just stay focused on YetiSim.

Branch prediction within YetiSim has a natural mapping to the state machine execution.  Statistics would have to be gathered during execution to improve the predictions made.  Fortunately,  YetiSim will be bundled already with just the tools required.  This is not something that I would do however, I would have to ask someone with more statistics experience than me to build the models for the branch predictions.  This is something that I would like to experiment with, after YetiSim becomes more stable.  The goal is to construct a stable simulator right now, not to wander around with a never ending list of desired features.  Still, this is a glimpse of the possible future of YetiSim.

A more immediate use of the branch statistics, is to dynamically adjust the order of branch evaluation so that the list of guards to consider is sorted by most frequently taken transitions.  This will reap some benefits at minor cost, and is easily implemented.

I’m not entirely sure about the details of the branch prediction, I have some ideas that I will outline but will not discuss in detail right now.  One of the ideas I have been toying with, is to separate out data from YetiSim so that it could be stored in a database.  Alternatively, it could fall back to just ordinary memory allocated from the heap.  The main idea is that if users restricted themselves to using YetiSim data storage constructs, that data could be saved elsewhere.  The execution of state machines could be captured with a data snapshot, and a database which provides transaction support could be used.  Only the correct path is committed to the database, the other transactions are silently discarded.  I’m not a database expert, someone else would have to provide the details here… but this is a general idea which could be of use.  Unfortunately it has disadvantages too… classes must use YetiSim data storage constructs.

Anyways, here’s a glimpse of what I’m thinking about.

I went through a couple of libraries at the University of Toronto last night to pick up some books on simulation. It is natural to wonder what will make YetiSim any different, when there are likely thousands of different simulation frameworks. It seems that everybody who writes a simulation writes their own framework. Browsing through the books, I found many different papers and books on distributed simulation and simulation techniques. So, is it just arrogance on my part to believe that YetiSim is anything more than another simulation framework? Considering the number of people who have worked on simulation engines, how could I possibly hope to improve upon their work? What makes YetiSim so special?

I don’t think it is arrogance to believe that there is room for another simulation framework, and that YetiSim is different. I’m not sure that YetiSim possesses advanced technology. YetiSim does not have many users (actually none), so what could possibly set it apart? Well, for one YetiSim was not constructed for a particular purpose. This means that YetiSim has been constructed without time constraints, and without a motivating project. This means that rather than developing the simulation framework as an aside for the sole purpose of conducting research, the simulation framework itself has been placed first and foremost in development. My role is to create a useful simulation framework, not to build a framework for a particular simulation.

YetiSim is still being constructed and designed, so I cannot give a list of ways that is different. However, there are a few areas in which I would like YetiSim to be different:

1. Testing: YetiSim will be tested thoroughly, to ensure that it works correctly. The testing strategy is one of the most important aspects of YetiSim, as others will be relying upon it for meaningful results that are correct. It is my intention to design a full test suite that will satisfy users that the software has been tested and functions correctly.
2. Documentation: This is one area for which YetiSim has already received praise. YetiSim will be documented thoroughly, including the internal mechanisms, usage, design, and testing. This will encourage others to investigate the internals of YetiSim, and to understand how it functions precisely.
3. Open Source: Although I am not satisfied entirely with the GPLv3 license for YetiSim, the open source nature of YetiSim ensures that others will be able to investigate the internals. Simulation serves a scientific purpose, and it is important that YetiSim as a library may be trusted. Thus, any doubtful person may see how YetiSim arrived at a particular result. Also, there is no licensing nonsense to restrict how you use YetiSim (except for the fact your simulation has to be GPLv3, but that’s something I’ll blog about later… I’m not happy with that right now).
4. Clarity: YetiSim strives to be easy to understand. That is, the user should not have to employ patterns of tricks to make their simulation work. Users should be able to easily understand what YetiSim is doing under the hood from a high level, even if they themselves do not ever look at the implementing code. Users should be able to concentrate on just writing their simulation, and not worrying about details of limitations of YetiSim and C++.

YetiSim is still a very young project. It is difficult to say right now how it will stand apart, because it is not yet sophisticated enough to be used for real simulations. In time, I think we will all see what makes YetiSim special. I would also encourage you to become part of the YetiSim project, and provide your input and help to make it special.