diff --git a/documentation/docs/fullsimlight/fsl/index.md b/documentation/docs/fullsimlight/fsl/index.md
index b833b12d0e084313aa09d3f3dac0df25230a988c..333815bfafee233f3278df9da9ce896d676598b0 100644
--- a/documentation/docs/fullsimlight/fsl/index.md
+++ b/documentation/docs/fullsimlight/fsl/index.md
@@ -6,7 +6,7 @@ fsl is a GUI for FullSimLight introduced in GeoModel release 4.3.0. It allows u
 ./fsl
 ```
 
- Compatability of the simulation is ensured by the fsl interface by enabling and disabling options based on the selections made. Once the user has configured the simulation to their desire, they can save the configuration in a json file that can be used to run FullSimLight through the -c flag. 
+ Compatibility of the simulation is ensured by the fsl interface by enabling and disabling options based on the selections made. Once the user has configured the simulation to their desire, they can save the configuration in a json file that can be used to run FullSimLight through the -c flag. 
  
 ```bash
 ./fullSimLight -c /path/to/config.json
@@ -30,7 +30,7 @@ One can also load in a configuration by running fsl with the -c flag.
    urlFix=False) 
 }}
 
-The main tab allows configuration of the following parameters.
+The main tab allows configuration of the following parameters:
 
 - Geometry Input
 - Physics List
@@ -51,7 +51,7 @@ It also contains the view button which shows the current configuration on the ma
    urlFix=False) 
 }}
 
-The generator tab shown above contains a list of event generators that can be selected for event generation. The options provided are
+The generator tab shown above contains a list of event generators that can be selected for event generation. The options provided are:
 
 - Particle Gun
 - Pythia
@@ -60,7 +60,7 @@ The generator tab shown above contains a list of event generators that can be se
 
 ### 1. Particle Gun
 
-To use a particle gun, the user must specify the particle type and momentum vector.
+To use a Geant4 particle gun, the user must specify the particle type and the momentum vector.
 
 ### 2. Pythia
 
@@ -70,15 +70,16 @@ To use Pythia one can select one of the pre-customized options which are
 - higgs
 - minbias
 
-Alternatively one can also provide a custom file. 
+Details about the default options can be found in the `PythiaPrimaryGeneratorAction` [class](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/blob/master/FullSimLight/src/PythiaPrimaryGeneratorAction.cc). 
+Alternatively one can also provide a custom Pythia configuration input file. 
 
 ### 3. HepMC3 File
 
-HepMC3 files containing events can be used in FullSimLight in the both the standard Asciiv3 format (introduced in HepMC3) as well as the old Ascii format (used in HepMC and HepMC2).
+HepMC3 files containing events can be used in FullSimLight in both the standard Asciiv3 format (introduced in HepMC3) as well as the old Ascii format (used in HepMC and HepMC2).
 
 ### 4. Generator Plugin
 
-In order to generate events one can also specify a plugin. Visit the Plugin Support page for more details.
+In order to generate events one can also specify a plugin. Visit the [Plugin Support page](https://geomodel.web.cern.ch/home/fullsimlight/plugin-support/) for more details.
 
 ## Magnetic Field Tab
 
@@ -93,7 +94,7 @@ In order to generate events one can also specify a plugin. Visit the Plugin Supp
 To set a Magnetic Field, there are two options
 
 - Fixed Axial
-- MAgnetic Field Plugin
+- Magnetic Field Plugin
 
 
 ### 1. Fixed Axial
@@ -102,7 +103,7 @@ Sets a constant Magnetic field in the z-direction at the specified magnitude.
 
 ### 2. Magnetic Field Plugin
 
-In order to generate a Magnetic Field one can also specify a plugin. Visit the Plugin Support page for more details. A custom ATLAS Magnetic Field Plugin comes with the GeoModel package ready to use. This is automatically contained in the atlas-conf.json configuration file provided by GeoModel. ***Warning: This Plugin requires the ATLAS Magnetic Field Map to be installed in a standard location. This Map is available to all ATLAS users on request.***
+In order to generate a Magnetic Field one can also specify a plugin. Visit the [Plugin Support page](https://geomodel.web.cern.ch/home/fullsimlight/plugin-support/) for more details. A custom ATLAS Magnetic Field Plugin comes with the GeoModel package ready to use. This is automatically contained in the atlas-conf.json configuration file provided by GeoModel. ***Warning: This Plugin requires the ATLAS Magnetic Field Map to be installed in a standard location. This Map is available to all ATLAS users on request.***
 
 
 ## Regions Tab
@@ -115,7 +116,7 @@ In order to generate a Magnetic Field one can also specify a plugin. Visit the P
    urlFix=False) 
 }}
 
