Manual: fix cross-references

---

Different types of detector models are available and distributed together with the framework: these models use the

configuration format introduced in [Section 4.3](./03_configuration.md#file-format) and can be found in the `models`

configuration format introduced in [Section 4.3](../04_framework/03_configuration.md#file-format) and can be found in the `models`

directory of the repository. Every model extends from the `DetectorModel` base class, which defines the minimum required

parameters of a detector model within the framework. The coordinates place the detector in the global coordinate system, with

the reference point taken as the geometric center of the active matrix. This is defined by the number of pixels in the sensor

Models are defined in configuration files which are used to instantiate the actual model classes; these files contain various

types of parameters, some of which are required for all models while others are optional or only supported by certain model

types. For more details on how to add and use a new detector model, [Section 9.5](../09_development/05_new_detector_model.md)

types. For more details on how to add and use a new detector model, [Section 10.5](../10_development/05_new_detector_model.md)

should be consulted.

The set of base parameters supported by every model is provided below. These parameters should be given at the top of the

- `material`:

  Material of the support. Allpix Squared does not provide a set of materials to choose from; it is up to the modules using

  this parameter to implement the materials such that they can use it. [Chapter 7](../07_modules/_index.md) provides

  this parameter to implement the materials such that they can use it. [Chapter 8](../08_modules/_index.md) provides

  details about the materials supported by the geometry builder modules (for example in the

  [`GeometryBuilderGeant4 module documenation`](../07_modules/geometrybuildergeant4.md)).

  [`GeometryBuilderGeant4 module documentation`](../08_modules/geometrybuildergeant4.md)).

## Accessing specific detector models within the framework

module, and is always interpreted as 1-MeV neutron equivalent fluence \[[@niel]\].

The decision on whether a charge carrier has been trapped during a step during the propagation process is calculated

similarly to the recombination processes, described in [Section 5.3](./03_lifetime_recombination.md).

similarly to the recombination processes, described in [Section 6.3](./03_lifetime_recombination.md).

It should be noted that the trapping of charge carriers is only one of several effects induced by radiation damage. In Allpix

Squared, these effects are treated independently, i.e. defining the fluence for a propagation module will not affect any

MCParticles provide local and global coordinates in space for both the entry and the exit of the particle in the sensor

volume, as well as local and global time information. The global spatial coordinates are calculated with respect to the

global reference frame defined in [Section 4.5](../04_framework/05_geometry_detectors.md#coordinate-systems), the global time

global reference frame defined in [Section 5.1](../05_geometry_detectors/01_geometry.md#coordinate-systems), the global time

is counted from the beginning of the event. Local spatial coordinates are determined by the respective detector, the local

time measurement references the entry point of the *first* MCParticle of the event into the detector.

- The pointer asterisk should be left-aligned, i.e. `int* foo` instead of `int *foo`.

The continuous integration automatically checks if the code adheres to the defined format as described in

[Section 10.3](../10_devtools/03_ci.md).

[Section 11.3](../11_devtools/03_ci.md).

- The framework documentation in [Chapter 4](../04_framework/_index.md) for an introduction to the different components of

  the framework.

- The module documentation in [Chapter 7](../07_modules/_index.md) for a description of the functionality of other modules

- The module documentation in [Chapter 8](../08_modules/_index.md) for a description of the functionality of other modules

  already implemented, and to look for similar modules which can help during development.

- The Doxygen (core) reference documentation included in the framework \[[@ap2-doxygen]\].

```

General guidelines and instructions for implementing new modules are provided in

[Section 9.3](../09_development/03_new_module.md).

[Section 10.3](../10_development/03_new_module.md).

### `CMakeLists.txt`

4.  Possible lines to include additional directories and to link libraries for dependencies loaded earlier.

5.  A line with `ALLPIX_MODULE_REQUIRE_GEANT4_INTERFACE(${MODULE_NAME})` adds the Geant4 interface library as explained in

    [Section 13.1](../13_additional/01_tools.md#geant4-interface).

    [Section 14.1](../14_additional/01_tools.md#geant4-interface).

6.  A line to register the directory with module tests, for example `tests` as in

    `{ALLPIX_MODULE_TESTS(${MODULE_NAME} "tests")`.

### `README.md`

The `README.md` serves as the documentation for the module and should be written in GitLab Flavored Markdown (GLFM)

\[[@markdown]\]. It is automatically included in the user manual in [Chapter 7](../07_modules/_index.md).

\[[@markdown]\]. It is automatically included in the user manual in [Chapter 8](../08_modules/_index.md).

The `README.md` should follow the structure indicated in the `README.md` file of the `DummyModule` in `src/modules/Dummy`,

and should contain at least the following sections: