docs: language and markdown brush-over (#2642)

- Fix numerous typos
- Improve grammar
- Fix markdown tables and numbering (should not be visible)
- Standardise upper/lower-case of ACTS:
    - `Acts` for the namespace
    - ACTS everywhere else

docs/acts_project.md

@@ -1,11 +1,11 @@
 # The ACTS project
 
-The *A Common Tracking Software (Acts)* project is an attempt to preserve and evolve the track reconstruction software of the LHC era towards HL-LHC and beyond. It has been initiated in 2016 starting from the [ATLAS Common Tracking Software](https://gitlab.cern.ch/atlas/athena/-/tree/master/Tracking). Given the changing computing landscape, dedicated care of parallel code execution is taken, and is written in `C++17`. 
+The *A Common Tracking Software (ACTS)* project is an attempt to preserve and evolve the track reconstruction software of the LHC era towards HL-LHC and beyond. It has been initiated in 2016 starting from the [ATLAS Common Tracking Software](https://gitlab.cern.ch/atlas/athena/-/tree/master/Tracking). Given the changing computing landscape, dedicated care of parallel code execution is taken, and is written in `C++17`.
 
 A [coherent write-up of the project](https://link.springer.com/article/10.1007/s41781-021-00078-8) has been published in 2022 in Springer's CSBS.
 
 ```{note}
-Acts is designed as a library that *contains components* for assembling a track reconstruction suite for High Energy Physics and Nuclear Physics. Acts does not strive to provide a complete experiment framework, but rather modules and connections to be used within an experiment context. These connections contain e.g. binding mechanisms to different geometry libraries, a cost-free yet flexible mechanism to use experiment specific contextual data (calibrations, detector alignment, experiment conditions), or simply the possibility to integrate an external screen logging facility.
+ACTS is designed as a library that *contains components* for assembling a track reconstruction suite for High Energy Physics and Nuclear Physics. ACTS does not strive to provide a complete experiment framework, but rather modules and connections to be used within an experiment context. These connections contain e.g. binding mechanisms to different geometry libraries, a cost-free yet flexible mechanism to use experiment specific contextual data (calibrations, detector alignment, experiment conditions), or simply the possibility to integrate an external screen logging facility.
 ```
 
 The library is structured as follows:
@@ -17,20 +17,20 @@ The library is structured as follows:
 
 
 ```{tip}
-Developers and R&D meetings can be found in the [Acts indico category](https://indico.cern.ch/category/7968/).
+Developers and R&D meetings can be found in the [ACTS indico category](https://indico.cern.ch/category/7968/).
 ```
 
  ## Philosophy
 
- In order to minimize virtual function calls and complex inheritance schemes, Acts does - in general - not define module interfaces, but rather relies on a data-centric pattern. Wherever possible, composition is favoured over inheritance/code extension.
+ In order to minimize virtual function calls and complex inheritance schemes, ACTS does - in general - not define module interfaces, but rather relies on a data-centric pattern. Wherever possible, composition is favoured over inheritance/code extension.
 
- Code execution performance is a big focus in Acts in order to serve the needs of the HL-LHC experiments; however, this is attempted to be reached mainly by technical means rather than compromising the physics performance.
+ Code execution performance is a big focus in ACTS in order to serve the needs of the HL-LHC experiments; however, this is attempted to be reached mainly by technical means rather than compromising the physics performance.
 
  ## R&D Testbed
 
- Acts should also provide a testbed for fruitful algorithm R&D, and hence is closely coupled to the development of the [Open Data Detector](https://gitlab.cern.ch/acts/OpenDataDetector) which can be built as a `thirdparty` dependency as part of the Acts project, and builds the backbone of the chain demonstrators.
+ACTS should also provide a testbed for fruitful algorithm R&D, and hence is closely coupled to the development of the [Open Data Detector](https://gitlab.cern.ch/acts/OpenDataDetector) which can be built as a `thirdparty` dependency as part of the ACTS project, and builds the backbone of the chain demonstrators.
 
 In addition, two dedicated R&D lines are part of the `acts-project`, one for machine learning based/inspired modules [acts-machine-learning](mailto:acts-machine-learning@cern.ch), and one for massively parallel code execution [acts-parallelization](mailto:acts-parallelization@cern.ch), which mainly focuses on GPU accelerators and portability.
 
-Code spill-over from the R&D lines into the main Acts repository are performed on demand and depending on the maturity of the R&D projects.
+Code spill-over from the R&D lines into the main ACTS repository are performed on demand and depending on the maturity of the R&D projects.
 

docs/authors.rst

@@ -8,7 +8,7 @@ Detailed contributor information can also be found on the projects `Github contr
 Contributors to the ATLAS tracking software
 -------------------------------------------
 
-The Acts project was initially based on the ATLAS tracking software.
+The ACTS project was initially based on the ATLAS tracking software.
 The development team is grateful for the work done by the following people on the ATLAS tracking software.
 
 Alejandro Alonso Diaz, Adam Edward Barton, Andy Buckley, Anthony Morley, Aaron James Armbruster, Olivier Arnaez, John Baines, Sebastien Binet, Bruno Lenzi, Veronique Boisvert, Guennadi Borissov, Eva Bouhova-Thacker, Antonio Boveia, Christian Gumpert, Christian Schmitt, Camilla Maiani, Andrea Coccaro, Christian Ohm, Christoph Rauchegger, Christoph Wasicki, Daniel Ryan Blackburn, Dave Casper, David Divalentino, Dmitry Emeliyanov, Daniel Hay Guest, Daniel Kollar, David Lopez Mateos, Daniel Mori, David Quarrie, David Rousseau, David Richard Shope, Till Eifert, Esben Lund, Edward Moyse, Frederic Brochu, Sebastian Fleischmann, Fred Luehring, Felix Socher, Igor Gavrilenko, Gerhard Immanue Brandt, Graham John Cree, Peter Van Gemmeren, Giacinto Piacquadio, Goetz Gaycken, Steven Goldfarb, Grant Gorfine, Carl Bryan Gwilliam, Heberth Jesus Torres Davila, Loek Hooft Van Huysduynen, Haichen Wang, Ioannis Nomidis, Ilija Vukotic, Jahred Adelman, Javier Jimenez Pena, Johanna Bronner, James Catmore, John Derek Chapman, Jason Lee, Jeremy Robert Love, John Alison, Jochen Meyer, Juergen Thomas, Jochem Snuverink, Jeffrey Tseng, Jike Wang, Konstantinos Karakostas, Kathryn Grimm, Peter Kluit, Thomas Koffas, Nikolaos Konstantinidis, Attila Krasznahorkay, Vicente Lacuesta Miquel, Remi Lafaye, Antonio Limosani, Markus Elsing, Salvador Marti I Garcia, Jiri Masik, Massimiliano Bellomo, Matthias Danninger, Miriam Deborah Diamond, Joerg Mechnich, Maria Jose Costa Mezquita, Maaike Limper, Manuel Neumann, Marcin Nowak, Matthew Scott Rudolph, Maximiliano Sioli, Michael Ughetto, Noemi Calace, Nectarios Benekos, Niels Van Eldik, Nir Amram, Nathan Rogers Bernard, Nicholas Styles, Konstantinos Ntekas, Emil Obreshkov, Susumu Oda, Gustavo Ordonez Sanz, Ourania Sidiropoulou, Petr Balek, Pawel Bruckman De Renstrom, Pierfrancesco Butti, Troels Petersen, Kirill Prokofiev, Alan Poppleton, Rachel Reisner Hinman, Elmar Ritsch, Roland Jansky, Markus Jungst, Robert Johannes Langenberg, Robert Harrington, Ruslan Mashinistov, Andreas Salzburger, Sebastian Boeser, R D Schaffer, Shih-Chieh Hsu, Sabine Elles, Rolf Seuster, Silvia Miglioranzi, Stewart Martin-Haugh, Song-Ming Wang, Simone Pagan Griso, Shaun Roe, Savanna Marie Shaw, Scott Snyder, Stefania Spagnolo, Thijs Cornelissen, Tommaso Lari, Tatjana Lenz, Sarka Todorova, Vakhtang Tsulaia, Vato Kartvelishvili, Veerle Heijne, Vadim Kostyukhin, Weimin Song, Andreas Wildauer, Walter Lampl, William Axel Leight, Wolfgang Liebig, Wolfgang Lukas, Marcin Wolter

docs/codeguide.md

@@ -6,7 +6,7 @@ All guidelines have a short identifier label, e.g. N.1, for easier reference in
 
 For cases and constructs not explicitly mentioned here, code should fall back to the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines).
 
-## Acts-specific
+## ACTS-specific
 
 ### A.indices: Always use enum values to access vector/matrix components
 

docs/contribution/documentation_cheatsheet.md

@@ -65,12 +65,12 @@ members: center
 :::
 
 (cheatsheetlabels)=
-## Cross referencing and labels
+## Cross-referencing and labels
 
 * Setting a label (should be in front of a heading or something like that):
 
 ```text
-## Cross referencing and labels
+## Cross-referencing and labels
 (cheatsheetlabels)=
 ```
 

docs/contribution/physmon.md

@@ -4,7 +4,7 @@ The ACTS CI runs a suite of physics performance monitoring jobs dubbed
 *physmon*. The purpose is to monitor and detect changes in the physics
 performance, both intentional and accidental.
 
-The associated job will run a number of workflow combinations. Currently this
+The associated job will run a number of workflow combinations. Currently, this
 includes the truth tracking and OpenDataDetector *full chain* workflows. The
 latter is further split into configurations with full seeding, truth smeared or
 truth estimated seeds. These jobs produce performance output files.

docs/contribution/profiling.md

@@ -53,7 +53,7 @@ $ go install github.com/google/pprof@latest
 
 ## Link gperftools Libraries When Compiling
 
-The library needed to run the CPU profilier should be linked into the ACTS project using the following build option:
+The library needed to run the CPU profiler should be linked into the ACTS project using the following build option:
 
 ```
 -DACTS_ENABLE_CPU_PROFILING=ON
@@ -67,7 +67,7 @@ Similarly, to enable the memory profiler the following build option should be us
 
 ## Alternative to Recompiling
 
-Alternatively, you can avoid rebuiding the project by pointing the `LD_PRELOAD` environment variable to the profiler library for CPU profiling:
+Alternatively, you can avoid rebuilding the project by pointing the `LD_PRELOAD` environment variable to the profiler library for CPU profiling:
 
 ```
 LD_PRELOAD="<path/to/libprofiler.so>" <other_options> <path/to/binary> <binary_flags>

docs/core/core.rst

@@ -1,7 +1,7 @@
 Core library
 ============
 
-The Acts core functionality is grouped into modules, where each module contains
+The ACTS core functionality is grouped into modules, where each module contains
 tools related to one particular subject, i.e. experiment geometry or vertexing.
 
 .. toctree::

docs/core/geometry/geometry_id.md

@@ -7,7 +7,7 @@ building, e.g. for the uploading/assigning of material to the surface after
 creation. The {class}`Acts::GeometryIdentifier` uses a simple masking procedure for applying an
 identification schema.
 
-While it is used in Acts-internal applications such as material mapping, it is not employed for
+While it is used in ACTS-internal applications such as material mapping, it is not employed for
 `EventData` and `Geometry` identification in an experiment setup. Instead, one should define and use the
 `Identifier` class in the latter case.
 

docs/core/geometry/layerless/layerless.md

@@ -37,7 +37,7 @@ While objects may be stored as `std::shared_ptr<T>` internally, their access dur
 
 ### Navigation state and delegates
 
-A struct {struct}`Acts::Experimental::NavigationState` holds the current navigation information through the geometry, which comprises of
+A struct {struct}`Acts::Experimental::NavigationState` holds the current navigation information through the geometry, which comprises
 
 - the current {class}`Acts::Experimental::DetectorVolume` in associated with the position within the detector, called `currentVolume`
 - a list of portal candidates to leave the `currentVolume`
@@ -70,7 +70,7 @@ Illustration of a shared direct portal between two volumes, the arrows indicate
 Illustration of a shared extended portal between several volumes, the arrows indicate the direction of attachment.
 :::
 
-The implementation of a unique, binned or any other volume link can be adapted to the detector geometry by providing a suitablen `Acts::Experimental::DetectorVolumeUpdator` delegate.
+The implementation of a unique, binned or any other volume link can be adapted to the detector geometry by providing a suitable `Acts::Experimental::DetectorVolumeUpdator` delegate.
 
 ### The Detector volume object
 
@@ -95,7 +95,7 @@ In case the volume contains surfaces and/or volumes, an adequate navigation stat
 :::{figure} ../figures/EndcapGrid.png
 :width: 600px
 :align: center
-Illustration of a planar module andcap detector with a grid holding the indices to the candidate surfaces.
+Illustration of a planar module endcap detector with a grid holding the indices to the candidate surfaces.
 :::
 
 :::{note}
@@ -108,7 +108,7 @@ The detector object is the holder class of all geometry objects, it has to conta
 
 - at least one detector volume
 - a name string
-- a volume finder delegate (as `Acts::Experimental::DetecorVolumeFinder`) that allows to uniquely associate a point in space with a contained volume of the detector.
+- a volume finder delegate (as `Acts::Experimental::DetectorVolumeFinder`) that allows to uniquely associate a point in space with a contained volume of the detector.
 
 :::{note}
 When the detector is constructed, name duplicates are checked for and if found a `std::exception` is thrown. Similarly, when sensitive surfaces are provided and duplicate `Acts::GeometryIdentifier` objects are found during detector construction a `std::exception` is thrown. The latter can be avoided by using an appropriate (set of) `Acts::GeometyIdGenerator` tool(s) which will guarantee some level of uniqueness.

docs/core/geometry/legacy/building.md

@@ -35,9 +35,9 @@ binding for the ATLAS experiment.
 
 ```{note}
 While `DD4hep` offers a descriptive language with a dedicated extension mechanism
-that can be used by Acts to interpret the underlying geometry hierarchy and and structure,
+that can be used by ACTS to interpret the underlying geometry hierarchy and and structure,
 there is no such guarantee when having the already as built `TGeo` geometry in hand.
-Therefore a dedicated Acts configuration file based on `json` can be provided that allows
+Therefore a dedicated ACTS configuration file based on `json` can be provided that allows
 to specify parsing restrictions for sub detectors. 
 ```
 

docs/core/geometry/surfaces.md

@@ -17,14 +17,14 @@ Each {class}`Acts::Surface` instance reports its type from {func}`Acts::Surface:
 :::
 
 
-| Surface Type          | Local Coordinates | Bound Types available                                                                       |
-|:----------------------|-------------------|:--------------------------------------------------------------------------------------------|
-| {class}`Acts::ConeSurface`         | $[r\phi, z]$         | {class}`Acts::ConeBounds`                                                                                |
-| {class}`Acts::CylinderSurface`     | $[r, \phi]$         | {class}`Acts::CylinderBounds`                                                                            |
-| {class}`Acts::DiscSurface`         | $[r, \phi]$         | {class}`Acts::RadialBounds`, {class}`Acts::DiscTrapezoidBounds`                                                     |
-| {class}`Acts::PlaneSurface`        | $[x, y]$         | {class}`Acts::RectangleBounds`, {class}`Acts::TrapezoidBounds`, <br>{class}`Acts::InfiniteBounds`, {class}`Acts::EllipseBounds` |
-| {class}`Acts::PerigeeSurface`,<br> {class}`Acts::StrawSurface` | $[d, z]$ | {class}`Acts::CylinderBounds`                                                                            |
-| {class}`Acts::LineSurface` | $[d_0, z_0]$ | {class}`Acts::LineBounds` |
+| Surface Type                                                   | Local Coordinates | Bound Types available                                                                                                           |
+|:---------------------------------------------------------------|-------------------|:--------------------------------------------------------------------------------------------------------------------------------|
+| {class}`Acts::ConeSurface`                                     | $[r\phi, z]$      | {class}`Acts::ConeBounds`                                                                                                       |
+| {class}`Acts::CylinderSurface`                                 | $[r, \phi]$       | {class}`Acts::CylinderBounds`                                                                                                   |
+| {class}`Acts::DiscSurface`                                     | $[r, \phi]$       | {class}`Acts::RadialBounds`, {class}`Acts::DiscTrapezoidBounds`                                                                 |
+| {class}`Acts::PlaneSurface`                                    | $[x, y]$          | {class}`Acts::RectangleBounds`, {class}`Acts::TrapezoidBounds`, <br>{class}`Acts::InfiniteBounds`, {class}`Acts::EllipseBounds` |
+| {class}`Acts::PerigeeSurface`,<br> {class}`Acts::StrawSurface` | $[d, z]$          | {class}`Acts::CylinderBounds`                                                                                                   |
+| {class}`Acts::LineSurface`                                     | $[d_0, z_0]$      | {class}`Acts::LineBounds`                                                                                                       |
 
 ```{tip}
 In an ideal setup, the coordinate systems also define the readout

docs/core/magnetic_field.md

@@ -100,7 +100,7 @@ which is returned unmodified to every call to
 For more complex magnetic field implementations
 {class}`Acts::InterpolatedMagneticField` can be used. The idea here is to calculate
 an interpolated value of the magnetic field from a grid of known field values.
-In 3D, this means the interpolation is done from the 8 cornerpoints of a *field
+In 3D, this means the interpolation is done from the 8 corner points of a *field
 cell*. The field cell can be retrieved for any given position. Since during
 typical access patterns, e.g. the propagation, subsequent steps are relatively
 likely to not cross the field cell boundary, the field cell can be cached.

docs/core/misc/grid_axis.md

@@ -42,7 +42,8 @@ There are three options:
 
 ## Grid creation
 
-The types of the axes have to be known at compile-time, since they are provided to the `Grid` as template parameters. Thus the number of dimensions $N$ of the `Grid` is also fixed at compile-time.
+The types of the axes have to be known at compile-time, since they are provided to the `Grid` as template parameters.
+Thus, the number of dimensions $N$ of the `Grid` is also fixed at compile-time.
 The axes can be any combination of the aforementioned variations.
 
 ```cpp
@@ -71,18 +72,18 @@ The local bin indices are always defined from 1 to $N_\text{bins}$ for the respe
 The `Grid` can determine the number of neighbors around a given bin. This done by first converting the global bin index to local bin indices, and then varying the local bin indices in each dimension. At this stage, each Axis gets to decide, which indices are considered neighbors, which differs depending on `AxisBinningType`. `Open` considers the underflow and overflow bins, while `Bound` does not. `Closed` considers bins on the other side of the axis.
 The resulting neighbor combination around bin *B* might look like
 
-b x b | 1    | 2    | 3    |
-------|------|------|------|
-1     | x    | 0,+1 | x    |
-2     | -1,0 |  B   | +1,0 |
-3     | x    | 0,-1 | x    |
+| b x b | 1     | 2    | 3     |
+|-------|-------|------|-------|
+| 1     | x     | 0,+1 | x     |
+| 2     | -1, 0 | B    | +1, 0 |
+| 3     | x     | 0,-1 | x     |
 
 Here, the corner combinations are still missing (also true for $N>2$). This is then turned into a hypercube which in $N=2$ results in:
 
-b x b | 1     | 2    | 3     |
-------|-------|------|-------|
-1     | -1,+1 | 0,+1 | +1,+1 |
-2     | -1,0  |  B   | +1,0  |
-3     | -1,-1 | 0,-1 | +1,-1 |
+| b x b | 1     | 2    | 3     |
+|-------|-------|------|-------|
+| 1     | -1,+1 | 0,+1 | +1,+1 |
+| 2     | -1, 0 | B    | +1, 0 |
+| 3     | -1,-1 | 0,-1 | +1,-1 |
 
 These local bin indices are then converted into global bin indices before being returned.