Fixing broken relative links in docs

docs/users/batch.md

@@ -2,21 +2,19 @@
 
 The model allows for multiple simulations ("chunks") to be chained together, such that the final temporal state of one model simulation provides the initial temporal state of the next. The main advantage of this is when wanting to run the model over long temporal periods: The model stores all input data in memory, and so long runs may use a significant amount of memory (depending on your geographical setup). Batching runs together means that only the input data for the current chunk is stored in memory at any time. 
 
-In addition to the normal config file (which for batch runs provides config options for the entire batch run), batch runs need a batch config namelist file, which specifies the location of the input data and temporal information of each chunk within the batch run. An example is given at [config.example/batch_config.example.nml](../../config.example/batch_config.example.nml)
+In addition to the normal config file (which for batch runs provides config options for the entire batch run), batch runs need a batch config namelist file, which specifies the location of the input data and temporal information of each chunk within the batch run. An example is given at [config.example/batch_config.example.nml](https://github.com/NERC-CEH/nanofase/blob/develop/config.example/batch_config.example.nml)
 
 ## Running a batch simulation
 
 The model will run in batch mode if a batch config file is passed as the second command line argument, after the normal config file:
 
 ```bash
-$ ./bin/main /path/to/normal/config.nml /path/to/batch_config.nml
+$ nanofase /path/to/normal/config.nml /path/to/batch_config.nml
 ```
 
-where `./bin/main` is the path to the model executable.
-
 ### Initial (normal) config file
 
-The initial config file is just the same as a [normal model config file](../../config.example/config.example.nml). Most of the config options are used for the entire batch run, with the exception of the input and constants data paths, start date and number of timesteps. 
+The initial config file is just the same as a [normal model config file](https://github.com/NERC-CEH/nanofase/blob/develop/config.example/config.example.nml). Most of the config options are used for the entire batch run, with the exception of the input and constants data paths, start date and number of timesteps. 
 
 ### Batch config file
 

docs/users/temporal-period.md

@@ -1,15 +1,15 @@
 # Running the model for different temporal periods
 
 The temporal period that the model is run for is defined by the model config (or [batch config](batch.md)) and NetCDF input files:
- - The *start date* of the model run is provided by the `&run > start_date` property in the [model config file](../../config.example/config.example.nml).
+ - The *start date* of the model run is provided by the `&run > start_date` property in the [model config file](https://github.com/NERC-CEH/nanofase/blob/develop/config.example/config.example.nml).
  - The length of each time step is given by the `&run > timestep` property in this file, which is given in seconds.
  - The number of time steps the model runs for is given by the `t` dimension in the input NetCDF file.
 
-Hence, the temporal period over which the model runs is the length of the `t` dimension in the NetCDF file, multiplied by the time step length from the config file. The important point here is that the model ignores the `units` attribute of the `t` dimension, which is commonly used to describe the start date of the data. Additionally, there is no check that this `units` attribute is the same as the config `start_date` property. This is intentional: It allows the same NetCDF file to be used to model different time period, which might be useful for ready the model to steady state. The upshot of this is that changing the `start_date` config option doesn't change the data that is being used in the model run, it is simply used to tell the model what the start date of the NetCDF data is.
+Hence, the temporal period over which the model runs is the length of the `t` dimension in the NetCDF file, multiplied by the time step length from the config file. The important point here is that the model ignores the `units` attribute of the `t` dimension, which is commonly used to describe the start date of the data. Additionally, there is no check that this `units` attribute is the same as the config `start_date` property. This is intentional: It allows the same NetCDF file to be used to model different time period, which might be useful for running the model to steady state. The upshot of this is that changing the `start_date` config option doesn't change the data that is being used in the model run, it is simply used to tell the model what the start date of the NetCDF data is.
 
 ## What if I only want to run the model for a slice of the NetCDF data's temporal period?
 
-For example, say you have a NetCDF file with data for an entire year with a daily time step (like the [example Thames 2015 data](../../data.example/thames_tio2_2015.nc)), but you only want to run the model for one month of that year - let's say June.
+For example, say you have a NetCDF file with data for an entire year with a daily time step (like the [example Thames 2015 data](https://github.com/NERC-CEH/nanofase/blob/develop/data.example/thames_tio2_2015.nc)), but you only want to run the model for one month of that year - let's say June.
 
 The bad news is that the model doesn't currently provide a way to do this without creating a new NetCDF file. If you were to change the `start_date` config option to `2015-06-01` and `n_timesteps` to `30`, the model would actually use the first 30 time steps it encounters in the data file (for the example data, corresponding to January), but write to the output data that it was performing the calculation for June.
 
@@ -23,7 +23,7 @@ If you have NetCDF installed, you almost certainly have the NetCDF command line
 ncks -d t,start_time,end_time in.nc out.nc
 ```
 
-where `start_time` and `end_time` are zero-indexed integers (use the flag `-F` if you want one-indexed). So, using our example, to slice June from the [example Thames 2015 data](../../data.example/thames_tio2_2015.nc), we slice between 152 (1 June) and 181 (30 June):
+where `start_time` and `end_time` are zero-indexed integers (use the flag `-F` if you want one-indexed). So, using our example, to slice June from the [example Thames 2015 data](https://github.com/NERC-CEH/nanofase/blob/develop/data.example/thames_tio2_2015.nc), we slice between 152 (1 June) and 181 (30 June):
 
 ```shell
 ncks -d t,152,181 thames_tio2_2015.nc thames_tio2_june2015.nc