Code Overview
===================

The general structure of OpenFTS is to build up an `OpenFTS` object and then call its `Run()`
method to run the simulation. This `OpenFTS` object contains the following components that must be
initialized prior to running.

* **Cell** : holds information about the simulation cell (i.e. cell tensor, etc). 

* **FFTLayout** : holds information about performing FFTs in the simulation box. This includes the
  number of plane waves in each dimension, a reference to `Cell` object, precomputed coefficients
  (i.e. k2map) which only depend on the cell, and lots of utility functions for accessing elements
  within fields

* **Species**: holds information about the different species in the simulation. For a simple block
  polymer melt, this might just be that statistical segement length, :math:`b_A` or :math:`b_B`, of
  each block. It could also be the charge, smearing range, of polarizability of that species (though
  these features are not currently in the code).

* **Model**: this class holds any information related to the Hamiltonian `H` of a field theory. This
  includes the definition of `H`, the list of fields that `H` is a functional of (e.g.
  :math:`\mu_+`, :math:`\mu_-`), the forces required to update `H` (e.g. :math:`\frac{\delta H}{\delta
  \mu_+}`, :math:`\frac{\delta H}{\delta \mu_-}`). 

* **Molecules**: this is a list of each molecule in the system. This class holds information
  necessary to compute the :math:`\frac{\tilde{V} \phi_p}{\alpha_p} \ln Q_p` term that appears in
  the expression for `H`. If the molecule is a polymer, then the calculation of :math:`Q_p` requires
  the solution of a propagator :math:`q(r,s)`, which is handled by the `Chain` class.
  This class also stores :math:`q(r,s)q^\dagger(r,s)` which is used to compute the density and
  stress operators. The `Chain` class allows different statistics such as continuous or discrete.

* **Operators**: this class holds a list of operators to compute in the system. 

* **Output**: this class handles the output to files during the simulation.

* **Driver**: holds information related to the main `for-loop` in the code. This includes what
  actual simulation will be performed (e.g. SCFT or CL) and all of the relevant parameters necessary
  to run such a simulation (e.g. how many steps a simulation will run, how the `model` fields will be
  updated, what quantities will be output during the simulation, and how frequently this output fill
  be, etc). The `Driver` class is where the `Run()` method is contained.

  * **Field Updater**: the `Driver` class contains a `FieldUpdater` class that handles the algorithm 
    for updating the :math:`\mu` fields. For a semi-implicit `FieldUpdater` (e.g. SIS, ETD), the 
    `FieldUpdater` extracts a `linear_response_kernel` :math:`\hat{\kappa}(\pmb{k})` from the `Model` 
    class, which in turn calculate the Debye functions :math:`\hat{g}_D` for each `Molecule` in the 
    system. Thus, to add a new `FieldUpdater` or to extend an existing one, edits are required in the 
    `FieldUpdater`, `Model` and `Molecule` derived classes.

* **Monitors**: this class monitors various quantities during a simulation and takes action accordingly

Many of these classes provide an interface that derived classes must implement and OpenFTS is
structured with the expectation that new functionality will be added to the code by adding new
classes that derive from one of these `Base` classes.