+{{ toctree() }}
diff --git a/doc/source/building-and-running/considerations.rst b/doc/source/building-and-running/considerations.rst
new file mode 100644
index 00000000..66359c89
--- /dev/null
+++ b/doc/source/building-and-running/considerations.rst
@@ -0,0 +1,35 @@
+Considerations
+==============
+
+Depending on your use case, there are two main things that you need to consider:
+
+Do I need NetCDF?
+-----------------
+
+`NetCDF `_ is a data format (and associated software libraries) specifically designed for large-scale scientific data. It has two major benefits over raw binary data:
+
+1. It is machine-independent, so `endianness `_ is not an issue when moving datasets between machines
+2. It is self-describing, so as well as containing raw data, NetCDF files also contain metadata describing the data (e.g. variable names, units, origin). Many tools are capable of exploiting this metadata to simplify processing.
+
+JULES can be built with or without NetCDF, however *building JULES without NetCDF limits the functionality of JULES*. Without NetCDF, JULES will use a dummy NetCDF library which allows the program to build but provides no functionality. Any attempt to use NetCDF files as input with this option will result in a runtime error. All input files must be columnar ASCII, meaning that the user is restricted to running at a single point only. Output files will automatically use a columnar ASCII format with headers. File formats are discussed in more detail in :doc:`/input/overview`.
+
+
+Do I need parallel processing?
+------------------------------
+
+.. note::
+ For running JULES at a single point, parallel processing provides no advantage. However, if JULES is already compiled with OpenMP or MPI enabled, it is still possible to run a single point by simply specifying the number of OpenMP threads and/or MPI tasks to be 1.
+
+JULES is capable of exploiting parallel processing techniques to reduce processing time for distributed/gridded simulations. There are two different methods JULES can use:
+
+OpenMP
+ `OpenMP `_ is a form of compiler-assisted parallelisation that uses directives for shared-memory, loop-level parallelism across multiple cores on a machine (OpenMP is *not* capable of utilising a cluster of machines).
+
+ This form of parallelism is not as effective as MPI, but may provide some speedup and does not require a specially compiled NetCDF library.
+
+MPI
+ `MPI (Message Passing Interface) `_ is a standardised message passing interface. MPI coordinates the running of multiple 'tasks' in parallel, potentially on several machines (or nodes), and provides mechanisms for these tasks to communicate with each other.
+
+ JULES takes advantage of the parallel I/O features available in `HDF5 `_ and `NetCDF4 `_, which enable multiple MPI tasks to read from and write to the same NetCDF file(s) at the same time. These features must be explicitly enabled when NetCDF is compiled (see :doc:`required-software`).
+
+It is also possible to use MPI and OpenMP together, where each MPI task has a number of OpenMP threads, however this is very advanced and beyond the scope of this document.
diff --git a/doc/source/building-and-running/fcm.rst b/doc/source/building-and-running/fcm.rst
new file mode 100644
index 00000000..0b6d9bd9
--- /dev/null
+++ b/doc/source/building-and-running/fcm.rst
@@ -0,0 +1,253 @@
+Building JULES using FCM
+========================
+
+FCM is a code management and build system developed by the Met Office with a particular focus on simplifying the process of building large Fortran programs. In this section, we will be using the build tool - FCM make.
+
+As part of the build process, FCM make will analyse the dependencies of every Fortran file and automatically compile them in the correct order.
+
+FCM make must be given a configuration file that it uses to determine how to build the source code. Extensive documentation on FCM make configuration files is `available online `_.
+
+Help pages for the FCM make command itself (rather than the configuration file) can be accessed using the command:
+
+.. code-block:: bash
+
+ fcm help make
+
+The FCM configuration file for building JULES is ``etc/fcm-make/make.cfg``. This file uses the environment variables below to determine the settings to use when compiling JULES.
+
+Running FCM make with this configuration file will create some files and directories in the specified build directory (see the ``-C`` option of ``fcm make``; defaults to the current working directory). The JULES executable will be produced in the specified build directory at ``build/bin/jules.exe``.
+
+
+.. _fcm-make-environment-variables:
+
+Environment variables used when building JULES using FCM make
+-------------------------------------------------------------
+
+``JULES_PLATFORM``
+ Used to select settings for a pre-defined platform. The default values of other variables may depend on the choice of this setting; differences from the generic defaults are included in the descriptions below.
+
+ .. note::
+ If you have many users using the same platform to run JULES, you may want to contribute a suitable platform configuration.
+
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +============================+==============================================================================================================================================================+
+ | ``custom`` | **Default.** Use a custom configuration entirely determined by the other environment |
+ | | variables. The default values of those variables are set in this platform's configuration file. |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``vm`` | Use settings for the `JULES development virtual machine`. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``ceh`` | Use settings for the GFortran compiler on the CEH Linux systems. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``jasmin-lotus-intel`` | Use settings for the Intel compiler on the Lotus system at JASMIN. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``jasmin-gcc-nompi`` | Use settings for the gfortran compiler on the JASMIN Cylc server. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``jasmin-intel-nompi`` | Use settings for the intel compiler on the JASMIN Cylc server. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``meto-linux-gfortran`` | Use settings for the GFortran compiler on Met Office Linux systems. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``meto-linux-nagfor`` | Use settings for the NAG compiler on Met Office Linux systems. |
+ | | |
+ | | **Warning:** This build configuration is intended for correctness checking only, not production runs. |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``meto-linux-intel-nompi`` | Use settings for the Intel compiler *without* MPI on Met Office Linux systems. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``meto-linux-intel-mpi`` | Use settings for the Intel compiler *with* MPI on Met Office Linux systems. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``meto-xc40-cce`` | Use settings for the Cray Compiler Environment on the Met Office Cray XC40 system. |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | ``uoe-linux-gfortran`` | Use settings for the GFortran compiler on University of Exeter Linux system (SL7). |
+ | | |
+ +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+``JULES_REMOTE``, ``JULES_REMOTE_HOST``, ``JULES_REMOTE_PATH``
+ .. warning:: Advanced users only
+
+ Used to determine whether the build will happen on a local or remote machine.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``local`` | **Default.** All compilation occurs on the local machine. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``remote`` | Code is extracted on the local machine and mirrored to |
+ | | ``${JULES_REMOTE_HOST}@${JULES_REMOTE_PATH}``, where ``JULES_REMOTE_HOST`` is |
+ | | the name of the remote machine and ``JULES_REMOTE_PATH`` is the path on the |
+ | | remote machine. |
+ | | |
+ | | The compilation can then be completed on the remote machine. See below for an |
+ | | example. |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_COMPILER``
+ Used to select compiler specific settings.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``gfortran`` | **Default.** Use settings for the `GNU Fortran compiler`_. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``intel`` | Use settings for the `Intel Fortran compiler`_. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``nagfor`` | Use settings for the `NAG Fortran compiler`_. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``cray`` | Use settings for the `Cray Compiler Environment`_. |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_BUILD``
+ Used to select the type of build.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``normal`` | **Default.** Compile JULES normally. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``debug`` | Compile JULES with additional settings for debugging. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``fast`` | Compile JULES with additional settings for faster execution. |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_OMP``
+ Used to determine whether to build with OpenMP or not.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``noomp`` | **Default.** Compile JULES with OpenMP off. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``omp`` | Compile JULES with OpenMP on. |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_MPI``
+ Used to determine whether to build with MPI enabled or not.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``nompi`` | **Default.** Compile JULES without MPI support. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``mpi`` | Compile JULES with MPI support. |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_NETCDF``
+ Indicates whether to use a dummy NetCDF library or a 'real' NetCDF library.
+
+ +-----------------+----------------------------------------------------------------------------------+
+ | Permitted value | Purpose |
+ +=================+==================================================================================+
+ | ``nonetcdf`` | **Default.** Use a dummy NetCDF library. |
+ +-----------------+----------------------------------------------------------------------------------+
+ | ``netcdf`` | Use a 'real' NetCDF library. |
+ | | |
+ | | The NetCDF installation to use is specified using one of: |
+ | | |
+ | | * ``JULES_NETCDF_PATH`` |
+ | | * ``JULES_NETCDF_INC_PATH`` and ``JULES_NETCDF_LIB_PATH`` |
+ +-----------------+----------------------------------------------------------------------------------+
+
+``JULES_NETCDF_PATH``
+ Path to NetCDF installation.
+
+ This sets ``JULES_NETCDF_INC_PATH = $JULES_NETCDF_PATH/include`` and ``JULES_NETCDF_LIB_PATH = $JULES_NETCDF_PATH/lib``. These can be overridden by setting the variables directly.
+
+``JULES_NETCDF_INC_PATH``
+ Path to NetCDF include directory (i.e. directory containing ``netcdf.mod``).
+
+``JULES_NETCDF_LIB_PATH``
+ Path to NetCDF library directory (i.e. directory containing ``libnetcdff.a`` and ``libnetcdf.a``).
+
+.. note::
+ When compiled in parallel mode, NetCDF must be statically linked. This means the compiler must be able to find all required library and include files (i.e. for NetCDF, HDF5, curl and zlib) in ``JULES_NETCDF_INC_PATH``, ``JULES_NETCDF_LIB_PATH`` or the default search path.
+
+``JULES_FFLAGS_EXTRA``
+ Any additional compiler flags you wish to add to the build. For example, to activate additional compiler checks.
+
+``JULES_LDFLAGS_EXTRA``
+ Any additional library flags you wish to add to the build. This may need to include both the linker flags themselves and, if you are linking in a new library, the flags specifying the path to the new library object.
+
+.. note::
+ When adding a completely new external dependency it is likely you will need to edit or override the FCM make build configuration files. The FCM make tool performs a dependency analysis on the JULES source tree to ensure all of the required files are present. Any new external sources must be added to the list of exclusions from this analysis or the build will fail when the external files cannot be found in the JULES working copy.
+
+``JULES_SOURCE``
+ The full path to the copy of JULES being compiled. This could be a directory path or an FCM/Subversion/file URL to a repository location. This variable is used by the configuration file contained in many Rose fcm_make apps, but is not read by JULES itself.
+
+
+Example FCM make commands
+-------------------------
+
+To create a normal JULES executable without NetCDF using the GFortran compiler (taking advantage of the default values for the environment variables):
+
+.. code-block:: bash
+
+ $ fcm make -j 2 -f etc/fcm-make/make.cfg --new
+
+To create a fast JULES executable with NetCDF using the Intel compiler:
+
+.. code-block:: bash
+
+ $ export JULES_COMPILER=intel
+ $ export JULES_BUILD=fast
+ $ export JULES_NETCDF=netcdf
+ $ export JULES_NETCDF_PATH=/path/to/netcdf # Replace this with the correct path
+ $ fcm make -j 2 -f etc/fcm-make/make.cfg --new
+
+To create a fast JULES executable with NetCDF using the GFortran compiler on a Met Office Linux system (making use of the platform setting):
+
+.. code-block:: bash
+
+ $ export JULES_PLATFORM=meto-linux-gfortran
+ $ export JULES_BUILD=fast
+ $ export JULES_NETCDF=netcdf # Note that we don't need to specify paths
+ $ fcm make -j 2 -f etc/fcm-make/make.cfg --new
+
+To create a normal JULES executable with NetCDF and OpenMP using the Intel compiler on a remote machine:
+
+.. code-block:: bash
+
+ localhost $ export JULES_REMOTE=remote
+ localhost $ export JULES_REMOTE_HOST=my-host
+ localhost $ export JULES_REMOTE_PATH=/path/on/remote/host
+ localhost $ export JULES_COMPILER=intel
+ localhost $ export JULES_OMP=omp
+ localhost $ export JULES_NETCDF=netcdf
+ localhost $ export JULES_NETCDF_PATH=/path/to/netcdf # Replace this with the path ON THE REMOTE MACHINE
+ localhost $ fcm make -f etc/fcm-make/make.cfg --new # This does the extract and mirror steps
+ localhost $ ssh -Y my-host
+ my-host $ cd /path/on/remote/host
+ my-host $ fcm make -j 4 --new # This does the preprocess and build steps
+
+To create a normal JULES executable with MPI enabled, using the Intel compiler with array bounds checking turned on:
+
+.. code-block:: bash
+
+ $ export JULES_COMPILER=intel
+ $ export JULES_MPI=mpi
+ $ export JULES_NETCDF=netcdf # We have to use NetCDF for distributed simulations
+ $ export JULES_NETCDF_PATH=/path/to/parallel/netcdf # NetCDF must be compiled with parallel I/O enabled
+ $ export JULES_FFLAGS_EXTRA="-check bounds" # Must be quoted because of the space
+ $ fcm make -j 2 -f etc/fcm-make/make.cfg --new
+
+
+Tips for effective use of FCM make
+----------------------------------
+
+* To check the current values of the environment variables JULES will use to build, use the command ``env | grep JULES``
+
+* If you always use the same compilation options for JULES, consider adding the export lines to the ``.profile`` file in your ``$HOME`` directory. Commands in the ``.profile`` file are automatically executed in any shell that you open, so defining environment variables there ensures your build environment remains consistent across shells and restarts of your computer. The definitions can still be overridden on the command line if required.
+
+
+.. _JULES development virtual machine: https://code.metoffice.gov.uk/trac/jules/wiki/JULESVirtualMachine
+.. _GNU Fortran compiler: https://www.gnu.org/software/gcc/fortran/
+.. _Intel Fortran compiler: http://software.intel.com/en-us/articles/fortran-compilers/
+.. _NAG Fortran compiler: https://www.nag.co.uk/nag-compiler
+.. _Cray Compiler Environment: http://docs.cray.com/cgi-bin/craydoc.cgi?mode=SiteMap;f=xc_sitemap
diff --git a/doc/source/building-and-running/intro.rst b/doc/source/building-and-running/intro.rst
new file mode 100644
index 00000000..4ab3fc43
--- /dev/null
+++ b/doc/source/building-and-running/intro.rst
@@ -0,0 +1,17 @@
+==========================
+Building and running JULES
+==========================
+
+
+This section details the options available for compiling and running JULES.
+
+
+.. toctree::
+ :maxdepth: 2
+
+ considerations
+ required-software
+ fcm
+ running-jules
+ rose
+
diff --git a/doc/source/building-and-running/required-software.rst b/doc/source/building-and-running/required-software.rst
new file mode 100644
index 00000000..c9c6715d
--- /dev/null
+++ b/doc/source/building-and-running/required-software.rst
@@ -0,0 +1,37 @@
+Required software
+=================
+
+Building a JULES executable requires FCM and one of the supported Fortran compilers (see :doc:`fcm`). The Fortran 90 NetCDF interface library is required to use gridded data (i.e. data for more than a single location).
+
+To be able to automatically upgrade namelists between JULES versions or use a GUI to configure JULES runs, Rose is required.
+
+All of this software is freely available:
+
+* GFortran, the GNU GCC Fortran compiler - https://www.gnu.org/software/gcc/fortran
+* FCM - http://metomi.github.io/fcm/doc
+* Rose - http://metomi.github.io/rose/doc/html/index.html
+* NetCDF libraries - http://www.unidata.ucar.edu/software/netcdf
+
+JULES has only been tested on Linux but, given a suitable Fortran compiler, should run on any Unix-like system with minimal changes. The recommended way to attempt to run JULES on Windows is via the Linux compatability layer `Cygwin `_, although this is untested.
+
+
+Building JULES with NetCDF
+--------------------------
+
+To build JULES with NetCDF, it must be told where to find the NetCDF library files. JULES needs two pieces of information - the directory containing the NetCDF archive files, ``netcdf.a`` and ``netcdff.a`` (the *'NetCDF library path'*), and the directory containing the NetCDF Fortran 90 module file, ``netcdf.mod`` (the *'NetCDF include path'*). In a standard NetCDF install, these are often ``/usr/lib`` and ``/usr/include`` or ``/usr/local/lib`` and ``/usr/local/include`` respectively.
+
+If the ``nc-config`` program is installed on your system (run ``which nc-config`` to find out), this can be used to determine values for the NetCDF library path (``nc-config --flibs``) and NetCDF include path (``nc-config --includedir``). When JULES is built with NetCDF, users can supply either ASCII or NetCDF input files, and all output will be NetCDF.
+
+
+Building and running JULES with MPI
+-----------------------------------
+
+.. warning:: For advanced users only
+
+In order to build and run JULES with MPI, additional software is required:
+
+#. An implementation of MPI compiled using the same compiler you will be using to compile JULES. Several implementations of MPI are available, the most commonly used being `MPICH2 `_ and `OpenMPI `_.
+
+ .. note:: The ``bin`` directory of your MPI installation must be in your ``$PATH``
+
+#. A version of HDF5/NetCDF4 compiled *with parallel I/O enabled*, using the MPI implementation installed above. This is *not* the default way to compile NetCDF, and must be explicitly enabled. More information on how to do this can be found on the `NetCDF website `_.
diff --git a/doc/source/building-and-running/rose.rst b/doc/source/building-and-running/rose.rst
new file mode 100644
index 00000000..ec4bb132
--- /dev/null
+++ b/doc/source/building-and-running/rose.rst
@@ -0,0 +1,133 @@
+Automatic upgrading and GUI using Rose
+======================================
+
+`Rose `_ is a collection of tools for managing the building and running of scientific applications.
+
+.. seealso::
+ Please familiarise yourself with the `Rose documentation `_ before continuing with this section.
+
+.. note::
+ This section assumes `Rose is installed `_.
+
+ We will not be using Rose Bush or Rosie, so those components need not be installed.
+
+ It is not necessary to install Cylc, but some functionality will not be available. This will be noted as we go.
+
+JULES uses Rose primarily to provide a graphical interface for configuring and running JULES, but also to allow automatic upgrading of JULES runs from one version to the next.
+
+A Rose suite for JULES will normally contain two applications - an ``fcm_make`` application for building JULES and a ``jules`` application for configuring the namelists and running JULES.
+
+
+Creating a Rose suite from existing namelists
+---------------------------------------------
+
+To enable users to quickly transition to Rose and the extra functionality it provides, a tool is distributed with JULES that can convert existing namelists to a Rose suite.
+
+To convert vn3.4 namelists to a vn4.7 Rose suite, run the following command in the directory containing the namelists:
+
+.. code-block:: bash
+
+ create_rose_app vn3.4 vn4.7 namelist_path suite_name jules_dir
+
+Where ``jules_dir`` is the path to the root directory of the most recent JULES code release on your machine.
+
+The ``namelist_path`` can be the full or a relative path.
+
+This will create a directory called ``suite_name`` in ~/roses/ directory which contains a fully functional Rose suite.
+
+To convert namelists to a Rose suite without upgrading the version, just give the same version for both.
+
+
+Using Rose to upgrade existing namelists
+----------------------------------------
+
+It is not necessary to use Rose to configure and run JULES - Rose can be used just to upgrade existing namelists (at vn3.4 or later).
+
+In order to use Rose to upgrade existing namelists from vn3.4 to vn4.0, just execute the following commands in the directory containing your namelists:
+
+.. code-block:: bash
+
+ # Creates a Rose suite at rose-suite
+ $JULES_ROOT/bin/create_rose_app vn3.4 vn4.0
+
+ # Remove the current namelists
+ rm -rf *.nml
+
+ # Use Rose to generate the new namelists
+ rose app-run -i -C rose-suite/app/jules
+
+ # Remove the Rose suite and other generated files
+ rm -rf rose-suite .rose-config_processors-file.db rose-app-run.conf
+
+
+Upgrading an existing JULES Rose suite
+--------------------------------------
+
+Upgrading an existing JULES Rose suite is even more simple than upgrading the namelist files directly. To see the versions it is possible to upgrade to, run the command:
+
+.. code-block:: bash
+
+ rose app-upgrade -M $JULES_ROOT/rose-meta -C /path/to/rose/suite/app/jules --all-versions
+ && rose macro --fix -C app/jules
+
+ rose app-upgrade -M $JULES_ROOT/rose-meta -C /path/to/rose/suite/app/fcm_make --all-versions
+ && rose macro --fix -C app/fcm_make
+
+To then upgrade to one of those versions, the command is:
+
+.. code-block:: bash
+
+ rose app-upgrade -M $JULES_ROOT/rose-meta -C /path/to/rose/suite/app/jules
+ && rose macro --fix -C app/jules
+
+ rose app-upgrade -M $JULES_ROOT/rose-meta -C /path/to/rose/suite/app/fcm_make
+ && rose macro --fix -C app/fcm_make
+
+
+Configuring JULES with a graphical interface
+--------------------------------------------
+
+Using a Rose suite to run JULES has the advantage that it can be configured graphically using `Rose Config Edit `_.
+
+To launch the graphical editor, the following command is used:
+
+.. code-block:: bash
+
+ # To edit the whole suite, including build configuration
+ rose config-edit -M $JULES_ROOT/rose-meta -C /path/to/rose/suite &
+
+ # To edit just the namelists
+ rose config-edit -M $JULES_ROOT/rose-meta -C /path/to/rose/suite/app/jules &
+
+where ``$JULES_ROOT`` is the root directory of your JULES installation. For more information on using the config editor, see `the Rose documentation `_
+
+Clicking on a variable name in the editor opens the corresponding page in this documentation.
+
+
+Running a JULES Rose suite
+--------------------------
+
+Without Cylc
+^^^^^^^^^^^^
+
+To run JULES from a Rose suite without Cylc, we just use Rose to generate the namelists. JULES is then built and run as normal - see :doc:`intro`.
+
+To generate namelists in the current directory from a Rose suite at ``/path/to/rose/suite``, use the following command:
+
+.. code-block:: bash
+
+ rose app-run -i -C /path/to/rose/suite/app/jules
+
+
+With Cylc
+^^^^^^^^^
+
+.. warning:: This requires Cylc to be installed and configured.
+
+Once a JULES Rose suite has been suitably configured using the graphical editor, it can be run using the following command:
+
+.. code-block:: bash
+
+ rose suite-run -C /path/to/rose/suite
+
+This will set the suite running, and will launch the `Cylc `_ GUI to allow you to see the status of your suite as it runs. The GUI also allows you to view log files etc. - these can be useful when a job fails!
diff --git a/doc/source/building-and-running/running-jules.rst b/doc/source/building-and-running/running-jules.rst
new file mode 100644
index 00000000..bae66258
--- /dev/null
+++ b/doc/source/building-and-running/running-jules.rst
@@ -0,0 +1,82 @@
+Running JULES
+=============
+
+The user interface of JULES consists of several files with the extension ``.nml`` containing Fortran namelists. These files and the namelist members are documented in more detail in :doc:`/namelists/contents`. These namelists are grouped together in a single directory. That directory is referred to as the *namelist directory* for a JULES run. In most use cases, this is practically abstracted away by the use of the rose/cylc workflow. This provides a GUI and rich ecosystem for integration of JULES into a larger workflow (eg compile-run-analyse).
+
+Once a :doc:`JULES executable is compiled ` and the :doc:`namelists ` are set up, JULES can be run in one of two ways:
+
+1. Run the JULES executable in the namelist directory with no arguments:
+
+ .. code-block:: bash
+
+ cd /path/to/namelist/dir
+ /path/to/jules.exe
+
+2. Run the JULES executable with the namelist directory as an argument:
+
+ .. code-block:: bash
+
+ /path/to/jules.exe /path/to/namelist/dir
+
+
+.. warning::
+ Any relative paths given to JULES via the namelists (e.g. :nml:mem:`JULES_FRAC::file` in :nml:lst:`JULES_FRAC`) will be interpreted *relative to the current working directory*.
+
+ This means that if the user plans to use the second method to run JULES (e.g. in a batch environment), it is advisable to use fully-qualified path names for all files specified in the namelists.
+
+ To allow runs to be portable across different machines, it is common to specify data files relative to the namelist directory. In this case, JULES must be run using the first method to allow the relative paths to be resolved correctly.
+
+
+General example of running JULES from the command line
+---------------------------------------------------------
+
+#. Move into the JULES root directory (the directory containing ``includes``, ``src`` etc.):
+
+ .. code-block:: bash
+
+ $ cd /jules/root/dir
+
+#. Build JULES:
+
+ .. code-block:: bash
+
+ $ fcm make -f etc/fcm-make/make.cfg
+
+#. Move into the namelist directory:
+
+ .. code-block:: bash
+
+ $ cd /path/to/namelist/dir
+
+#. Run the JULES executable:
+
+ .. code-block:: bash
+
+ $ /path/to/jules.exe
+
+
+Running JULES with OpenMP
+-------------------------
+
+If JULES is compiled with OpenMP, then it must be told how many OpenMP threads to use. This is done using the environment variable ``OMP_NUM_THREADS``:
+
+.. code-block:: bash
+
+ $ export OMP_NUM_THREADS=4 # Use 4 threads for OpenMP parallel regions
+ $ /path/to/jules.exe
+
+
+Running JULES with MPI
+----------------------
+
+When running JULES using MPI, JULES attempts to find a suitable decomposition of the grid depending on how many MPI tasks are made available to it. Each MPI task can then be thought of as its own independent version of JULES, with each task being responsible for a portion of the grid. Each task reads its portion of the input file(s), performs calculations on those points and outputs its portion of the output file(s). Tasks only communicate in order to read and write dump files - this ensures that dump files are consistent regardless of decomposition, i.e. a dump from any run (MPI or not; different numbers of MPI tasks), can be used to (re-)start any other run and produce identical results, providing the overall model grids are the same.
+
+None of the namelists or namelist members are parallel-specific - the same :doc:`JULES namelists ` can be used to run JULES with or without MPI, and the final results will be identical.
+
+If JULES is compiled with MPI, then it must be run using commands from your MPI distribution (usually called ``mpiexec`` and/or ``mpirun``):
+
+.. code-block:: bash
+
+ $ mpirun -n 4 /path/to/jules.exe # Run JULES using 4 MPI tasks
+
+Detailed discussion of ``mpiexec``/``mpirun`` is beyond the scope of this document - please refer to the documentation for your chosen MPI distribution for the available options and features.
diff --git a/doc/source/code/contents.rst b/doc/source/code/contents.rst
new file mode 100644
index 00000000..f5f88aca
--- /dev/null
+++ b/doc/source/code/contents.rst
@@ -0,0 +1,8 @@
+===================
+Aspects of the code
+===================
+
+
+.. toctree::
+ io
+ known-limitations
\ No newline at end of file
diff --git a/doc/source/code/io.rst b/doc/source/code/io.rst
new file mode 100644
index 00000000..af417ae4
--- /dev/null
+++ b/doc/source/code/io.rst
@@ -0,0 +1,194 @@
+I/O framework
+=============
+
+
+JULES version 3.1 saw a complete rewrite of the I/O code to use a more modular and flexible structure. This section attempts to give a brief description of the low-level I/O framework, and explains how to make some commonly required changes.
+
+.. warning:: This section requires a good knowledge of Fortran.
+
+
+Overview
+--------
+
+The JULES I/O code is comprised of several 'layers' with clearly defined responsibilities that communicate with each other, as shown in the figure :ref:`figure-modular-structure` (the relevant Fortran modules for each layer are also given). The blocks in orange are the JULES specific pieces of code - in theory, the rest of the code could be used with other models if different implementations of these modules were provided.
+
+.. _figure-modular-structure:
+
+.. figure:: io_modular_structure.png
+ :alt: Modular structure of the JULES I/O code
+
+ Modular structure of the JULES I/O code
+
+The core component in the I/O framework is the common file handling API. This layer provides a common interface for different file formats that is then used by the rest of the code. The drivers for ASCII and NetCDF files implement this interface. The interface is based around the concepts of dimensions and variables, much like NetCDF (except that nothing is inferred from metadata - all information about variables and dimensions must be prescribed), but adds the concept of a "record" to that:
+
+Dimension
+ A file has one or more dimensions. Each regular dimension has a name and a size.
+
+ One dimension is special, and is referred to as the record dimension. It has a name but has no defined size. A typical use of the record dimension is to represent time.
+
+Variable
+ A file has one or more variables. The size of each variable is defined using the dimensions previously defined in the file. Each variable can opt to use the record dimension or not - if a variable uses the record dimension it must be the last dimension that the variable has.
+
+Record
+ A record is the collection of all variables at a certain value of the record dimension. The figure :ref:`figure-records-in-file` gives an example of this:
+
+ .. _figure-records-in-file:
+
+ .. figure:: records_in_file.png
+ :alt: Records in a file
+
+ Records in a file
+
+ In the figure, each variable has dimensions x, y and n, where n is the record dimension. Each green box represents the (2D plane of) values of a variable for a certain value of n. A record is then the collection of all variables at a certain value of n.
+
+ A good analogy is the lines in an ASCII file, where each column represents a variable and each line is a record (in fact, this is a generalisation to multiple dimensions of that exact concept).
+
+Files keep track of the record they are currently pointing at (it is the responsibility of the file-type drivers to do this in the way that best suits the file format they implement). When a file receives a read or write request for a particular variable, the values are read from or written to the current record.
+
+The record abstraction also allows two useful operations - seek and advance. When a file receives an instruction to seek to a particular record, it sets its internal pointer so that read/write requests access the given record (a use of this within JULES is looping the input files round spin-up cycles). An advance instruction just moves the internal pointer on to the next record.
+
+The routines in ``file_mod`` define the interface that each file-type driver must implement, and are responsible for deciding which driver to defer to. Support for a file format is provided by implementing this interface and declaring the implementation in ``file_mod``. This is discussed in further detail in :ref:`implementing-a-new-file-format`.
+
+The gridded file API then imposes the concept of reading and writing cubes of gridded data (i.e. x and y dimensions for the grid, plus zero or more 'levels' dimensions) on top of the common file handling API. The underlying files may have a 1D or 2D grid (see :doc:`/input/overview`), and this layer handles the grid dimensions transparently. It is this layer that handles the extraction of a subgrid from a larger grid (see ``file_gridded_read_var`` and ``file_gridded_write_var``).
+
+The time series file API builds on the gridded file API by explicitly presenting the record dimension as a time dimension. It provides an interface that allows users to treat multiple files (e.g. monthly files, yearly files) as if they were a single file (i.e. seek and advance will automatically open and close files if required).
+
+The input and output layers interact with the model via an interface provided by ``model_interface_mod``. ``model_interface_mod`` allows the input and output layers to read values from and write values to the internal model variables. This is discussed in more detail in :ref:`implementing-new-variables-for-input-and-output`. The input and output layers use the time series file API to read from and write to file.
+
+This should provide a reasonable introduction to the JULES I/O framework, but looking at the code is the best way to learn about it.
+
+
+.. _implementing-new-variables-for-input-and-output:
+
+Implementing new variables for input and output
+-----------------------------------------------
+
+The only I/O code that needs to be modified to add new variables for input and output is in ``model_interface_mod`` (the routines in ``src/io/model_interface``). All interaction between the I/O code and the model happens in this module (apart from reading and writing dump files).
+
+Before adding any code to ``model_interface_mod``, the variable the user wishes to make available for input and/or output must be accessible to ``model_interface_mod``. This is usually accomplished by placing the variable in a module and importing the module into ``model_interface_mod`` where required, e.g.:
+
+.. code-block:: fortran
+
+ ! Declare the variable in a module
+ MODULE my_module
+
+ REAL, ALLOCATABLE :: my_var(:)
+
+ ! ...
+ END MODULE my_module
+
+
+ ! ... Later, in model_interface_mod
+ USE my_module, ONLY : my_var
+
+
+``model_interface_mod`` contains several routines:
+
+* Two routines that populate and extract data from the relevant model variables. These are ``populate_var`` and ``extract_var`` respectively.
+* Routines that provide various pieces of information (e.g. string identifiers, number and size of 'levels' dimensions) about the available variables to the input and output layers. Internally, a metadata array that contains information about the available variables is used to implement these 'information providing' routines.
+
+
+In most cases, the following edits will be sufficient to add a variable for input and/or output:
+
+``model_interface_mod.F90``
+ .. note:: Required for both input and output variables.
+
+ Increment the constant ``N_VARS``. This ``PARAMETER`` indicates how many elements are in the metadata array. If you forget to do this, the module will fail to compile.
+
+``populate_var.inc``
+ .. note:: Required for input variables only.
+
+ ``populate_var`` takes a variable identifier and a cube of data on the full model grid, and populates the associated model variable using that data. This is done using a ``SELECT`` statement, to which a case must be added for the new variable.
+
+``extract_var.inc``
+ .. note:: Required for output variables only.
+
+ ``extract_var`` takes a variable identifier, extracts the values from the associated model variable, and returns those values as a cube of data on the full model grid. This is done using a ``SELECT`` statement, to which a case must be added for the new variable.
+
+``variable_metadata.inc``
+ .. note:: Required for both input and output variables.
+
+ This file contains the ``DATA`` definition for the variable metadata array. The metadata array contains objects of the derived type ``var_metadata``, which is defined in ``model_interface_mod.F90``. A typical entry in this array will look something like:
+
+ .. code-block:: fortran
+
+ !-----------------------------------------------------------------------------
+ ! Metadata for latitude
+ !-----------------------------------------------------------------------------
+ DATA metadata(1) / var_metadata( &
+ ! String identifier
+ 'latitude', &
+ ! Variable type
+ VAR_TYPE_SURFACE, &
+ ! Long name
+ "Gridbox latitude", &
+ ! Units
+ "degrees" &
+ ) /
+
+ This allows us to define all the static information about a variable in one place:
+
+ String identifier
+ This is the name used to identify the variable in namelists (as seen elsewhere in the User Guide)
+
+ Variable type
+ This indicates the number and size of the 'levels' dimensions for the variable. For a full list of types see the file ``get_var_levs_dims.inc``; some of the available types are:
+
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | Type | Number and size of 'levels' dimension(s) |
+ +======================+=====================================================================================================+
+ | ``VAR_TYPE_SURFACE`` | No levels dimension |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_PFT`` | Single levels dimension of size :nml:mem:`JULES_SURFACE_TYPES::npft` |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_NVG`` | Single levels dimension of size :nml:mem:`JULES_SURFACE_TYPES::nnvg` |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_TYPE`` | Single levels dimension of size ``ntype`` (:nml:mem:`JULES_SURFACE_TYPES::npft` + |
+ | | :nml:mem:`JULES_SURFACE_TYPES::nnvg`) |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_TILE`` | Single levels dimension of size ``nsurft`` (1 if :nml:mem:`JULES_SURFACE::l_aggregate` = TRUE, |
+ | | ``ntype`` otherwise) |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_SOIL`` | Single levels dimension of size :nml:mem:`JULES_SOIL::sm_levels` |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_SCPOOL`` | Single levels dimension of size ``dim_cs1`` (number of soil carbon pools, i.e. 4 if |
+ | | :nml:mem:`JULES_VEGETATION::l_triffid` = TRUE, 1 otherwise) |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+ | ``VAR_TYPE_SNOW`` | Two levels dimensions: the first of size ``nsurft`` and the second of size |
+ | | :nml:mem:`JULES_SNOW::nsmax` |
+ +----------------------+-----------------------------------------------------------------------------------------------------+
+
+ Adding a new type is a relatively simple procedure:
+
+ #. A new ``PARAMETER`` must be added for the type in ``model_interface_mod.F90``
+ #. A new ``CASE`` must be added to the ``SELECT`` statement in ``get_var_levs_dims.inc`` that correctly returns the number, names and sizes of the levels dimensions.
+
+ Long name
+ This is the name used in the ``long_name`` attribute for the variable in output files.
+
+ Units
+ This is the units given in the ``units`` attribute for the variable in output files.
+
+
+``map_from_land`` and ``map_to_land`` are provided as utilities for use with variables that are defined on land points only. ``tiles_to_gbm`` is used to provide gridbox mean diagnostics for model variables that have one value per surface tile.
+
+As always, the best way to go about implementing new variables for input and output is to follow the examples that are already there.
+
+
+.. _implementing-a-new-file-format:
+
+Implementing a new file format
+------------------------------
+
+To understand how to implement a new file format, it first helps to understand how the common file handling layer works under the hood.
+
+Each of the routines in ``file_mod`` (see files in ``src/io/file_handling/core``) takes a ``file_handle`` as its first argument. The ``file_handle`` is a Fortran derived type that contains a flag indicating the format of the file it represents, and each of the routines in ``file_mod`` contains a ``SELECT`` statement that defers to the correct implementation of the routine based on that flag.
+
+``file_handles`` are created in ``file_open``. Each file format implementation defines a list of recognised file extensions, and the appropriate file opening routine is deferred to by comparing the extension of the given file name to the recognised extensions for each file format.
+
+To implement a new file format, an implementation of each of the routines in ``file_mod`` must first be provided (the implementations for ASCII and NetCDF formats should be used as a reference). A new ``CASE`` deferring to the new implementation should then be added to the ``SELECT`` statement in each of the routines in ``file_mod``. The recognised file extensions for the new format should also be added to the checks in ``file_open`` to allow the new the file opening routine to be called.
+
+Implementations of these routines for ASCII and NetCDF file formats are given in ``driver_ascii`` (see ``src/io/file_handling/core/drivers/ascii``) and ``driver_ncdf`` (see ``src/io/file_handling/core/drivers/ncdf``) respectively. These should be used as examples of how to implement a file format.
+
+These two file formats suffer from opposite problems when implementing the concepts of dimensions, variables and records. For NetCDF, the concepts of dimensions and variables already exist, but the idea of a record has to be imposed. For ASCII, the concept of a record is a natural fit (think lines in a file), but the concepts of dimensions and variables have to be imposed. Between them, these implementations should provide sufficient examples of how to implement a new file format.
+
diff --git a/doc/source/code/io_modular_structure.png b/doc/source/code/io_modular_structure.png
new file mode 100644
index 0000000000000000000000000000000000000000..f973ad555e244c1ac556941cbb3369c688341ee1
GIT binary patch
literal 24670
zcmd43cUV(h_a=M*yCR|}9qg!7=^cC!ln&CQBPdlsdM}m-l&T=TOOr0W1PDrrf^v-jC$?X}ms?|bn^N9!K_3APgu1ktPB
zzxx1!=%OHqw)of)@QK^~0XgvBA&Jf;h^A4y%k(z!
z==p0G-`h9$sGPXl`8fA%-P%vb2MDH(`oFL)f4PN(__{Wwq^C%Uc-Z!(WKed=vxfub
z)A51*DUWRBJ>ff>p(sCp7E*JC>2*%S2K@E@*oCNkEXIZ$usp_N`hX-kpKN1Y-+c0euS*jt?DfHx&m%?%lGeba
z+jWYC_&GK&nA@SYwi>upyvZ+GD8i@CgWvw(Y5g6&HRsx_&u~SCos%=VT&ntSWe8fd
zqB~0NY6>_owt8&W-rhcVu*SS#4z}xU?ml$^^_voML#V16EX%_hqU*nYu__mQr7L9n
zecLezQWSm;ULJb4dR+ht-4w9YCk%6)^&JuV)tjRqZ8O6!+y4@apTqO3
zm&q1<$fU~_S$uTpBD3oAa!zcYiOlE;#f8E4V~Rbs!dK5X-cxz_)KWRvoaV8r)uHT1
z`AYL@F9$XRG5N8YRP&v~vd-+PyCvvg{&oZ2QQdz3IdsK>Y@Rc6gTp{N$-%KqUnzGX
zXX>IMo@5X}uP+ml&}UlKp2IG8)S=F`@Df(Bk|pkhVnJMMGI}Up91PgeF&AyoR71!s
z%SHPS7mv8)qGZWFjdNtQ4t^aSwVtR_R*`RFiHsJ|Mj%Zra%)Ep31x7pK*AEE9=E9{
zmqt1SM*Z#L615p5Rq;m4Gpde-6FZ~WiW&=kvQ}A^w{U#kx^YRK&5e55Ua5~>A){z@
zJ*5k5LG+^41plmQwS`aEgOegbU#?}l`Lob`9oZ1fiauRd;uYe6))Wc+G?BDYbkKLX
z&ESFaLG7xH<_*`HFi|{DSz3Z)#ml9B^Hhu?zq7Vw#k)EuzhHK`aJ||Sk&0rVryF@6
z`aYy?N-GRGbor?-n>%#|n+|$k*;OCUrT;SlX*I+6(t+00ZMGX&e8~_4NANFbXaH=(
zB{5v2w@ARlwbMrkw|dqM%Z)10#*gp`Mhq6%nTEMA%K!px0@%P%w#5VohRj0qMi<79
z;cdqhAL*y+csYi$oj6M;`r7nxTZR6F
zyde6T4+NFIJNy-cqP4VFQ^cgCq*8nsnNUA}T6G|U1dmLU!kX1-Ajn-57{rDUEwFzL
zt3$vEy!&J1m;W(x+AH8NzB!}<{ylpfI5z0&Sr(e?i)@XLWFgV^mFAOBsBPK_>v)Rg
z*fVxLHir@eTTXw&oMnv@9m>TOi&egybR%k3hpf8Nnh(0e0*D16s;-9GKQ&I%Dxa(%
z+=#^7RxCTEdKi8!urCwGoli|em%J0gCPszRD-&mO{TReF5eIqehAz~lSP5KnLcmm9
zU6HOv!S{asD)16NygzsH~j3hKQqL_6?6&+=1YNRjr=7jx-DH4{n1JS!c3zLBON
zk$leORL`k`x|?P76Mm(6i5|D*t{RjSCYm?~$q&h6dVMn^H>8i)UsrlS^HsU=tzPjE
z^X|}8of-{~GeQ}u#kbTfX5!ki@ZrJ3vU~huc|qlARM`b8Xdw<3>Z7_YorW%+*8W~t
z9_>J7#6F0;O}CNCc9Z3_(HpQSxfHuUSN
zs)&1H+Qoddw_R~jid-S@TH}rSgBmgBxgV)y@RmB`c<|-Ne8=t7>C-BE;}q-PoUUIH
zOjcoPO?H;4yFbMI51QO5UFyRwse;SoQvs#`uF!cng$v3gB
z6m?J~`R+sB*MzF#_xJZ3$XzAt0(9B@#~BH|>qmbpsDx~;F9wk!PpLk!qf)82W!G@c
zJz%!(qI#ZD0GE5D1%}pD-QE0o-67zyNqG_mJ$k-jIz8&)=Ds?X4`};gRo8P{D`<)LflOn}~@_OHhi^(oyeN}Sqy`HzfhSe+a+v4IE1Ovu;
zW@{^goG1JiGW?S0YQ8Qm+H?5*ddJAoC!!#mYkro>tB)5OX=OPe@6=@|U
zCASgXd!66}<4@%3n6)2so(*Gnd2Q4@d%p5fdl(Bldk=ymTUkqvJR-TXn2TG?jg8UM
zmJ=hoLyJPRS8CoMspH7#_R}(ar)7V)HOxlvt_d8qf6iOpaM^o0h_Xl^L{Cjk{RpB=
zQV$pu)sIIF95Jl0;Oq~WTK|AR$efn?^>%AwL4F~XE_p`f-aXuhNP&oJ>WM24>mGlL
zYgqgcY3=DLiu?jC-T*IqexBE`TFIpSH!z_@6wBDQ?EJPaJ;FcM`M5fIpc|^*4CHhDUJP|m%=%!
zdTb&u@JI9rB4xviLv7XAB22mm^dS>vt5>w9z${k4*lxQ{HJft<%<)>XN=*6Yesi@t
zQY6Y$`#z@#s(I0N?67!HRoVlvx1_Zsq-=T1CKi3+u&8os&d2;ynuoK;4yoMu2!`Ri
zm=kV|q;B#e`aUQ}Y6R1X-2I;(froH`-$dUnBQrBIIXU??h%zo192QmL|JM{nz!VkF
zojXSwtq2yoAYk^;YZ9EVtzSF}V=utaKid6kiisOIi_pZzrGhl;&o2(YiJyEgy_o%S
zwz#A`qO!7bacRlnj+bI$AFxXJEorW;eyA$y=D6T#xs8E{@t_5n={NVdgFI2w;9YL>
zDRx~F$nD+&I3{6a$q5x`-I{&a?CVzSW!Im{xl2TbOgw9+CrwdW>l^>3NkQzb_1HXp
z`V=({q9?bx1S3QGD9Ut5Na@2$>q72`J^Mq7Xs{s3U~=H?AD1GhN90%!tJo_91qFd9
z(Fjuq!b~r7$}z~HF^uuV{92EoU;uBld*;F30?H$EJ^dlrl=xy=DEk~(j*B=P&aH>P
z{%%M}Nbfk8=fEA8N*YM90KDOCNkywPY|5#t?c(_r6@sl)f-BLJA9xedzrf};E*F=~
zw$U+^2J9LkcScF|A-naghKC?Uo^vcY7sJBBE`O*rK5e<(ZPZ1^SaO54U^O`Wuipx^
zYz(FHAa05Q!}t+EY|#v+gA}h%7}A}X%{ti5!jVwi(@XP{J&F7!(lmW@NtRsNvZM~J
z9v86v59^*9>n$IGvOSJP>6|&(Cmys8PrrQmveKJ?EgqL6b)35`B{f!B1;?V`!T>k#
z{r|(87lQ6z{c~0SUpKJ#o&vWl)GH<}&4#fEAZYbu`Y#vhkC&Sx#E%?3>a#ZqeEdR&
zk44z1?qm2m`2LJC;h}Bj{_UFE*Gu6m550dp3h!+8TfgOk!C;uLT)6_z=Jo3zObVt*x!+RKNm<3&}Hyf|gto(}5n}Q$%=xDJT0QfYE2Xm?6|pb0t~$7k&D1
z2e>c@;4D+lb6^2)i;C*6*O}J4
zM3eCtRCfYzwP4g==U8Z(6x78ZWsCa0v!2zN$j?$Ime)-Olt=;*jRiwpa3_7Yfh
z#e2n~aKnOQaF;oKlDMeF<>iQQ?qJ`-xv&qy%6~@cjfaNYPtGMaBB*Q$C`wecSKf&t%CXdbg#eP25`Eym|Am-o<>Be50tW@Ts3xXDA7;oAuifL@@?2)4-
zMkphf#%nG}LLJzeg(rfM3k34Gl#$An%wYe3Jxram+c>7x(5+>xKlL25<=WDZpt{&K
z@4BGzx~)gP7GT+t;5G<6$y@0-THN44UT%0YTI{=5iJIL8_XsJD
zYLVz;{CEZFGc9MmxzeznwHhIFuvFgMbIE2JLCJjmT5>U=B1%D$)FJ6MR<%eZRy1X3
zvxbU`$jftab8tjeOu4J`u}R8WtnZwgolrjzAXbGQaW?a@oT#?d3|x*=pZ)#(`PQ#a
z<^?VeqjED=?w#M^HZz~Y?;gCn*ELr^&DuZiRAJ^s%eMZt;OOj>Yv2_vzaCTTiUm1A
z0n^G4*3Xz&Xs}OT$;D4Jml$o6gP6Hkb_HaGrrf6jtZ_}dv+wJh
zuf@pDzHWHh837Cd`y?oS3aWV%dqB2CiCOMFF!SEcaGPayWxnv}i0N9`xmm31p&T4RL)=|G
z3EL_mm^>Bqo;jv18!
zgOcK=J_L!ol=NzBBI?|M*kDZnPE$jpgMDhNYinJby%WlKI@mVj*2aiD2X6;wkA^>;
zjulawGO;zRy{9?#q$c5>xZD{^AP#@K>XFjZ={kO*yA`v?d|!0yONN+fzeysh^(2Ev
z%VZHzUQj-;YkaojoOTp&DH={YAR^-1ei?5~++G)PX0})8(FzIJ8&l=!VlB+L0B#*H
zU)?g3+FQZ+zXgkzPCnt;?Zm~R?Bs=66oP)elbrRc5V?Kk?^@
zGwn-3395~jP?}pdBRY99nL?;%D-6YCO
z?C%NgUvBlrm)&-9cXt;ieh4+EKYbeZ2sWhIP6Nz3lJtFJx&3rxy~WmZ$)7)!)&%l@
z*SU^gAj*@XN%PhHZ?3sYULv|*tVOhXn@+fs7jSwKK{rPkI83twg{LYvD6@sRxo?K2
zF@M4@ZkKK2^!--k*E~5ZTS>B5MFjWLiA6S*(95tt7#!4nbUQ!IaNnGR)Py-6S(5>G
z9^*TSpCu{;sTPwL2#t0t^}pL#*x0&D!z#*6&eN$U*`m3GME3fK+~-OR%RsspVLw`I
zK$1a*Xny$DwB%=|^pJGV&{TKJJ0}&1`j2twROwZBlo5gC9oJd;
zJ#St28%PXf17iLBl4zKcLF$_AGD_=%GS^i#x{i%c#%!|jFYNQl)l;sG&b&pQr&P%rmWE5dPEui|eY&;eVUBx^
zRE)ow1D@{2Es&O8yyMVz1CwURCK*S2A2j>nimh9ISC{Eury8KeUUsv@BYw_Y-az71DusdLGCV2Id!!kv^-aE;Zc<5_uj*6~LKs8suB!!fc
zI|^kNj%3RN>?J$O_Eltl%gN%+h=}6C(z*TZh<8kA3jo1i#@v^a@QwF(I
z&uO<--qM&eN#}Tt3>fe~@C68>9)mo$CN$^GsMI~E6M!lZ!1F-Rv!}3Hh6(Jutr&3o
z>Ul^yIpBnCF51)+syPW7|2}w3dV-wvA3#UBxGcH#k0^@i#hz6BCvv+~1bH?)whI?B
zNbuFKZp`JkIOjVT1T|0W4~@ioTRP}t?_qITG8<%%A2jhC<+6r0ZbeVR)=UNxR
z3`lA(9}eNv1DIFN@)aDI^9Npa)^jm#q>ets(SamG#!3%n2NYMG^!zqvA(9n{%{}
zQ%&N~N0VV}=KjqRi@efuij#7Mp@XXhqp1Ic>hpSCWm#>=_zc*YPOQV$hfLAXzUxA?
zit(c&8e);&>xLUURafu(gyk(r^^z;*&^;ewOvd?#YU}-)?|BaGJ}?9wOPee)Bh=!*
zzqe>NYZS|$RMm*w0Gc9FM5JdsgNtZ_Dpoh5K9$pvM@yH;n#JXCmk`uXn&W(
zoqdmgcoSZAZUQg|Qj9Lv^wcMiYU-Pd$Y@F93AIAB`0$i};l%5|^H7egmj=Je7r6jf
z7=j$*MIWEHXV6nh8s-zMwy^S
zeS4$U6hI`)!W*^Y)+BZ<;I5Y6cHY%CPGb|e_3+(!aK7yW>_UDkxpf_waKLfKY00g(
z%{|XYxF$Zy!!GvEH9&mu2ZpO@fv+27%dOo%cNP4&g_O`4I3Q~7c~QkRUUdyLyTmoN
zp%}PTo#jEjoN{w{zzLhwcC0PxlhrhJcF5Evdc5Lbw}HrR8EYxK?>lwvj&T5ppO10`
zK1<&vA^Q+a!q&%bh$O&G)^_Gx-(Uno)Bym*`2lUL5N|7>iIwkdBG;JqyNwRn)|w1=
z+hkpZ&FVMq(np(M5mqW3_cGyd+)73GofZ!M4m#Udb_9Y(ZaOsBI8>lV
zq#Y8qT`Nq+hwBB+>kY*667=!%7m(!~+kLdIc
zO&$KbEP7LaRm`AC_U1r>sl41>gMbz-=d2o+636?zMd-Yr582Fy)2G#X%#lAN!A6I&
z_9v-S8Q#=LIBC}#r+=@+>3&HK+I`^@dfn6|Na3uQ7O=X%XWLu6l_l+zKjx%g4t6+V
z&kX#Nrh$X6PA%R*Eu3GIpBJN&`sf|mV)_AI-l?(NVY#vfv#c+}J&G-xo5
zmRc4SI1==m3{QlbvjPsl^d>XZ&7ZaJ^WdVB3Q@07oR?5y++yVr+nBOYfUYwo%hKp%
z091S2Sfr_OMdP`H|MpO+QN@sne45aQU|Oz^O2k?8Ti
zq>K-J5v@M2MMY#9@1&l$R(uEvh^(F3%o(gRHCM{r?VYV-
zaVdKz_na{_X6P$(xG2*5q!;x4Drl&o*Y7Nznvb4&2)z{p!MhMH0Z)_ORGvRJBN(}v
zW^9wc9v|*5rjOvs$Ez%f&bja&G9ChC0m|X=*>Fe9*+h$gA2AU+KDDMUBkW9t)0>B|
z=2I0oll|!)gyAv|IQxtRt)-8}aF(?}*Z%HyuReqxHbmd*75L%kU~5~NKh+#VXDfZ_
zlL!cEYV@(YtOa8QnE}G$INRS27*&xgRu{-40ejI}$KKBcS4pF4YmT7?=4HI6_b5#h|!aZ9w1W|c_p~xnVRxD)$-4IIVuEy$oc*5m0pa?Lc`>;vrnId
zjwe_-&Kt#T0pgyK!m>sm@)Zuiof21pHx3?6q1;f3vwn
zF+^A%)d*|5)0B`IFPduL+DMMCyXkXEwZ|!_xA5JlQ!94AdN1Tq_IWthk)WzOrwV2z
zyy)HVDkv|zMaggU3{lje!3-<1Jj|$1Lyq8JzcTBd}9jQx*soan?DsG%0
zC9GB(_7(%nQXRhvR{h`oqvy&k4@LBWz@l62gsSS$t182fg<U!
z&o!Ss{4_pE#d2M5oN0TT?&IIUz;i~|<`7ex_;*j}Asu~y*t~sndE)!DYM20t6|6vK%w#Q5U&E`+hqSe3_vSmfSs=dc_&xP%|rLi6_x8J#RZE
z^iqHKOUmX+ht#Em^#*0d78Iu2#L1yP(I4-Ce8=W!ETPG6+`75!AQ4HmB}w1HmWcsm
z9*3;k!j^1bd%Bhs_!
zJZ|k`1a26eyMlo;CvnWN2Y@daIP&U8pGe&k^^MI<(4d05FjN>^Pf{0}w>rT>GU*c4
zEzVw{OeOiSc9dh*=Qszdnrti17n_gY4-!{cd&VdGGgJe+jK@c2$?oa=d671^-_@O+
z9bhGwO#slgHySR_6tXiIyI`(X;Fyx0e}g9XhL=W>q4v8zx2c8l`wN%V+kK`vxdW%O
z?1l_|e0)|8){;;!+0iJPqug<-X>H#>&8)h1l2BZ{AfwdpVVFTsg~cvON5DPoz9*@DHgaZLoy
z3%;hNAvp@u-PJt3yq=)vmkP7EoLrIoAa+PJPV>N7hyvE*j}|~N0I>k>;pfkv1LzjS
zN)e7@RZmFkSyU(4s-@?EraSSIIaYzo61fz%_4TJ!0bz4vqeF@qXgBd}sSwV1wa4q7
zBk}TnZf14X%6A*ejwt4sgYV2JMMzSQ!Wm4^+U!=_VdlGF_Vdn2iX8FH3<7x`4q(>n
zo^P(r^_NB|NRvl6t8br-f)3aDl4c+7hlj9a?f$s8E^zqkV6l@t_wL3DXJJ;bzaEwd
zV6So47BP9hDTEC^UR(SLw<0OXm4N-R*TyiL%f0_Q<_QcjWO!_jkv>cZx|oqGV}F^S
zc>6M>d1i;DkvPTK-kzFYUoTPKurahXu;dyEhah^C!%Y2MUX;$VEQGMj{w(t!jG^Xv
zk74QS_6uBRxC0hs0^hwnT?z8^hGiS>H-#$P(O?|4*LKYST5aaH{lsl>%&rq`ZT;gc
z#r@We6khAm^GPU$DerNC_Nl|buK*CcnWrxZmDRDEly&yt)9l&yE~_I5+)l`AA3kb}
zTX0DVN`<^QxN(bspF
zj+EhA{)TvJ@;nT+?INiJu=(HeGXdzfwOWtl1j%=V&%xl$!4`}K35$!3g%K!#SoP;$
z&vt`@SvWF8hu}@!rc*0WpQ%(*Z2csRc08&7!}gASVSD}_K)W^sY^{N7pRA-L%f7^_
z20*!CKyM2rLyX!*mqmt$Y~(hpe^7-Ppx3W`0U6+4{>s+)_iR$fhka$Yp*K8Tw^1DN
zraF9flTBW3I8BMp9eVcJEF`%MKzK&3DxdWcCNSG|zu(pWU*FjegRTNJu_jdlrOs
z&c!7qFl+Z7Cc)MO{=Uuz#28m%WrZ(aUTxi7)#qM)TMJD858`=Bc=H2u%MC60?Oze~
zj;w5K5xFtaw~mOk9`F#9tPX|J$^g6+Cbp(X(|{?n>^o00pbDTQ=&)Dkd83Y11d*$y
zrDbq@oE_%n%-lN9`z0M#JPOWKcIf|(vVxcfMs!BTst*>H-;Gt