diff --git a/LDDsimulation/README.md b/LDDsimulation/README.md
index 1e054cb4549f96454a546a75ab9eefd391af2e42..64d108d401551d2841bff856385a36d4e14d6c63 100644
--- a/LDDsimulation/README.md
+++ b/LDDsimulation/README.md
@@ -33,7 +33,7 @@ Some commented out code can be found here which might or might not be usefull fo
 This file contain the class definition of the `domainPatch` class which is the main data structure of the LDD simulation code.
 The programming paradigm was:
 >>>
-**PARADIGM**
+**PARADIGM:**
 _Each subdomain contains all information need and is completely independent of other subdomains._
 >>>
 All information means:
@@ -46,7 +46,19 @@ Methods in charge of communicating dofs to interfaces for exchange of informatio
 - function spaces and functions: Each subdomain stores their functionspaces as well as functions in which to store iterates.
 
 We briefly highlight some of the methods:
-- `governing_problem(*kwrgs)`:
+- `governing_problem(*kwrgs)`: This method gets called by `LDDsimulation.Lsolver_step(*kwrgs)` and assembles the form for the LDD solver
+in `ufl` language. It also calls the methods that calculate the gli terms that
+decouple the problems. The models are hardcoded here.
+If you want to implement LDD methods for other models, this is were it needs to
+happen.
+- `calc_gli_term(*kwrgs)`: Method that gets calle by the `governing_problem(*kwrgs)` method and calculates the gli term of the current
+iteration step. This method also communicates dofs to the interface objects.
+Note that this method needs to be revisited if parallelisation is to be implemented.
+Similarly, if more general types of gli methods need to be considered, this is where it needs to happen.
+- `calc_gl0_term(*kwrgs)`: Method that gets called by the `LDDsimulation.prepare_subdomain(*kwrgs)` within the `LDDsimulation.prepare_LDDsolver(*kwrgs)` method to calculate the initial gl0 term at the beginning of the calculation of the solution of a new timestep.
+As the normal flux gets calculated explicitly here, parts of the model are hard coded in this method aswell. Bare that in mind, when implementing new models.
+A layer of abstraction for the flux might be usefull here. 
+
 
 ## `boundary_and_interface.py`