Updated: Jan 23, 2022
In this post we want to discuss some of the potential issues that can arise from trying to simplify simulation modeling through the creation of predefined blocks. What are the things you need to be aware of, some interesting aspects of this approach, the potential pitfalls and how to manage around them.
When Jaco-Ben Vosloo asked me to be a ”guest blogger” here at the AnyLogic Modeler after our discussion on LinkedIn I thought, "Why Not? I have never blogged before". There is a first for everything!
So here we go! :-)
In 1988, with a fresh M.Sc. degree, tilting towards Applied Mathematics,
Operations Research, Systems Theory, …, I landed my first job. I started working for a consultancy, targeting the Swedish industry, and therewith simulation. I focused primarily on all types of industries, but I had colleagues that focused more on railway modeling.
The picture here is from an article, with the title “Discrete simulation – The crystal ball of production technology, even though a bit foggy” I wrote 1989, published in the magazine Automation.
The team I worked with had the common denominator, to all use DEMOS as our modeling platform.
DEMOS, or Discrete Event Modeling On SIMULA, is a package put together by Prof. Graham Birtwistle to further enhance the simulation toolbox when modeling with SIMULA. DEMOS gave users a whole bunch of predefined procedures, classes, etc. that you used - combined with regular SIMULA code to create simulation models. A bit like a predefined library in AnyLogic.
For those that are unfamiliar with this programming language (SIMULA), it is often considered to be the first real OOP (Object Oriented Programming) language (Java is arguably the more familiar OOP language nowadays).
A DEMOS model had a structure in line with the example shown here.
The Entity was the key structural building block and the logic – or process – defining the behavior of an entity was put inside it, using SIMULA code combined with predefined objects and procedures (functions). I usually claim that SIMULA to a large extent combined what today would be called ABM (Agent-Based Modeling) with DEM (Discrete Event Modeling). Seeing these as different paradigms is, in my opinion, one of the really big mistakes in the evolution of dynamic modeling. The reason for this is that we obviously often need to combine Bottom-Up with Top-Down thinking/logic in the same model. For us – formed by modeling using DEMOS – this division did not exist and we learned that “anything could be modeled” given a good enough platform.
The start of Blockification...
Now I want to philosophize a bit related to the phenomenon called ‘blocks’ – and as seen above, I usually call building logic using blocks blockification. In the early 1990’s, I and three of my colleagues had a meeting with an Englishman. A clear memory fails me, but I think he in some way was connected to Cambridge. He told us – enthusiastically – that he was investigating, researching, or whatever, how to package logic in blocks that in some form were supposed to be connected to each other …!
We probably looked a bit dumbfounded – and even though we were too polite to laugh in his face, at least I did so within. Because it was so obvious that you could never ever get even close to the level of flexibility (and thereby model quality) an environment like DEMOS could provide if you limited yourself to structures that were predefined.
I still hold that for true, only really challenged by one modeling platform (to my knowledge) nowadays, AnyLogic. The reason AnyLogic can challenge is primarily two-sided:
all paradigms can be combined
sophisticated object-oriented code can easily be integrated into the blocks, to create the dynamics and flexibility often needed.
The image below (and others in this blog post) comes from a workshop and a presentation I had at the Winter Simulation Conference 2018, in Gothenburg. Here I tried to reason and discuss both the pros and the cons related to blockification – which is the point I want to raise with this blog.
Now, let's discuss the advantages, and more importantly the disadvantages of blockification...
My guess is that most modelers of today can’t really imagine modeling without the help of blocks and predefined structures – just as kids have a hard time conceiving a world without smartphones. There are of course advantages with blocks, even though I might not be the strongest advocate. So let us start considering what these pros are – at least according to my point of view.
Efficiency and speed of modeling A library of well-designed blocks most certainly is a help, but ‘well-designed’ is the keyword. With it, I mean that the block as such must be flexible and the possibility for the modeler to tailor-make the block should be there. If this is the case, then yes – it helps us both from an efficiency and a speed perspective. But with a poorly designed block, it might actually contribute to the opposite, hindering us and slowing down the modeling endeavor.
Simplification of modeling – and modeling made available for more A car design where we do not have to get our hands greasy is in many cases more simple to handle - but it hides the real logic of how a car works. Similarly a program with a lot of icons will often make it easier for the user. Blocks are usually simpler to handle than code and will simplify for those that do not already have the relevant competence, and thereby the market of potential modelers will grow. But this is not by definition a good thing, which I emphasized at the Winter Simulation conference 2018 and will elaborate on below.
The possibility to visualize and explain the logic of a model Given my background and view of blockification, you see that I have even made reservations for those bullet points above that I call advantages. For me, this third point is really the only true advantage, compared with DEMOS modeling. But it is a clear one, unfortunately not realized by so many, according to my experience. When we model purely with code, DEMOS or more modern alternatives – there is a very obvious problem. We hide the logic of our model inside a program, using code that our stakeholders in many cases can’t interpret. The focus of modeling – and simulating – should almost always be to support decision-making and a general understanding of the issue, the system (that we have modeled), and the consequences (of various alternatives). A perfect model or good results are no ends in themselves – if we are not able to make the managers and individuals that are supposed to act upon what we provide trust the model and results! And to make others trust what can be concluded with a model, we must in many cases – especially in relation to more senior decision-makers – be prepared to “prove” that the model is built around a relevant understanding of the issue at hand. And how do we do that with code? So here is the single and most obvious – at least for me – benefit with blocks. We can visualize the logic of our model so that others can understand it!!! But also here I must add a question mark – because what I just claimed of course only is possible if the used platform (built upon blocks) makes it possible to visualize the blocks. In AnyLogic this is the case, but as I understand it, not with all software on the market. Below I have enclosed another presentation slide, claiming that visualization is much more than animation.
Now I have been positive enough – trying to lift various advantages! ;-) Let us take a look at the other side of the coin.
The loss of flexibility We are back to my reactions of the early 1990’s – we inevitably lose some flexibility and the only way to prevent this from having a clear negative impact, is to have a well-prepared way to easily mold the blocks according to our needs (most likely by using code).
The negative impact on modeling competence Making something simpler has of course potential to add value and be something positive – but there almost always is a cost to put in the other weigh bowl. Modern cars are in one way simpler to handle and maintain, but on the other hand, the mechanics of today risk being less skilled than the old-timers. Hand calculators made calculation simpler, but most likely made the average pupil less talented in mathematics. This is really the case for most simplifications – and of course also when it comes to dynamic modeling. Working with blocks partly removes the thought process that previously (before there were blocks on the market) was needed – the process of fully understanding the issue at hand, capturing the studied system with a logic of some sort. So everything else being equal, a modeler formed by a blockified platform will risk becoming a weaker modeler than one formed by a non-blockified environment. So if I had a time machine handy, I would without any doubt like to take the small modeling team I myself belonged to 1988-1993, transport that team (including a younger version of myself!) to today, and arrange a modeling challenge towards most current modelers – where I would be prepared to bet a considerable amount of money on the “winners”.
It is hard to prove me right – or wrong – related to that thought experiment. But my point is making things “too easy” will have consequences. And not only positive ones.
Another twist of this is that making simulation available for more might have positive connotations from a market share perspective, but not from a competence or professional perspective. I sometimes make the partly silly analogy, that technology might be sophisticated enough to allow us to conduct some type of brain surgery at our kitchen table – perhaps by using some smart app?!! That the possibility to provide this opportunity exists is not by necessity the same thing as claiming that this would be a good idea though …!
And the same, I claim, can be said related to simulation modeling. Being able to make simulation modeling available for more (using blockification etc.) does not imply that it is a good thing to do this. Simulation modeling should be seen as a profession – demanding talent and having modeling as the primary focus work-wise. Simulation modeling is not, not even close, to be compared with the construction of spreadsheets in Excel. The latter can be handled by many and can therefore be software available for most. The former should only be handled by a few – but the benefits (which are enormous – but only given talented modelers) spread to many!
So first I claim that the majority of those having access to simulation modeling software probably shouldn’t – if we care about the profession and quality of the models (and whether the simulation projects do more good than bad). An Arabic full-blood should not be ridden by anyone – but it should be admired by many. Secondly, I claim that those that have modeling as a profession are given poorer opportunities to become “modeling full-bloods” – since they are to some extent blocked from the opportunity to learn fully how to “think”, given that simplified structures are presented for them. These two factors together risk hurting both the modeling profession and the wonderful opportunities with dynamic modeling and simulation – in the long run!
The slaughtering of what is meant with an Event In a previously shared slide, focusing on blockification, I also lifted the quite severe issue related to the distortion of the view of what an ‘event’ is and stands for – and this most certainly has nothing to do with entering or leaving blocks. But the trend of using blocks has caused this twist of what an event is – and this has made an already clear problem even more severe, the issue of synchronizing events taking place at the same point in time (which was a key challenge in discrete modeling, also before anyone had heard of blocks). So with blockification – which by most (all?) modeling platforms causes unnecessary “events” to be created – the synchronization challenge has increased exponentially. And as a consequence, the hard-to-crack situations when a model that ought to work behaves illogically have become more common. From a more aesthetic point of view, it is a shame that the foundation of discrete modeling – the event – has been so mistreated.
The cementation of a Master-Slave relationship Working with blocks, really related to the DEM paradigm, implies that the blocks and the process defined by them are made “master” over the “entities”, that are supposed to flow through the blocks. The blocks and the system/process description is made active Masters, the entities more passive Slaves. Predefining if an object is supposed to be active or passive limits the levels of freedom when modeling – and this choice (active, passive or both) is not something the paradigm or platform should meddle with. It should be left to the modeler. In the blockified world we live in, the only way to truly cope with this is if the bottom-up opportunities with ABM is offered in combination with the top-down approach, given to us by DEM. But as noted previously, the real problem is the division into different paradigms at all. What we all the time have needed, is a Paradigm-Free approach. Master-Slave relationships are otherwise a classical challenge, where the wit and taste of the modeler (working with DEMOS) influence which entities should lead and which that should follow. And in some cases, the roles toggled, based on the state of the system during simulation.
The loss of the possibility to model conceptually My final reflection related to cons with blocks, is about the rudimentary need to model more conceptually. It should always be possible to quickly create an executable model that roughly captures the more conceptual system challenge when struggling with an issue. We are here talking about the possibility to draw a dynamic picture with a very broad brush, in less than an hour (or just a few). I guess the problem here is not blockification as such, but rather how many platforms have implemented blocks, without the flexibility needed. I realized this a few years ago, when I should jot down a business proposal for a very basic challenge, preferably handled conceptually, where the whole modeling effort ought to take just a few days. The modeler, formed in modeling and simulation through a platform without several of the key traits a good modeling environment should have (at least according to me), was totally perplexed. He claimed he needed 1-2 days just for preparations – so that he then could start to model. Thinking conceptually was totally unfamiliar. AnyLogic of course provides the opportunity for this, as well as a few other platforms I assume, but there are quite a few that don’t. When adding a logical block, some demands that an animation of the block (e.g. a machine) is also added. And some have other quirks and formal requirements, blocking the opportunity to swiftly build conceptual logic – that most often should not be animated. With AnyLogic being based on Java and having the ability to not only use and write code everywhere but also import and use standard Java libraries you get the best of both worlds (If you know how to use them ;-) )
To wrap it up!
Enough is enough – and I have probably taken up too much of your time already. I conclude with another slide, also from WSC 2018, that captures some key insights you got by learning to model without blocks, with DEMOS. The slide brings up some of my reflections above.
Best of luck with the modeling – with or without blocks!
Stefan Bengtsson is a guest writer for the AnyLogic Modeler. Feel free to connect with him over LinkedIn.
If you liked this post, you are welcome to read more posts by following the links above to similar posts. Why not subscribe to our blog or follow us on any of the social media accounts for future updates. The links are in the Menu bar at the top, or the footer at the bottom. You can also join the mobile app here!
If you want to contact us for some advice, maybe a potential partnership or project or just to say "Hi!", feel free to get in touch here and we will get back to you soon!