Internals of the SystemDynamics library

• Basic idea from Cellier:
  • notation
    • flow line denoted by large arrow
    • signal line denoted by (standard) small arrow
  • Connector
    • standard input/output connectors for signal ports
    • input/output connectors for flow with different icons (MassInPort/MassOutPort)
  • Converter
    • block, i. e. dedicated input and output ports
  • Flow
    • computes flow dm from inputs
    • distributes dm via MassOutPorts to reservoirs
  • Reservoir
    • gets dm from MassInPorts
    • subtracts and integrates to get stock m
  • all ports have static causality (i. e. are designated inputs or outputs)
• Problems with causality:
  • model Outflow
    • usually flow defines dm
    • stock is (almost) empty → reservoir (Stock) defines dm
  • model TestConveyor
    • reservoir (Conveyor) always defines dm
    • value provided by flow is ignored
  • model TestOven
    • output flow (0 or capacity) given by reservoir (Oven)
    • input flow depends on phase
    • loading: given by flow and reservoir together
    • production: given by reservoir (0)
  • model AssemblyLine
    • inflow of inputStore defined by path1
    • inflow of machine1 depends on stock of inputStore, value of path2 and state of machine1
• Conception of the connector MassPort:
  • mass flow dm defined as flow variable
  • corresponding potential variable data
    • contains amount defined by reservoir
  • additional integer variable info defines, what to do with data
    • info = 0 → discard it, dm = dm_flow
    • info = 1 → use it directly, dm = data
    • info = 2 → reservoir is restricted, dm = min(data, dm_flow)
  • info has fixed causility: output of reservoir, input of flow
  • two connectors

    • connector MassPortR "mass port of reservoirs"
        flow Real dm;
        Real data;
        output Integer info;
      end MassPortR;

    • connector MassPortF "mass port of flows"
        flow Real dm;
        Real data;
        input Integer info;
      end MassPortF;

• Practical considerations:
  • several predefined Flow and Converter models implementing common equations
  • defining special equations easy using generic blocks in Interfaces
  • tabular data not as files, but as constant arrays
    • several tables can be combined in one resource class