Sysdea modelling is based around a few simple principles which can then be used to create powerful results. This guide will take you through building a simple model of a bathtub being filled and drained, to introduce these ideas to you. More in-depth technical information is linked to from each stage for reference.
Once you're logged in, you should see the models table, and a button around the middle for creating your new model, which will then take you to the main workspace.
We can then change the time settings. Sysdea time is simple units that you can treat as whatever makes sense for your model. Here, we'll have our model run over 30 minutes.
In Sysdea, the core idea is to model around something which can accumulate and deplete over time. This could be your bank account, the number of staff or loyal customers in a restaurant, or in our case the amount of water in a bathtub.
To create a stock, right click on the workspace and select Add Stock (this can also be done by using the shortcut key 's'). Clicking on our newly created stock will then open the inspector.
This has a number of options and fields, but for now we're just interested in giving it a better name, and starting it off with some water. A quick search suggests an average bath can hold up to 150 litres, let's start it off with 20 litres and fill it up from there. First, enter
Bathtub as the name, and then enter
20 as the formula. For stocks, the formula is only used to initialise, after that only flows can affect the value of our stock.
You can then click anywhere on the workspace to dismiss the inspector. You should now have a bathtub that stays at the same level for 30 minutes.
Let's get a tap running into our bath, which we can represent with a Flow. To add a Flow, you can use the right click menu (or the shortcut 'f'). We'll place it to the left of our
Bathtub. If you need to move an existing element, you can click and drag the centre.
The options on a flow differ slightly from those on a Stock, but the core fields are the same. Another search suggests a tap can flow for 8-12 litres/minute. Lets name our flow
Tap and give it a formula
10, then dismiss the inspector.
So far this hasn't changed anything, because our flow isn't connected to our Stock. To connect it, click and drag the arrow of the flow onto the stock. The model should update to show our now rather-overflowing
Bathtub ending up at 320 litres. Whoops.
We want to turn our
Tap off when
Bathtub gets to a certain level. To do this, we can make the
Tap formula smarter, by deciding how much
Tap will flow based on the current level of
Bathtub. To add a link from
Tap, hover your mouse just outside of the Stock (a grey halo should appear) and then click and drag a link over to our Flow.
Tap inspector should now show an unused reference to
Bathtub. Clicking on it will add the reference to our formula, which has the syntax of double quotes around the name. Setting the formula to be
"Bathtub" will send our water level shooting off into space, as an out-of-control feedback loop. What we need to use is a conditional to check the level of the water and turn our tap off if it's too high.
This can be achieved by using this formula, which lowers our flow rate to 0 when the
Bathtub level is above 80 litres.
if "Bathtub" > 80 then 0 else 10
If you make that change then happily the tap will turn off and our bath is no longer overflowing. But why is our bathtub 90 litres full, and not 80?
You may have noticed a setting in the model time settings panel earlier, called Resolution. By default, a model will be calculated once at each time period. So when our flow checks the level and sees it's 80, 80 isn't greater than 80, and so it continues to flow. But it isn't checked again until all 10 litres of its flow have gone into our tub. A simple solution would be to change our formula to check for greater than or equal to (
"Bathtub" >= 80) but this relies on our flow rate nicely dividing into our target level.
Upping the Resolution will run the model in smaller time-slices, and give better accuracy for continuous processes like our tap. Setting it to
10 lowers the accidental overflow down to 1 litre (a total of 81), because time is run in 1/10 steps, so only 1 of our 10 litre flow rate can occur before it checks again.
So we have a model of our clever tap that turns itself off when the water gets too high, but we've hidden a lot of information inside our formulae, such as what level we want the water at, and the flow rate of the tap. We can pull these numbers out into Variables to expose this information in our model, and possibly make it a decision that can be changed. Let's add a variable through the right-click menu (shortcut 'v') and connect it with a link to
Tap just like we did with
Open the inspector for our Variable and call it
Desired Bathtub Level, with a formula of
80. Now we can edit the
Tap formula to use this variable instead of 80, changing the formula to:
if "Bathtub" > "Desired Bathtub Level" then 0 else 10
We've now covered most of the basic elements upon which Sysdea models can be built, but an important core topic is the concept of feedback loops. Our model is currently still very linear, with no particular insight you couldn't glean from multiplying and dividing a few numbers. Let's add some non-linearity to our model by adding a plug that drains based upon the current level of
Add a flow to the right of
Plug, then connect its source (left) arrow to
Bathtub and add a link from
Plug, like so:
For demonstration purposes, let's say that the plug drains a certain percentage of the Bathtub. To start with a 10% drain, set the formula of the
"Bathtub"*0.1. Now it takes about twice as long for our bath to fill to our desired level. And at 15% (
"Bathtub"*0.15) it never quite fills in our 30 minute simulation.
This setup shows a negative feedback loop on
Bathtub, whereby the more it grows, the higher the drain on it from
Plug becomes, so it will reach an equilibrium if the flows into
Bathtub are stable. A common positive feedback loop is interest rate on a bank account.
On their own these feedback loops can be straightforward to predict, but when they interact with each other, changing conditions, and conditional behaviours, models can give great insight into these complicated systems.
[further links, references, etc]