I just gave Loopy a try, after seeing Gene Bellinger’s post about it.
It’s cool for diagramming, and fun. There are some clever features, like drawing a circle to create a node (though I was too dumb to figure that out right away). Its shareability and remixing are certainly useful.
However, I think one must be very cautious about simulating causal loop diagrams directly. A causal loop diagram is fundamentally underspecified, which is why no method of automated conversion of CLDs to models has been successful.
In this tool, behavior is animated by initially perturbing the system (e.g, increase the number of rabbits in a predator-prey system). Then you can follow the story around a loop via animated arrow polarity changes – more rabbits causes more foxes, more foxes causes less rabbits. This is essentially the storytelling method of determining loop polarity, which I’ve used many times to good effect.
However, as soon as the system has multiple loops, you’re in trouble. Link polarity tells you the direction of change, but not the gain or nonlinearity. So, when multiple loops interact, there’s no way to determine which is dominant. Also, in a real system it matters which nodes are stocks; it’s not sufficient to assume that there must be at least one integration somewhere around a loop.
You can test this for yourself by starting with the predator-prey example on the home page. The initial model is a discrete oscillator (more rabbits -> more foxes -> fewer rabbits). But the real system is nonlinear, with oscillation and other possible behaviors, depending on parameters. In Loopy, if you start adding explicit births and deaths, which should get you closer to the real system, simulations quickly result in a sea of arrows in conflicting directions, with no way to know which tendency wins. So, the loop polarity simulation could be somewhere between incomprehensible and dead wrong.
Similarly, if you consider an SIR infection model, there are three loops of interest: spread of infection by contact, saturation from running out of susceptibles, and recovery of infected people. Depending on the loop gains, it can exhibit different behaviors. If recovery is stronger than spread, the infection dies out. If spread is initially stronger than recovery, the infection shifts from exponential growth to goal seeking behavior as dominance shifts nonlinearly from the spread loop to the saturation loop.
I think it would be better if the tool restricted itself to telling the story of one loop at a time, without making the leap to system simulations that are bound to be incorrect in many multiloop cases. With that simplification, I’d consider this a useful item in the toolkit. As is, I think it could be used judiciously for explanations, but for conceptualization it seems likely to prove dangerous.
My mind goes back to Barry Richmond’s approach to systems here. Causal loop diagrams promote thinking about feedback, but they aren’t very good at providing an operational description of how things work. When you’re trying to figure out something that you don’t understand a priori, you need the bottom-up approach to synthesize the parts you understand into the whole you’re grasping for, so you can test whether your understanding of processes explains observed behavior. That requires stocks and flows, explicit goals and actual states, and all the other things system dynamics is about. If we could get to that as elegantly as Loopy gets to CLDs, that would be something.
4 thoughts on “Loopy”
A reader asked, what would I recommend as an alternative? My answer:
If I had a different tool in the same class to suggest, I would have suggested it.
Vensim builds good causal loop diagrams, and it won’t mislead you by simulating them incorrectly, because it won’t simulate them at all unless you specify an underlying dynamic model.
I’ve used it with 9 year olds, though the barrier to entry is obviously higher. (Disclaimer: I work for Ventana.) Insightmaker and other tools that can simulate a system accurately will tend to have the same limitation.
Lack of alternatives does not absolve Loopy of the fundamental requirement of any simulator, which is to deliver sensible results. If the mapping from diagram to behavior is incorrect, or at least incomprehensible, there’s no way to learn from the gap between your mental model and simulation output.
So, I recommend that you feel free to use it as a “gateway drug” for diagramming simple systems; for one-loop linear systems simulations should be reasonable. Also feel free to use it to diagram multi-loop systems and talk about them. Just don’t expect simulations for multi-loop or nonlinear systems to make sense, and warn your subjects to that effect.
What I really recommend is that someone rework the software to simulate multiple loops one at a time. That would actually make for better storytelling, without risk of spurious results. You could even enhance it to generate an English narrative of the outcome, step by step.
Tom, I saw you assessed “Loopy”. I would be interested to read your assessment of the “iModeler” (https://www.consideo.de/). As you can see, it is a software promoted by a German company. There are instructional texts in English, however, which might help. For your kind willingness and effort, I thank you cordially.
I don’t really have time to do a detailed assessment at the moment. Is there anything in particular you find interesting about it?