diff --git a/doc/RTD-Legacy/DeveloperGuide/AddingTasks/addingtasks.rst b/doc/RTD-Legacy/DeveloperGuide/AddingTasks/addingtasks.rst
deleted file mode 100644
index 936fc5b45f901cbb704545727dac1211ac58b5a4..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/DeveloperGuide/AddingTasks/addingtasks.rst
+++ /dev/null
@@ -1,127 +0,0 @@
-.. _NewTask:
-
-How to add a new task to SWIFT?
-=================================
-.. highlight:: c
-
-
-
-.. toctree::
- :maxdepth: 0
-
-This tutorial will step through how to add a new task to swift. First we will go through the
-idealology of adding a new task to SWIFT. This will be followed by an example of how to add a task
-for an imposed external gravitational field to SWIFT and a task to include "cooling" to the gas particles.
-
-In the simplest case adding a new tasks requires changes to five files, namely:
-
-* task.h
-* cell.h
-* timers.h
-* task.c
-* engine.c
-
-Further, implementation details of what the task will then do should be added to another file
-(for example runner_myviptask.c) which will contain the actual task implementation.
-
-So now lets look at what needs to change in each of the files above, starting with task.h
-
---------------
-**task.h**
---------------
-Within task.h there exists a structure of the form::
-
- /* The different task types. */
- enum task_types {
- task_type_none = 0,
- task_type_sort,
- task_type_self,
- task_type_pair,
- .
- .
- .
- task_type_my_new_task,
- task_type_psort,
- task_type_split_cell,
- task_type_count
- };
-
-Within this task structure your new task should be added. Add the task entry anywhere in the struct before the
-task_type_count member. This last entry is used to count the number of tasks and must always be the last entry.
-
---------------
-**task.c**
---------------
-
-Within task.c the addition of the new task type must be include in a character list (which at the moment is only
-used for debugging purposes)::
-
- /* Task type names. */
- const char *taskID_names[task_type_count] = {
- "none", "sort", "self", "pair", "sub",
- "ghost", "kick1", "kick2", "send", "recv",
- "link", "grav_pp", "grav_mm", "grav_up", "grav_down",
- "my_new_task", "psort", "split_cell"};
-
-The new task type should be added to this list in the same order as it was added within the task_types struct in
-task.h
-
---------------
-**cell.h**
---------------
-
-cell.h contains pointers to all of the tasks associated with that cell. You must include your new task type
-here e.g::
-
- struct task *my_new_task;
-
---------------
-**timers.h**
---------------
-
-Within timers.h is an enumerated list of timers associated with each task. The timers measure the time required
-to execute a given task and this information is used in improve scheduling the task in future iterations::
-
- /* The timers themselves. */
- enum {
- timer_none = 0,
- timer_prepare,
- timer_kick1,
- .
- .
- .
- timer_new_task,
- timer_step,
- timer_count,
- };
-
---------------
-**engine.c**
---------------
-
-Finally, in engine.c the new task is added so that the scheduler knows to include the task in the list of tasks
-to be scheduled. Knowing where to add the task in engine.c is a little bit more difficult. This will depend on
-the type of task involved and whether it is a task that acts only on a individual particle independent of other
-particles (e.g. a cooling a task) or whether the task depends on other tasks (e.g. density, force or feedback).
-
-If we assume that the task is a particle only task then the first place to modify is the engine_mkghosts()
-function. Within this function the new task must be added to the list of tasks
-(within the c->nodeID == e->nodeID if clause)::
-
- /* Generate the external gravity task*/
- c->my_new_task = scheduler_addtask(s, task_type_my_new_task, task_subtype_none, 0, 0,
- c, NULL, 0);
-
-
-That's pretty much it - but what about dependencies and conflicts?
-Remember SWIFT automatically handles conflicts (by understanding which tasks need to write to the same data) so
-you (the developer) don't need to worry about conflicts. Dependencies do however need to be managed and they will
-be task specific. The following two examples, implementing cooling and an imposed external gravitational field
-will illustrate how dependencies should be treated.
-
-
-Examples:
-
-:ref:`ExternalGravityExample`
-
-:ref:`CoolingExample`
diff --git a/doc/RTD-Legacy/DeveloperGuide/Examples/Cooling/cooling.rst b/doc/RTD-Legacy/DeveloperGuide/Examples/Cooling/cooling.rst
deleted file mode 100644
index 5dc0c46a1881601115ceee1b2ac5b205e2fb1e5b..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/DeveloperGuide/Examples/Cooling/cooling.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. _CoolingExample:
-
-Cooling Example
---------------------------
-
-An example of how to implement a particle cooling task in SWIFT
-===================================================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/DeveloperGuide/Examples/ExternalGravity/externalgravity.rst b/doc/RTD-Legacy/DeveloperGuide/Examples/ExternalGravity/externalgravity.rst
deleted file mode 100644
index aceba80bb96dc69d942cbc675669c49fc7f2cf13..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/DeveloperGuide/Examples/ExternalGravity/externalgravity.rst
+++ /dev/null
@@ -1,225 +0,0 @@
-.. _ExternalGravityExample:
-
-External Gravity Task Example
-----------------------------------
-
-An example of how to implement an external gravity task in SWIFT
-=====================================================================
-
-An external gravitational field can be imposed in SWIFT to mimic self-gravity. This is done by assigning
-a gravitational force that falls as $1/ r^2$ (mathjax support to be included).
-
-In order to do this we update the files as described in :ref:`NewTask`. For the specific case of adding an
-external graviational field the additions are as follows:
-
-
---------------
-**task.h**
---------------
-
-Code (snapshot Nov 2015)::
-
- /* The different task types. */
- enum task_types {
- task_type_none = 0,
- task_type_sort,
- task_type_self,
- task_type_pair,
- task_type_sub,
- task_type_ghost,
- task_type_kick1,
- task_type_kick2,
- task_type_send,
- task_type_recv,
- task_type_link,
- task_type_grav_pp,
- task_type_grav_mm,
- task_type_grav_up,
- task_type_grav_down,
- **task_type_grav_external,**
- task_type_psort,
- task_type_split_cell,
- task_type_count
- };
-
-Task of type - task_type_grav_external - added to list of tasks.
-
---------------
-**task.c**
---------------
-
-Code (snapshot Nov 2015)::
-
- /* Task type names. */
- const char *taskID_names[task_type_count] = {
- "none", "sort", "self", "pair", "sub",
- "ghost", "kick1", "kick2", "send", "recv",
- "link", "grav_pp", "grav_mm", "grav_up", "grav_down", "grav_external",
- "psort", "split_cell"
- };
-
-Task added to list of task names (used only for debugging purposed).
-
-
---------------
-**cell.h**
---------------
-
-Code (snapshot Nov 2015)::
-
- /* The ghost task to link density to interactions. */
- struct task *ghost, *kick1, *kick2, *grav_external;
-
-Struture of type "task" declared (or pointer to a task at least).
-
-
-
---------------
-**timers.h**
---------------
-
-Code (snapshot Nov 2015)::
-
- /* The timers themselves. */
- enum {
- timer_none = 0,
- timer_prepare,
- timer_kick1,
- timer_kick2,
- timer_dosort,
- timer_doself_density,
- timer_doself_force,
- timer_doself_grav,
- timer_dopair_density,
- timer_dopair_force,
- timer_dopair_grav,
- timer_dosub_density,
- timer_dosub_force,
- timer_dosub_grav,
- timer_dopair_subset,
- timer_doghost,
- timer_dograv_external,
- timer_gettask,
- timer_qget,
- timer_qsteal,
- timer_runners,
- timer_step,
- timer_count,
- };
-
-The timer list is updated to include a timer task.
-
-
---------------
-**engine.c**
---------------
-
-Code (snapshot Nov 2015)::
-
- void engine_mkghosts(struct engine *e, struct cell *c, struct cell *super) {
-
- int k;
- struct scheduler *s = &e->sched;
-
- /* Am I the super-cell? */
- if (super == NULL && c->nr_tasks > 0) {
-
- /* Remember me. */
- super = c;
-
- /* Local tasks only... */
- if (c->nodeID == e->nodeID) {
-
- /* Generate the external gravity task*/
- c->grav_external = scheduler_addtask(s, task_type_grav_external, task_subtype_none, 0, 0,
- c, NULL, 0);
-
- /* Enforce gravity calculated before kick 2 */
- scheduler_addunlock(s, c->grav_external, c->kick2);
- }
- }
- }
-
-
-The first function call adds the task to the scheduler. The second function call takes care of the dependency
-involved in imposing an external gravitational field. These two functions are worth considering due to their
-obvious importance.
-
-
-
-The function prototype for the addtask function is (**found in scheduler.c**)::
-
- struct task *scheduler_addtask(struct scheduler *s, int type, int subtype,
- int flags, int wait, struct cell *ci,
- struct cell *cj, int tight) {
-
-This function adds a task to the scheduler. In the call to this function in engine.c we used the actual
-parameters **s** for the scheduler, **task_type_grav_external** for the (task) type, task_subtype_none for
-the (task) subtype, zeros for the flags and wait parameters, **c** for the pointer to our cell, NULL for the
-cell we interact with since there is none and 0 for the tight parameter.
-
-The function prototype for the addunlock function is(**found in scheduler.c**)::
-
- void scheduler_addunlock(struct scheduler *s, struct task *ta,
- struct task *tb) {
-
-This function signals when the unlock a certain task. In our case we use the external gravity task to unlock the
-kick2 task - i.e. kick2 depends on external gravity. So when calling the addunlock function the
-order is the **ta** task should be the task to unlock and **tb** should the task that does the unlocking.
-
-
---------------
-**runner.c**
---------------
-
-In runner.c the implementation of the external gravity task is taken care of. The function prototype is::
-
- void runner_dograv_external(struct runner *r, struct cell *c) {
-
-The function takes a pointer to a runner struct and a pointer to the cell struct. The entire function call is::
-
-
-
- void runner_dograv_external(struct runner *r, struct cell *c) {
-
- struct part *p, *parts = c->parts;
- float rinv;
- int i, ic, k, count = c->count;
- float dt_step = r->e->dt_step;
- TIMER_TIC
-
- /* Recurse? */
- if (c->split) {
- for (k = 0; k < 8; k++)
- if (c->progeny[k] != NULL) runner_dograv_external(r, c->progeny[k]);
- return;
- }
-
- /* Loop over the parts in this cell. */
- for (i = 0; i < count; i++) {
-
- /* Get a direct pointer on the part. */
- p = &parts[i];
-
- /* Is this part within the time step? */
- if (p->dt <= dt_step) {
- rinv = 1 / sqrtf((p->x[0])*(p->x[0]) + (p->x[1])*(p->x[1]) + (p->x[2])*(p->x[2]));
- for(ic=0;ic<3;ic++){
- p->grav_accel[ic] = - const_G * (p->x[ic]) * rinv * rinv * rinv;
- }
- }
- }
- TIMER_TOC(timer_dograv_external);
- }
-
-
-The key component of this function is the calculation of **rinv** and then the imposition of the
-**grav_accel** to this particle. **rinv** is calculated assuming the centre of the gravitational
-potential lies at the origin. The acceleration of each particle then is calculated by multiplying
-the graviational constant by the component of the position along one axis divided by R^3. The
-gravitational acceleration is then added to the total particle acceleration **a**.
-
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/DeveloperGuide/developerguide.rst b/doc/RTD-Legacy/DeveloperGuide/developerguide.rst
deleted file mode 100644
index 0c2cbe23c681af2dc4302b74e3c8c9f44fce5bef..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/DeveloperGuide/developerguide.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. _DeveloperGuide:
-
-A Developer Guide for SWIFT
-=================================
-
-
-.. toctree::
- :maxdepth: 1
-
- AddingTasks/addingtasks.rst
- Examples/ExternalGravity/externalgravity.rst
- Examples/Cooling/cooling.rst
-
diff --git a/doc/RTD-Legacy/FAQ/index.rst b/doc/RTD-Legacy/FAQ/index.rst
deleted file mode 100644
index 0d49b1d5833df205a1a98df78ebae9554686796d..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/FAQ/index.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-.. _GettingStarted:
-
-Frequently Asked Questions
-==========================
-
-1)
-
-2)
-
-3)
-
-4)
-
-5)
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/AsynchronousComms/index.rst b/doc/RTD-Legacy/Innovation/AsynchronousComms/index.rst
deleted file mode 100644
index 882492fc53abdab218fa46efe0b6f17c5d32393a..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/AsynchronousComms/index.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. _GettingStarted:
-
-Asynchronous Communication
-=================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/Caching/index.rst b/doc/RTD-Legacy/Innovation/Caching/index.rst
deleted file mode 100644
index 18e495ebf6b3a523f58e5360e99e5dc6f3337695..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/Caching/index.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. _GettingStarted:
-
-Caching
-=================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/InitialDecomp.png b/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/InitialDecomp.png
deleted file mode 100644
index 30cb00258b6668a3e9b1060ee7a49538e89b0e9c..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/InitialDecomp.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitCell.png b/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitCell.png
deleted file mode 100644
index 597710b6899e6070318006de1065ed4ac323379e..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitCell.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitPair.png b/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitPair.png
deleted file mode 100644
index 5d736aff29b94f5c915e9ec1f61e4b79c2323a7a..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/SplitPair.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/index.rst b/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/index.rst
deleted file mode 100644
index 5a16095d9de0ec8e6dd35218f0303d6da297ad8d..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/HeirarchicalCellDecomposition/index.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-.. _GettingStarted:
-
-Heirarchical Cell Decomposition
-=================================
-
-Most SPH codes rely on spatial trees to decompose the simulation space. This decomposition makes neighbour-finding simple, at the cost of computational efficiency. Neighbour-finding using the tree-based approach has an average computational cost of ~O(logN) and has a worst case behaviour of ~O(N\ :sup:`2/3`\), both cases grow with the total number of particles N. SWIFT's neighbour-finding algorithm however, has a constant scaling of ~O(1) per particle. This results from the way SWIFT decomposes its domain.
-
-The space is divided up into a grid of rectangular cells with an edge length that is greater than or equal to the maximum smoothing of any particle in the simulation, h\ :sub:`max`\ (See :ref:`cell_decomp`).
-
-.. _cell_decomp:
-.. figure:: InitialDecomp.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 1: 2D Cell Decomposition
-
-In this initial decomposition if a particle p\ :sub:`j`\ is within range of particle p\ :sub:`i`\, both will either be in the same cell (self-interaction) or in neighbouring cells (pair-interaction). Each cell then only has to compute its self-interactions and pair-interactions for each of its particles.
-
-The best case scenario is when each cell only contains particles that have a smoothing length equal to the cell edge length and even then, for any given particle p\ :sub:`i`\ it will only interact with 16% of the total number of particles in the same cell and surrounding neighbours. This percentage decreases if the cell contains particles whose smoothing length is less than the cell edge length. Therefore the cell decomposition needs to be refined recursively by bisecting a cell along each dimension if the following conditions are met:
-
-1) The cell contains more than a minimum number of particles
-
-2) The smoothing length of a reasonable number of particles within a cell is less than half the cell's edge length
-
-.. _split_cell:
-.. figure:: SplitCell.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 2: Refined Cell Decomposition
-
-Once a cell has been split its self-interactions can be decomposed into self-interactions of its sub-cells and corresponding pair interactions (See :ref:`split_cell`). If a pair of split cells share a boundary with each other and all particles in both cells have a smoothing length less than the cell edge length, then their pair-interactions can also be split up into pair-interactions of the sub-cells spanning the boundary (See :ref:`split_pair`).
-
-.. _split_pair:
-.. figure:: SplitPair.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 3: Split Cell Pair Interactions
-
-When the cells' particle interactions are split up between self-interactions and pair-interactions, any two particles who are within range of each other will either share a cell for which a cell self-interaction is defined or they will be located in neighbouring cells which share a cell pair-interaction. Therefore to determine whether particles are within range of each other it is sufficient to traverse the list of self-interactions and pair-interactions and compute the interactions therein.
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/HybridParallelism/index.rst b/doc/RTD-Legacy/Innovation/HybridParallelism/index.rst
deleted file mode 100644
index ed19e98a0d2fbae4494949014bf202416733add2..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/HybridParallelism/index.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. _GettingStarted:
-
-Hybrid Shared/Distributed-Memory Parallelism
-============================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/OMPScaling.png b/doc/RTD-Legacy/Innovation/TaskBasedParallelism/OMPScaling.png
deleted file mode 100644
index 4e5feaae3a91d1eae1aa3dee0ae38065512de9d7..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/OMPScaling.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExample.png b/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExample.png
deleted file mode 100644
index 3177010188e86962ad337c8ceb7b53a2631a5652..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExample.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExampleConflicts.png b/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExampleConflicts.png
deleted file mode 100644
index 368a9643503f213f699c185182d3ccc244210d00..0000000000000000000000000000000000000000
Binary files a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/TasksExampleConflicts.png and /dev/null differ
diff --git a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/index.rst b/doc/RTD-Legacy/Innovation/TaskBasedParallelism/index.rst
deleted file mode 100644
index 4cc265b80b3b4bd408c3b417c4a43313b8cec609..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/TaskBasedParallelism/index.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. _GettingStarted:
-
-Task Based Parallelism
-=================================
-
-One of biggest problems faced by many applications when running on a shared memory system is *load imbalance*, this occurs when the work load is not evenly distributed across the cores. The most well known paradigm for handling this type of parallel architecture is OpenMP, in which the programmer applies annotations to the code to indicate to the compiler which sections should be executed in parallel. If a ``for`` loop has been identified as a parallel section, the iterations of the loop are split between available threads, each executing on a single core. Once all threads have terminated the program becomes serial again and only executes on single thread, this technique is known as branch-and-bound parallelism, shown in :ref:`branch_and_bound`. Unfortunately, this implementation generally leads to low performance and bad scaling as you increase the number of cores.
-
-.. _branch_and_bound:
-.. figure:: OMPScaling.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 1: Branch-and-bound parallelism
-
-Another disadvantage with this form of shared-memory parallelism is that there is no implicit handling of concurrency issues between threads. *Race conditions* can occur when two threads attempt to modify the same data simultaneously, unless explicit *critical* regions are defined which prevent more than one thread executing the same code at the same time. These regions degrade parallel performance even further.
-
-A better way to exploit shared memory systems is to use an approach called *task-based parallelism*. This method describes the entire computation in a way that is more inherently parallelisable. The simulation is divided up into a set of computational tasks which are **dynamically** allocated to a number of processors. In order to ensure that the tasks are executed in the correct order and to avoid *race conditions*, *dependencies* between tasks are identified and strictly enforced by a task scheduler. A Directed Acyclic Graph (DAG) illustrates how a set of computational tasks link together via dependencies. Processors can traverse the graph in topological order, selecting and executing tasks that have no unresolved dependencies or waiting until tasks become available. This selection process continues for all processors until all tasks have been completed. An example of a DAG can be seen in :ref:`DAG`, the figure represents tasks as circles, labelled A-E, and dependencies as arrows. Tasks B and C both depend on A, and D depends on B, whereas A and E are independent tasks. Therefore on a shared memory system, tasks A and E could be executed first. Once task A is finished, tasks B and C become available for execution as their dependencies to A have been resolved. Finally, task D can be executed after task B has completed.
-
-.. _DAG:
-.. figure:: TasksExample.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 2: Tasks and Dependencies
-
-The main advantages of using this approach are as follows:
-
-* The order in which the tasks are processed is completely dynamic and adapts automatically to load imbalances.
-* If the dependencies and conflicts are specified correctly, there is no need for expensive explicit locking, synchronisation or atomic operations, found in OpenMP to deal with most concurrency problems.
-* Each task has exclusive access to the data it is working on, thus improving cache locality and efficiency.
-
-SWIFT modifies the task-based approach by introducing the concept of *conflicts* between tasks. Conflicts occur when two tasks operate on the same data, but the order in which the operations occur does not matter. :ref:`task_conflicts` illustrates tasks with conflicts, where there is a conflict between tasks B and C, and tasks D and E. In a parallel setup, once task A has finished executing, if one processor selects task B, then no other processor is allowed to execute task C until task B has completed, or vice versa. Without this modification, other task-based models used dependencies to model conflicts between tasks, which introduces an artificial ordering between tasks and imposes unnecessary constraints on the task scheduler.
-
-.. _task_conflicts:
-.. figure:: TasksExampleConflicts.png
- :scale: 40 %
- :align: center
- :figclass: align-center
-
- Figure 3: Tasks and Conflicts
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/TaskGraphPartition/index.rst b/doc/RTD-Legacy/Innovation/TaskGraphPartition/index.rst
deleted file mode 100644
index c0dd4b44927cbfa6da106e8e93ffdf0b9d9f94d7..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/TaskGraphPartition/index.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. _GettingStarted:
-
-Task Graph Partition
-=================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/Vectorisation/index.rst b/doc/RTD-Legacy/Innovation/Vectorisation/index.rst
deleted file mode 100644
index c944fb98a9c440761d7a8c3955cc4f734ed24bab..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/Vectorisation/index.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. _GettingStarted:
-
-Vectorisation
-=================================
-
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Innovation/index.rst b/doc/RTD-Legacy/Innovation/index.rst
deleted file mode 100644
index 65a9cb82230b5661f332e25ea05644ec8e2cdbf8..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Innovation/index.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-What makes SWIFT different?
-===========================
-
-SWIFT implements a host of techniques that not only make it faster on one core but produce better scaling on shared and distributed memory architectures, when compared to equivalent codes such as Gadget-2.
-
-Here is a list outlining how SWIFT approaches parallelism:
-
-.. toctree::
- :maxdepth: 1
-
- HeirarchicalCellDecomposition/index.rst
- TaskBasedParallelism/index.rst
- Caching/index.rst
- TaskGraphPartition/index.rst
- HybridParallelism/index.rst
- AsynchronousComms/index.rst
- Vectorisation/index.rst
diff --git a/doc/RTD-Legacy/Makefile b/doc/RTD-Legacy/Makefile
deleted file mode 100644
index b1dfebb01c2f55530f7a8efad3c5e5bf96484c18..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Makefile
+++ /dev/null
@@ -1,177 +0,0 @@
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS =
-SPHINXBUILD = sphinx-build
-PAPER =
-BUILDDIR = _build
-
-# User-friendly check for sphinx-build
-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
-$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
-endif
-
-# Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
-
-help:
- @echo "Please use \`make <target>' where <target> is one of"
- @echo " html to make standalone HTML files"
- @echo " dirhtml to make HTML files named index.html in directories"
- @echo " singlehtml to make a single large HTML file"
- @echo " pickle to make pickle files"
- @echo " json to make JSON files"
- @echo " htmlhelp to make HTML files and a HTML help project"
- @echo " qthelp to make HTML files and a qthelp project"
- @echo " devhelp to make HTML files and a Devhelp project"
- @echo " epub to make an epub"
- @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
- @echo " latexpdf to make LaTeX files and run them through pdflatex"
- @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
- @echo " text to make text files"
- @echo " man to make manual pages"
- @echo " texinfo to make Texinfo files"
- @echo " info to make Texinfo files and run them through makeinfo"
- @echo " gettext to make PO message catalogs"
- @echo " changes to make an overview of all changed/added/deprecated items"
- @echo " xml to make Docutils-native XML files"
- @echo " pseudoxml to make pseudoxml-XML files for display purposes"
- @echo " linkcheck to check all external links for integrity"
- @echo " doctest to run all doctests embedded in the documentation (if enabled)"
-
-clean:
- rm -rf $(BUILDDIR)/*
-
-html:
- $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
- $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
- $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
- @echo
- @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-pickle:
- $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
- @echo
- @echo "Build finished; now you can process the pickle files."
-
-json:
- $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
- @echo
- @echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
- $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
- @echo
- @echo "Build finished; now you can run HTML Help Workshop with the" \
- ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
- $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
- @echo
- @echo "Build finished; now you can run "qcollectiongenerator" with the" \
- ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
- @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/SWIFT.qhcp"
- @echo "To view the help file:"
- @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/SWIFT.qhc"
-
-devhelp:
- $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
- @echo
- @echo "Build finished."
- @echo "To view the help file:"
- @echo "# mkdir -p $$HOME/.local/share/devhelp/SWIFT"
- @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/SWIFT"
- @echo "# devhelp"
-
-epub:
- $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
- @echo
- @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-latex:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo
- @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
- @echo "Run \`make' in that directory to run these through (pdf)latex" \
- "(use \`make latexpdf' here to do that automatically)."
-
-latexpdf:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through pdflatex..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-latexpdfja:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through platex and dvipdfmx..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
- $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
- @echo
- @echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
- $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
- @echo
- @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo
- @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
- @echo "Run \`make' in that directory to run these through makeinfo" \
- "(use \`make info' here to do that automatically)."
-
-info:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo "Running Texinfo files through makeinfo..."
- make -C $(BUILDDIR)/texinfo info
- @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-gettext:
- $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
- @echo
- @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-changes:
- $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
- @echo
- @echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
- $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
- @echo
- @echo "Link check complete; look for any errors in the above output " \
- "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
- $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
- @echo "Testing of doctests in the sources finished, look at the " \
- "results in $(BUILDDIR)/doctest/output.txt."
-
-xml:
- $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
- @echo
- @echo "Build finished. The XML files are in $(BUILDDIR)/xml."
-
-pseudoxml:
- $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
- @echo
- @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
diff --git a/doc/RTD-Legacy/Motivation/index.rst b/doc/RTD-Legacy/Motivation/index.rst
deleted file mode 100644
index 94daf931959c446592f1a06b7e49c94f92d27516..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Motivation/index.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. _GettingStarted:
-
-What is the Motivation for SWIFT?
-=================================
-
-SWIFT is designing with parallelism from the very start. It is a bottom up approach with a task based
-parallel infrastructure at it's very core.
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Physics/Gravity/gravity.rst b/doc/RTD-Legacy/Physics/Gravity/gravity.rst
deleted file mode 100644
index 82b60bc01747f1693ff2d99fc09db8a5e23d7043..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Physics/Gravity/gravity.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. _SWIFTGravity:
-
-Gravity
-=============================
-
-SWIFT implements the calculation of gravitational forces using a version of TreePM.
-Matthieu - can you update this part? I know you have implemented a Multipole method here
-with some SWIFT specific modifications. Could you write a brief overview of the idea?
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Physics/SPH/sph.rst b/doc/RTD-Legacy/Physics/SPH/sph.rst
deleted file mode 100644
index feadec4bcd48a161c80bc4ecf09345278e20ab87..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Physics/SPH/sph.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. _SWIFTSPH:
-
-Smooth Particle Hydrodynamics
-=============================
-
-SWIFT simulates the universe using SPH.
-
-.. toctree::
- :maxdepth: 1
diff --git a/doc/RTD-Legacy/Physics/index.rst b/doc/RTD-Legacy/Physics/index.rst
deleted file mode 100644
index 536c135ec47d83791ba50dd55246f4c6a9559e9e..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/Physics/index.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. _SWIFTPhysics:
-
-What Physics does SWIFT Simulate?
-=================================
-
-
-.. toctree::
- :maxdepth: 1
-
- SPH/sph.rst
- Gravity/gravity.rst
diff --git a/doc/RTD-Legacy/conf.py b/doc/RTD-Legacy/conf.py
deleted file mode 100644
index 6b65aabe54a480a29a7930f6e6f24a35b0204dcf..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/conf.py
+++ /dev/null
@@ -1,248 +0,0 @@
-# -*- coding: utf-8 -*-
-#
-# SWIFT documentation build configuration file, created by
-# sphinx-quickstart on Thu Nov 5 15:57:05 2015.
-#
-# This file is execfile()d with the current directory set to its containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys, os
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration -----------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be extensions
-# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ['sphinx.ext.todo', 'sphinx.ext.mathjax']
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix of source filenames.
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = u'SWIFT'
-copyright = u'2015: John Regan, James Willis, Stefan Arridge, Matthieu Schaller'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = '0.1'
-# The full version, including alpha/beta/rc tags.
-release = '0.1'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = ['_build']
-
-# The reST default role (used for this markup: `text`) to use for all documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
-
-
-# -- Options for HTML output ---------------------------------------------------
-
-# The theme to use for HTML and HTML Help pages. See the documentation for
-# a list of builtin themes.
-html_theme = 'default'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = []
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# "<project> v<release> documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'SWIFTdoc'
-
-
-# -- Options for LaTeX output --------------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title, author, documentclass [howto/manual]).
-latex_documents = [
- ('index', 'SWIFT.tex', u'SWIFT Documentation',
- u'John Regan, James Willis, Stefan Arridge, Matthieu Schaller', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output --------------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
- ('index', 'swift', u'SWIFT Documentation',
- [u'John Regan, James Willis, Stefan Arridge, Matthieu Schaller'], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output ------------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-# dir menu entry, description, category)
-texinfo_documents = [
- ('index', 'SWIFT', u'SWIFT Documentation',
- u'John Regan, James Willis, Stefan Arridge, Matthieu Schaller', 'SWIFT', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
diff --git a/doc/RTD-Legacy/index.rst b/doc/RTD-Legacy/index.rst
deleted file mode 100644
index 1d2b08ceb8e227ba9fee306ab26ae9a490308dc4..0000000000000000000000000000000000000000
--- a/doc/RTD-Legacy/index.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-.. SWIFT documentation master file, created by
- sphinx-quickstart on Thu Nov 5 15:57:05 2015.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Welcome to SWIFT's documentation!
-=================================
-
-This is the first go at writing some high level documentation for SWIFT.
-It will be augmented and linked with the already available documentation.
-Contents:
-
-
-.. toctree::
- :maxdepth: 2
-
- Motivation/index.rst
- Innovation/index.rst
- Physics/index.rst
- DeveloperGuide/developerguide.rst
- FAQ/index.rst
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-