As I mentioned in my introductory post, I started down this road as a software engineer turned simulation practitioner, who thought he might be able to build a better – or at least different – mousetrap. Which naturally leads to the question: what am I trying to do differently? You might be tempted to translate that into “What are your requirements?”, but at this stage, I prefer to think of them more fuzzily as goals. I started off with five:
- Support both process and agent-based modeling. In brief, this means allowing model behavior to be defined from either or both of two perspectives; the processes being executed by the system, or the agents controlling or performing those processes.
- Support the modeler’s ability to define model behavior in a natural way using an existing programming language – when code is the best way to express that behavior. Where it makes more sense to define behavior in terms of data (textual or graphical), do that.
- Support modeling component re-use through object-oriented and object-based design. Leverage object-oriented model component design to support natural aggregation (and de-aggregation) of simulation outputs. If, for example, process are defined in terms of a process class hierarchy, that hierarchy provides one way to aggregate results from related, but different processes.
- Support the notion of location (and location hierarchies) as a second type of model component decomposition. The concept of location often provides a natural framework for grouping heterogeneous model components – or subgroups. Location hierarchies also provide a second axis for output aggregation and reporting, along with another avenue for re-use.
- Take advantage of multi-core hardware, but not at the expense of ease-of-use or model development. The number of processing cores available on our desks – or laps, or in the palms of our hands – will only continue to grow. Given the generally compute-intensive nature of simulation applications, it would be crazy not to make every effort to take advantage of those resources. That being said, I’d prefer to do so in ways that don’t create additional work for or constraints on the modeler.
I’ll be discussing each of these in future posts. No doubt I’ll also be refining and adding to this list as I go along. I realize that none of these goals are truly novel, but I hope to implement them in some different and hopefully useful ways.