-Regions can be added through the regions tab in FSL as shown above. For each region one must specify 
+Geant4 regions can be added through the regions tab in FSL as shown above. For each region one must specify 
 
 - Region name
 - Root Logical Volumes
@@ -124,19 +125,19 @@ Regions can be added through the regions tab in FSL as shown above. For each reg
 - Positron cut (GeV)
 - Gamma cut (GeV)
 
-A list of ATLAS specific regions comes in the atlas-conf.json condfiguration file provided by GeoModel.
+A list of ATLAS specific regions comes in the atlas-conf.json configuration file provided by GeoModel.
 
 ## Sensitive Detectors Tab
 
 
 {{ imgutils_image_caption('fsl-sen.png', 
    alt='fsl', 
-   cap='fsl sensitive detector tab',
+   cap='fsl sensitive detectors tab',
    width ='700px',
    urlFix=False) 
 }}
 
-In order to add Sensitive Detectors one can create plugins which can then be added to the simulation through the menu shown above. Visit the Plugin Support page for more details.
+In order to add Geant4 Sensitive Detectors one can create plugins which can then be added to the simulation through the menu shown above. Visit the [Plugin Support page](https://geomodel.web.cern.ch/home/fullsimlight/plugin-support/) for more details.
 
 
 ## User Actions Tab
@@ -149,4 +150,4 @@ In order to add Sensitive Detectors one can create plugins which can then be add
    urlFix=False) 
 }}
 
