# Simulation Principles

## Simple Flows into Stocks

Sysdea simulations are driven by the interaction of stocks and flows. At each time step, flows will be calculated, and their results will affect connected stocks in the period up to the next step. For example, a flow of value 10 between two stocks, the source being initialised at 100:

We can see that `Stock 2` has increased in value by 10 between time step 0 and time step 1, and conversely `Stock 1` has decreased by the same amount.

## Resolution

When there are feedback loops between stocks and flows, the frequency of calculation can be important for accuracy. Consider the simple system of a flow that drains a stock by half each period:

Naively this seems accurate, as at each step half of the stock has been removed by the flow. However, if this is a continuous process, then in the reality of the situation, there is going to be less than 100 in `Stock` at every time except exactly 0, given there is an outflow. So the average flow rate during the first period has to be less than 50, if the flow is truly draining at a 50% rate of the stock at any one moment.

Resolution is a setting in the model time settings which allows the simulation to be run in smaller intervals during a period, with the Resolution value being the total number of calculations per period. A Resolution of 2 would add an additional calculation at time 0.5, a Resolution of 4 would have extra calculations at 0.25, 0.5, 0.75, and so on. Upping the Resolution for our model to 8 shows an improved result, with only ~40 of the stock drained over the first period:

Note that there is much less difference in result between a Resolution of 8 and 1000, than there is between 1 and 8, even with such a drastic feedback loop of 50% drain. For most simulations a Resolution of 4-8 should suffice for reasonable results. Also note that it is now harder to see the validity of the link between the flow rate and the current stock level, due to the added calculations going on in-between steps.

## Immediate flows

For some simulations, the delayed nature of a Flow is not suitable. For instance, a bank transfer, although it can have a small delay, takes effect immediately when it occurs, and does not occur spread out across a time period. A flow in immediate mode will move its value from source to destination instantly.

This small video shows the difference made switching between continuous and immediate modes on a flow. Although the stock has an initialisation of 100, in immediate mode it is instantly drained by 25 during time 0.

Immediate flows are prioritised by inflows before outflows, so immediate outflows can depend on immediate inflows (allowing values to move along a chain of stocks and flows during a single time period), but immediate inflows cannot depend on immediate outflows, as this causes a circular dependency in evaluation.

Note that due to their instant nature, immediate flows are never run more than once per time period, regardless of the Resolution of the model.

### Pipeline Example

A good example of the use of immediate flows is in modelling systems involving rate-limiting and queues. Imagine we have a generator of events, and a processor that can handle up to 50 events per period. We would expect for the queue to remain empty while the generator was creating less than 50 events per period. But with the delayed nature of normal flows, this gives the strange result of a slowly growing queue even with well below 50. The processor is constantly slightly behind because it never sees the incoming flow until the period after they are generated.

Switching the generator and processors to be immediate solves this issue:

And we can see that the queue starts to grow as expected when the generator rate exceeds our processing rate. `Queue 2` stays 0 because each processor has the same rate, so the output of `Processor 1` never exceeds the capacity of `Processor 2`.