* Add overview description and move methods, #78

Tutorial/Introduction.md

@@ -1,13 +1,13 @@
 # pyDMPC Introduction
 
-Models could play an increasingly important role in future building energy systems. Many model and optimization-based approaches, however, require the assumption of convexity and availability of a cost function gradient. We aim to develop approaches that function without these simplifying assumptions. Instead, we developed a flexible algorithm, in which each subsystem can be modelled using a different technique as long as the maximum computing time of the slowest model is still acceptable. Some of the models could be simulation models, potentially in a functional mockup unit, some could be simple characteristic fields and some could even be ‘external’, stored on the embedded controllers of HVAC components themselves.
+Models could play an increasingly important role in future building energy systems. Many model and optimization-based approaches, however, require the assumption of convexity and availability of a cost function gradient. We aim to develop approaches that function without these simplifying assumptions. Instead, we developed a flexible algorithm, in which each subsystem can be modelled using a different technique as long as the maximum computing time of the slowest model is still acceptable. Some of the models could be simulation models, potentially in a functional mockup unit, some could be simple characteristic fields and some could even be 'external', stored on the embedded controllers of HVAC components themselves.
 In this framework, we have implemented two different algorithms: a non-iterative algorithm and an iterative algorithm.
 
 ![Architecture](../pyDMPC/Resources/Images/Architecture.png)
 
 ![System Decomposition](../pyDMPC/Resources/Images/SystemDecomposition.png)
 
-The non-iterative approach, henceforth called BExMoC – Building Exergy-based Model Predictive Control – is based on a DMPC design that only requires communication between the current subsystem and its immediate up-stream neighbors. Instead of solving one error-prone optimization task of a central problem that considers optimization parameters of every single subsystem simultaneously, the central objective function is decomposed and each subsystem is attributed a suitable objective function of its own. These objective functions, however, cannot be solved without taking the influence on other subsystems into account. For that reason, the objective functions are constructed in such a way, that one subsystem’s objective always depends on the one of the downstream neighboring subsystem. Beginning with the last subsystem in a supply chain, the local objective functions are minimized successively for a set of pre-defined input conditions. Thus, look-up tables containing the local optimization results and corresponding decision values are generated and communicated to the immediate upstream neighbors. As soon as the upstream neighbor has received the look-up tables, its local objective function can be evaluated.
+The non-iterative approach, henceforth called BExMoC – Building Exergy-based Model Predictive Control – is based on a DMPC design that only requires communication between the current subsystem and its immediate up-stream neighbors. Instead of solving one error-prone optimization task of a central problem that considers optimization parameters of every single subsystem simultaneously, the central objective function is decomposed and each subsystem is attributed a suitable objective function of its own. These objective functions, however, cannot be solved without taking the influence on other subsystems into account. For that reason, the objective functions are constructed in such a way, that one subsystem's objective always depends on the one of the downstream neighboring subsystem. Beginning with the last subsystem in a supply chain, the local objective functions are minimized successively for a set of pre-defined input conditions. Thus, look-up tables containing the local optimization results and corresponding decision values are generated and communicated to the immediate upstream neighbors. As soon as the upstream neighbor has received the look-up tables, its local objective function can be evaluated.
 For the proposed algorithm, two cost functions can be selected: one aims to optimize operation costs, the other one focuses on minimizing the exergy destruction and loss. Whereas the operating costs are strongly influenced by fluctuating energy prices, the exergy loss depends only on the system's performance and the selection of the reference environment. Exemplarily, the local objective function is used in the following to show the equality of the central optimization problem and the decomposed problem.
 
 ![Sequential Scheme](../pyDMPC/Resources/Images/SequentialScheme.png)
@@ -28,7 +28,8 @@ The positive factors β_1 and  β_2 ensure that the cost increases significantly
 
 ### Various model types
 Currently, pyDMPC features the following model types:
-- Modelica model (via Python-Dymola interface or as FMU)
+- Modelica (via Python-Dymola interface)
 - Scikit model (exported using Joblib)
-- Fuzzy Logic model
-- Linear model
+- Fuzzy Logic
+- Linear equation
+- Linear state space 

Tutorial/Overview.md

@@ -0,0 +1,9 @@
+# Overview of the reference implementation
+
+The reference implementation allows applying two specific DMPC algorithms to the AHU and the test hall use case. 
+
+## System
+The System module is used to generate a set of subsystems (agents) that perform the actual control task. It is also useful to define the overall algorithm. In the reference implementation, this algorithm is called BExMoC and simply inherits from the System class. 
+
+## Subsystem
+The Subsystem module contains the definition of the subsystems (agents). In the BaseSubsystem class, only the main model types are defined. 

pyDMPC/ControlFramework/Subsystem.py

@@ -71,7 +71,6 @@ def __init__(self, sys_id):
         self.sys_id = sys_id
         self.name = Init.name[sys_id]
         self.model_type = Init.model_type[sys_id]
-        self.model = self.prepare_model()
         self.ups_neigh = Init.ups_neigh[sys_id]
         self.downs_neigh = Init.downs_neigh[sys_id]
         self.par_neigh = Init.par_neigh[sys_id]
@@ -91,6 +90,13 @@ def __init__(self, sys_id):
         self.traj_var = Init.traj_var[sys_id]
         self.traj_points = Init.traj_points[sys_id]
 
+
+class Subsystem(BaseSubsystem):
+
+    def __init__(self, sys_id):
+        super().__init__(sys_id = sys_id)
+        self.model = self.prepare_model()
+
     def prepare_model(self):
         """Prepares the model of a subsystem according to the subsystem's model
         type.
@@ -120,11 +126,6 @@ def prepare_model(self):
             model = Modeling.StateSpace(self.sys_id)
         return model
 
-class Subsystem(BaseSubsystem):
-
-    def __init__(self, sys_id):
-        super().__init__(sys_id = sys_id)
-
     def predict(self, inputs, commands):
 
         if inputs != "external":