-In order to add User Actions one can create plugins which can then be added to the simulation through the menu shown above. Visit the Plugin Support page for more details.
+In order to add Geant4 User Actions one can create plugins which can then be added to the simulation through the menu shown above. Visit the [Plugin Support page](https://geomodel.web.cern.ch/home/fullsimlight/plugin-support/) for more details.
diff --git a/documentation/docs/fullsimlight/plugin-support/index.md b/documentation/docs/fullsimlight/plugin-support/index.md
index 11545da20cd04cff9b9888cca6e6220499b4b8c4..1943fc80f63069b36a0eb6d8efc2c4a1ebb13715 100644
--- a/documentation/docs/fullsimlight/plugin-support/index.md
+++ b/documentation/docs/fullsimlight/plugin-support/index.md
@@ -1,10 +1,10 @@
 # Plugin Support
 
-FullSimLight provides the user support with writing plugins by providing the abstract classes which one has the override. These abstract classes serve as a link to interface various Geant4 functionality with simulation using FullSimLight. Header files containing these abstract classes are automatically installed with FullSimLight installation.
+FullSimLight provides the user support with writing plugins by providing the abstract classes which one has to override. These abstract classes serve as a link to interface various Geant4 functionality with simulation using FullSimLight. Header files containing these abstract classes are automatically installed with FullSimLight installation.
 
 ## User Actions & Event Generators
 <!---->
-The header file which contains the abstract classes to create plugins with User actions is ***FSLUserActionPlugin.h***. 
+The header file which contains the abstract classes to create plugins with User actions is `FSLUserActionPlugin.h`. 
 
 
 ```c++
@@ -37,8 +37,6 @@ class FSLUserActionPlugin {
   #A primary generator plugin inherits from this.
   virtual G4VUserPrimaryGeneratorAction *getPrimaryGeneratorAction() const {return nullptr;}
 
-
-  
  private:
   
   FSLUserActionPlugin (const FSLUserActionPlugin &)=delete;
@@ -52,7 +50,7 @@ class FSLUserActionPlugin {
 
 ## Sensitive Detectors
 <!---->
-The header file which contains the abstract classes to create plugins with Sensitive detectors is ***FSLSensitiveDetectorPlugin.h***. 
+The header file which contains the abstract classes to create plugins with Sensitive detectors is `FSLSensitiveDetectorPlugin.h`. 
 
 
 ```c++
@@ -123,7 +121,7 @@ inline FSLSensitiveDetectorPlugin::ConstIterator FSLSensitiveDetectorPlugin::end
 
 ## Physics List
 <!---->
-The header file which contains the abstract classes to create plugins with Physics lists is ***FSLPhysicsListPlugin.h***. 
+The header file which contains the abstract classes to create plugins with Physics lists is `FSLPhysicsListPlugin.h`. 
 
 
 ```c++
@@ -151,7 +149,7 @@ public:
 
 ## Magnetic Field
 <!---->
-The header file which contains the abstract classes to create plugins with Magnetic fields is ***MagFieldPlugin.h***. 
+The header file which contains the abstract classes to create plugins with Magnetic fields is `MagFieldPlugin.h`. 
 
 
 ```c++
diff --git a/documentation/docs/fullsimlight/plugins/index.md b/documentation/docs/fullsimlight/plugins/index.md
index aec028e273e3ac3c96ddf6497e901d19d2c80562..a5ba6c985083a058702aefbc29f956bd09b25664 100644
--- a/documentation/docs/fullsimlight/plugins/index.md
+++ b/documentation/docs/fullsimlight/plugins/index.md
@@ -1,29 +1,66 @@
-# Plugins Example
+# Plugins Examples
 
-FullSimLight provides a convenient mechanism for users to extend their simulations through plugins in the form of shared libraries. Plugins can be used to add
+FullSimLight provides a convenient mechanism for users to extend their simulations through plugins in the form of shared libraries. Plugins can be used to add:
 
+- Geometry description
 - User Actions
-- Sensititve Detectors 
-- Magnetic Field Maps
+- Sensitive Detectors 
+- Magnetic Field
 - Physics Lists
 - Event Generators
 
-## Hits Plugin
+For a description of the available example plugins look at the following sections. 
+
+##Geometry plugins
+
+Some geometry example plugins are available at the [GeoModelATLAS](https://gitlab.cern.ch/atlas/geomodelatlas/GeoModelATLAS) repository, under the [Example Plugins](https://gitlab.cern.ch/atlas/geomodelatlas/GeoModelATLAS/-/tree/master/ExamplePlugins) folder. The `ToyGeometryPlugin` and the `AccordionPlugin` are the right examples to start with. 
+
+##User Actions plugins
+
+You can find some example user actions plugins under the FullSimLight/Plugins folder. In particular we provide a DummyUserAction plugin available [here](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/Examples/UserActionPlugins) and a [Hits plugin](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/HitsPlugin) and a [Track plugin](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/TracksPlugin). 
+
+###Hits Plugin
+
+The [Hits plugin](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/HitsPlugin) implements both `G4UserSteppingAction` and `G4UserEventAction`. At each step the particle position (x,y,z coordinates) is saved and at the end of the event the hits are saved into a HDF5 output file. The same file can be in a second step visualized in `gmex`.
+
+###Tracks Plugin
+
+The [Tracks Plugin](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/TracksPlugin) implements `G4UserRunAction`, `G4UserEventAction`, `G4UserSteppingAction`, `G4UserTrackingAction`. For each track at each step the position is recorded and mapped into a map. At the end of the event the information is saved into a HDF5 output file (the default name is Tracks_data.h5). The tracks file data can be in a second step visualized in `gmex`.
+
+##Sensitive Detectors plugins
+
+One sensitive detectors example plugin is provided [here](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/blob/master/FullSimLight/Plugins/Examples/SensitiveDetectorPlugins/SDPlugin/src/SDPlugin.cxx). It's a dummy plugin that serves the purpose of showing how to implement the corresponding FullSimLight abstract interface. 
+
+##Magnetic Field plugins
+
+An example Magnetic field plugin can be found [here](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/Examples/MagneticFieldPlugins/UniformMagneticFieldPlugin). It implements a uniform magnetic field. 
+An ATLAS specific Magnetic Field plugin is also available in the [ATLAS Extensions](https://gitlab.cern.ch/atlas/geomodelatlas/ATLASExtensions) repository. Please refer to the ATLAS Extensions page for further info.
+
+##Physics list plugins
+
+A physics list plugin example is available [here](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/Examples/PhysicsListPlugins/FSLTestPhysListPlugins). It implements a custom physics list that is based on the standard `FTFP_BERT`, adding the `G4OpticalPhysics` process. 
+
+##Event Generators plugins
+
+An Event generator example plugin is available [here](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/tree/master/FullSimLight/Plugins/Examples/EventGeneratorPlugins/FSLExamplePrimaryGeneratorPlugin). 
+It shows how to customize the use of the `G4ParticleGun`and set some properties as the particle type, name, energy, position, polarization, and momentum direction. 
+
+## How to write a plugin: the Hits Plugin example
 
 As a simple example, suppose you as the user want to keep track of the various particles and their positions as the simulation progresses. In particular, if you run the simulation with a certain number of events, then for each event you want to write to a file all the particles and their positions ***"hits"***.
 
-Geant4 provides classes to assist with this task. Namely the G4UserSteppingAction class contains the function
+Geant4 provides classes to assist with this task. Namely the `G4UserSteppingAction` class contains the function:    
 
 ```c++
 virtual void UserSteppingAction (const G4Step *aStep);
 ```
 
-By overriding this function we can get particle positions and names through the G4Step object. Now since we also want to write out our hits to a file for each event, we can use the G4UserEventAction class, which conveniently provides the function
+By overriding this function we can get particle positions and names through the `G4Step` object. Now since we also want to write out our hits to a file for each event, we can use the `G4UserEventAction` class, which conveniently provides the function:
  
 ```c++
 virtual void EndOfEventAction (const G4Event *anEvent);
 ```
-which is called at the end of every event. We can also access the event ID through the G4Event object. Before proceding let us setup our project. Navigating to the directory of choice we can run on the terminal
+which is called at the end of every event. We can also access the event ID through the `G4Event` object. Before proceeding let us set up our project. Navigating to the directory of choice we can run on the terminal
  
 ```bash
 mkdir HitsPlugin
@@ -34,7 +71,7 @@ mkdir src
 cd src
 touch HitsPlugin.cxx
 ```
-This creates the directory structure
+This creates the directory structure:
 
 ```bash
  HitsPlugin
@@ -44,7 +81,7 @@ This creates the directory structure
        └── HitsPlugin.cxx    
 ```
 
-Opening up the CMakeLists.txt file, we call our project GenerateHitsPlugin and configure the file as follows
+Opening up the CMakeLists.txt file, we call our project GenerateHitsPlugin and configure the file as follows:
 
 ```cmake
 # Set up the project.
@@ -71,7 +108,7 @@ target_link_libraries ( GenerateHitsPlugin PUBLIC FullSimLight ${Geant4_LIBRARIE
 target_include_directories( GenerateHitsPlugin PUBLIC ${FullSimLight_INCLUDE_DIR})
 ```
 
-Now we are ready to write our implementation of recording hits in HitsPlugin.cxx. This will require three classes and one additional function at the end of the file.
+Now we are ready to write our implementation of recording hits in `HitsPlugin.cxx`. This will require three classes and one additional function at the end of the file.
 
 ```c++
 class GenerateHitsStep;
@@ -80,13 +117,13 @@ class GenerateHitsPlugin;
 extern "C" GenerateHitsPlugin * createGenerateHitsPlugin();
 ```
 
-- The first two classes GenerateHitsStep & GenerateHitsEvent will inherit from G4UserSteppingAction and G4UserEventAction respectively, since these contains the methods that are relevant for our purpose as discussed earlier. In general you will need one class for every type of User Action you decide to use.
+- The first two classes `GenerateHitsStep` & `GenerateHitsEvent` will inherit from `G4UserSteppingAction` and `G4UserEventAction` respectively, since these contain the methods that are relevant for our purpose as discussed earlier. In general you will need one class for every type of User Action you decide to use.
 
-- The final class GenerateHitsPlugin is neccesary for defining the plugin and ***must have the same name as the name specified within the add_library command in the CMakeLists.txt file.*** This class will inherit from the FSLUserActionPlugin class, which is the abstract class provided by FullSimLight to allow it to interface with our custom defined User Actions. This class must always be defined.
+- The final class `GenerateHitsPlugin` is neccesary for defining the plugin and ***must have the same name as the name specified within the add_library command in the CMakeLists.txt file.*** This class will inherit from the `FSLUserActionPlugin` class, which is the abstract class provided by FullSimLight to allow it to interface with our custom defined User Actions. This class must always be defined.
 
-- Finally the function createGenerateHitsPlugin is neccesary for properly loading in the plugin to FullSimLight and ***must always have the name create + name of plugin class.*** This function must always be defined.
+- Finally the function `createGenerateHitsPlugin` is neccesary for properly loading in the plugin to FullSimLight and ***must always have the name create + name of plugin class.*** This function must always be defined.
 
-Now that we have an outline of what we need to do. Let's first include all the relevant header files based on the above discussion
+Now that we have an outline of what we need to do, let's include all the relevant header files based on the above discussion.
 
 ```c++
 #include <iostream>
@@ -98,7 +135,7 @@ Now that we have an outline of what we need to do. Let's first include all the r
 #include "G4Step.hh"
 #include <G4Event.hh>
 ```
-Next lets define a Hit struct which provides a convenient way of storing a particles position and ID
+Next let's define a `Hit` struct which provides a convenient way of storing a particle position and ID
 
 ```c++
 struct Hit{
@@ -108,7 +145,7 @@ struct Hit{
   unsigned int  id;
 };
 ```
-Let us also create a map which associates various particles with an ID. This is useful as we can access particle names through the G4Step object and then associate those names with IDs for more efficient storage.
+Let us also create a map which associates various particles with an ID. This is useful as we can access particle names through the `G4Step` object and then associate those names with IDs for more efficient storage.
 
 ```c++
 //Not a comprehensive list of all particles
@@ -116,7 +153,7 @@ std::map<G4String, unsigned int> particle_ids { {"gamma", 1},
 {"e-", 2}, {"e+", 2}, {"mu-", 3}, {"mu+", 3}, };
 ```
 
-We can now define our first class GenerateHitsStep which will inherit from G4UserSteppingAction and will record hits for us.
+We can now define our first class `GenerateHitsStep` which will inherit from `G4UserSteppingAction` and will record hits for us.
 
 ```c++
 class GenerateHitsStep:
@@ -175,7 +212,7 @@ void GenerateHitsStep::UserSteppingAction(const G4Step* step){
 }
 
 ```
-Next we define GenerateHitsEvent class which will inherit from G4UserEventAction and will write hits to a file at the end of every event.
+Next we define `GenerateHitsEvent` class which will inherit from `G4UserEventAction` and will write hits to a file at the end of every event.
 
 ```c++
 class GenerateHitsEvent:
@@ -233,7 +270,7 @@ void GenerateHitsEvent::EndOfEventAction(const G4Event* evt)
 
 ```
 
-Now we need to define the GenerateHitsPlugin class which will provide the interface with FullSimLight. This class will inherit from FSLUserActionPlugin class and override methods depending upon the User Actions used.
+Now we need to define the `GenerateHitsPlugin` class which will provide the interface with FullSimLight. This class will inherit from `FSLUserActionPlugin` class and override methods depending upon the User Actions used.
 
 ```c++
 class GenerateHitsPlugin:public FSLUserActionPlugin {
@@ -275,7 +312,7 @@ G4UserEventAction *GenerateHitsPlugin::getEventAction() const {
 }
 ```
 
-Finally we need to define the function createGenerateHitsPlugin() which will return a new instance of our plugin class.
+Finally we need to define the function `createGenerateHitsPlugin()` which will return a new instance of our plugin class.
 
 
 ```c++
@@ -286,21 +323,21 @@ extern "C" GenerateHitsPlugin *createGenerateHitsPlugin() {
 
 ```
 
-With the implmentation completed, we can now move into the build folder and run.
+With the implementation completed, we can now move into the build folder and run.
 
 ```bash
 cmake ..
 make
 ```
 
-In the build folder you will see
+In the build folder you will see:
 
 ```bash
 libGenerateHitsPlugin.dylib (Mac)
 libGenerateHitsPlugin.so (Linux)
 ```
 
-Our plugin is ready to use! We can now open up fsl by running the fsl command and can add our plugin in the User Actions tab as shown below
+Our plugin is ready to use! We can now open up `fsl` by running the `fsl` command and can add our plugin in the User Actions tab as shown below:
 
 {{ imgutils_image_caption('plugin.png', 
    alt='fsl',