[pre-commit.ci] pre-commit autoupdate

.pre-commit-config.yaml

@@ -1,18 +1,18 @@
 repos:
 -   repo: https://github.com/klieret/jekyll-relative-url-check
-    rev: v2.0.1
+    rev: v2.0.2
     hooks:
     -   id: jekyll-relative-url-check-html
     -   id: jekyll-relative-url-check-markdown
 -   repo: https://github.com/codespell-project/codespell
-    rev: 'v2.2.5'
+    rev: 'v2.2.6'
     hooks:
     -   id: codespell
         args: ["-I", "codespell.txt"]
         types_or: ["markdown"]
         exclude: '(organization/_posts/2016/.*)|(organization/_posts/2017/.*)|(organization/_posts/2018/.*)|(organization/_posts/2019/.*)|(organization/_posts/2020/.*)|(organization/_posts/2021/.*)|(organization/_posts/2022/.*)'
 -   repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.4.0
+    rev: v4.5.0
     hooks:
     -   id: check-json
     -   id: check-yaml

_gsdocs-blogs/2020/blog_ROOT_JohannesHentrich.md

@@ -26,7 +26,7 @@ Older content has been reviewed for accuracy and revised or removed as necessary
 
 The [ROOT Forum](https://root-forum.cern.ch/) is the central place for questions about ROOT. Statistics have been compiled and evaluated to identify the most common problems of users with ROOT. Numerous answers to the questions were incorporated into the ROOT Manual. Care was taken to ensure that the relevant content can be found easily.
 
-## Developping how-tos
+## Developing how-tos
 
 How-to’s were included in the ROOT documentation, also based on the evaluated statistics from the [ROOT Forum](https://root-forum.cern.ch/). Furthermore, older sources were examined to determine which content should be included in the ROOT Manual. The number of code examples has been increased to handle typical tasks faster.
 

_gsdocs-blogs/2020/blog_ROOT_JohnYoon.md

@@ -34,7 +34,7 @@ In summary, I would create:
 # Development
 After establishing the success criteria for the project, I began to deep dive into the source code and review any existing documentation. Then I began to create the tutorial using the language, C++. The first major milestone was getting RNTuple to properly work with the climate data. The next stage consisted of taking the inputted data and filtering it to a more granular level so that the tutorial could use the data in combination with another ROOT feature, RDataFrame. Once this part was completed, we focused on outputting the results as visualizations. Afterwards, there were several iterations of adding and improving the comments within the code.
 
-Once the tutorial was complete, I shifted gears towards creating the eference specification document for RNTuple. This comprised of establishing and defining the key terms that is used in the understanding RNTuple, as well as translating the C-based implementation of RNTuple into a universally accessible guide that would allow developers to implement their own take on RNTuple, i.e. into other programming languages like Python.
+Once the tutorial was complete, I shifted gears towards creating the reference specification document for RNTuple. This comprised of establishing and defining the key terms that is used in the understanding RNTuple, as well as translating the C-based implementation of RNTuple into a universally accessible guide that would allow developers to implement their own take on RNTuple, i.e. into other programming languages like Python.
 
 # Challenges
 Most of the challenges relating to the completion of either goals derived from the fact that the parts of ROOT that I was contributing towards consisted mainly of its experimental version, ROOT 7. Consequently, it was difficult at times, such as during troubleshooting, to determine if the code was crashing due to a bug implemented on my part, or if it was due to the inherently experimental nature of the feature. Similarly, there were compatibility issues that arose between the experimental ROOT 7 version, and the currently accepted version. Fortunately, in both situations, my mentor, the I/O team, and the broader ROOT community was always there to offer insights and suggestions.

_gsocblogs/2022/blog_Geant4_PriyamMehta.md

@@ -385,7 +385,7 @@ For detailed read on ONNXRuntime Quantization, refer https://onnxruntime.ai/docs
 - `activation_type` - Which `INT8` quantization to perform on activations. Supported [`int8`, `uint8`]. Preferred, `int8` as it is more versatile and works on a wide array of models.
 - `weight_type` - Which `INT8` quantization to perform on model weights. Supported [`int8`, `uint8`]. Preferred, `int8` as it is more versatile and works on a wide array of models.
 - `nodes_to_quantize` - List of nodes to quantize. Specify exact node names of the .onnx model. Only the nodes present in the list will be quantized. If empty, all nodes will be quanized.
-- `nodes_to_exclude` - List of nodes to exclude. Specify exact node names of the .onnx model. Only the nodes present in the list will be exclued. If empty, no nodes will be excluded.
+- `nodes_to_exclude` - List of nodes to exclude. Specify exact node names of the .onnx model. Only the nodes present in the list will be excluded. If empty, no nodes will be excluded.
 - `use_external_data_format` -  Saving models > 2GB creates problems in ONNXRuntime. It is preferred to set this option to `True` if dealing with models > 2GB.
 - `extra_options` - Refer [onnxruntime/quantization/quantize.py](https://github.com/microsoft/onnxruntime/blob/main/onnxruntime/python/tools/quantization/quantize.py#L113)
 - `for_tensorrt` - If this optimization is for tensorrt or not. If set to `True`, only the calibration table will be created. TensorRT performs it own graph optimization and quantization. Hence, TensorRT optimization can only be performed dynamically in ONNXRuntime. The path of calibration table generated can be given as input to ONNXRuntime Session, TensorRT will use this Calibration cache to optimize the model at runtime.

_gsocblogs/2022/blog_PODIO_SoumilBaldota.md

@@ -54,9 +54,9 @@ Following the addition of the attributes necessary for building the includes req
 The equivalent of C++ classes in Julia are the Mutable Structs, these help by providing structure to our data and allow us to set the type of the data after construction  which allows us to use our dataypes, by calling our Constructor. These constructors are named after the types themselves in our case, in order to abstract information from the users regarding the existence of Mutable Structs which are not interacted with, by the users.
 When two mutually dependent Mutable Structs are passed their Julia Types using Constructors, A Mutually Recursive/Inclusive Type Declaration occurs. This can be solved easily using forward declarations in C++ but it requires the use of either Parametric types or Abstract Types in Julia ([long standing issue](https://github.com/JuliaLang/julia/issues/269)).
 
-For the purpose of code generation and a cleaner approach we chose to use the parameteric method. This required the list of parameters needed by each Constructor. This data is processed by the [**get_julia_params**](https://github.com/AIDASoft/podio/blob/59fe1e740ca0a7dbff1180c1425047ed1ab3e027/python/podio_class_generator.py#L286-L293)
+For the purpose of code generation and a cleaner approach we chose to use the parametric method. This required the list of parameters needed by each Constructor. This data is processed by the [**get_julia_params**](https://github.com/AIDASoft/podio/blob/59fe1e740ca0a7dbff1180c1425047ed1ab3e027/python/podio_class_generator.py#L286-L293)
 
-The Parameteric Types are used by the [Datatypes](https://github.com/AIDASoft/podio/blob/a8efda986f776892e90e7aafa4958aaf18a1e6c7/doc/templates.md?plain=1#L84), which have one to one and one to many relations and are not used by the [Components](https://github.com/AIDASoft/podio/blob/a8efda986f776892e90e7aafa4958aaf18a1e6c7/doc/templates.md?plain=1#L75) as they do not have any Cyclic Relations that could cause an infinite inclusion loop, Similarly Types with pure Vector Members also do not need a Parameteric Type.
+The Parametric Types are used by the [Datatypes](https://github.com/AIDASoft/podio/blob/a8efda986f776892e90e7aafa4958aaf18a1e6c7/doc/templates.md?plain=1#L84), which have one to one and one to many relations and are not used by the [Components](https://github.com/AIDASoft/podio/blob/a8efda986f776892e90e7aafa4958aaf18a1e6c7/doc/templates.md?plain=1#L75) as they do not have any Cyclic Relations that could cause an infinite inclusion loop, Similarly Types with pure Vector Members also do not need a Parametric Type.
 
 The Datatypes described by the yaml input are allowed to have a namespaces. These namespaces have been implemented with the help of modules and Submodules in Julia. So for to emulate the namespaces we have grouped the code into modules, such that each Type is wrapped in its own module. For Example the MCParticle Constructor would be a part of the MCParticleModule. the modules generated in parent namespaces required the collection of children in each namespace this is handled by the function [**get_namespace_dict**](https://github.com/AIDASoft/podio/blob/59fe1e740ca0a7dbff1180c1425047ed1ab3e027/python/podio_class_generator.py#L107-L115). 
 

_gsocblogs/2022/blog_Rucio_NimishBongale.md

@@ -174,7 +174,7 @@ The Rucio Client is an important piece of abstraction, playing a vital role in t
 
 #### SCSS Architecture
 
-The SCSS arhitecture in the new WebUI 2.0 is unconventional, but serves a mighty purpose - to have the ability to build our own components on the fly, or use out-of-the-box SCSS to style existing components. As a result, Rucio flavoured components are now a reality.
+The SCSS architecture in the new WebUI 2.0 is unconventional, but serves a mighty purpose - to have the ability to build our own components on the fly, or use out-of-the-box SCSS to style existing components. As a result, Rucio flavoured components are now a reality.
 
 #### Configuration & Environment Variable Control
 

_gsocproposals/2019/proposal_ROOTIpopt.md

@@ -10,7 +10,7 @@ organization:
 
 ## Description
 Ipopt (Interior Point OPTimizer)[1] is a software package for large-scale ​nonlinear optimization. It is designed to find (local) solutions of mathematical optimization problems.
-Ipopt is now integrated to ROOT framework providing a new set of tools for minization[2] through a ROOT plugin system in the math libraries.
+Ipopt is now integrated to ROOT framework providing a new set of tools for minimization[2] through a ROOT plugin system in the math libraries.
 
 ## Task ideas
   * To write support for:

_gsocproposals/2020/proposal_XRootDKubernetes.md

@@ -22,7 +22,7 @@ This project aims to develop a Kubernetes Operator for XRootD in order to ease a
 
  * Provide an **XRootD operator**, which will demonstrate how to deploy and manage an XRootD service at scale, using Kubernetes.
  * Implement Kubernetes operator's advanced features like **seamless upgrades**, **full lifecycle**, **deep insights** and **auto-pilot**.
- * Explain to the **XRootD community** and in peculiar, to the XRootD system administrators, how to leverage this  Kubernetes Operator in order to ease and scale up worlwide XRootD clusters management.
+ * Explain to the **XRootD community** and in peculiar, to the XRootD system administrators, how to leverage this  Kubernetes Operator in order to ease and scale up worldwide XRootD clusters management.
 
 ## Expected results
 

_gsocproposals/2024/proposal_PodioONNX.md

@@ -16,7 +16,7 @@ mentor_avail: May-October
 
 [PODIO](https://github.com/AIDASoft/podio) is a data model definition package that provides the necessary functionality to generate C++ and Python code from a high level definition of an event data model in yaml format. EDM4hep is an example of a data model generated with PODIO, which serves as the common event data model for many HEP communities, brought together under the umbrella of the [Key4hep](https://github.com/key4hep) project.
 
-With the increasing importance of artificial intelligence and machine learning workflows, there is a need to integate PODIO data models into these workflows. In particular, this may require specification or conversions of array-of-struct or struct-of-array data storage models in PODIO data models or on collections based on these data models.
+With the increasing importance of artificial intelligence and machine learning workflows, there is a need to integrate PODIO data models into these workflows. In particular, this may require specification or conversions of array-of-struct or struct-of-array data storage models in PODIO data models or on collections based on these data models.
 
 ## Task ideas
 

newsletter/_posts/2016-05-17-workshop-lal.md

@@ -56,7 +56,7 @@ on a review of the existing tools, and an attempt to identify a tool with the
  greatest potential as an integrating layer. One tool from the HPC world, 
  [Spack](https://spack.io/), generated a lot of interest. Some people tried to experiment with it in various 
  contexts in the past few months.  The workshop session facilitated an in-depth 
- dicussion about Spack's potential and it's limits. We reached consensus about how to move forward.  We will continue to collaborate with the Spack developer community.  When the features identified by the working group and documented in our technical note are available we'll start to recommend it to new projects and facilitate adoption by older projects.
+ discussion about Spack's potential and it's limits. We reached consensus about how to move forward.  We will continue to collaborate with the Spack developer community.  When the features identified by the working group and documented in our technical note are available we'll start to recommend it to new projects and facilitate adoption by older projects.
 
 See the [Packaging WG]({{ site.baseurl }}/workinggroups/2015/11/04/packaging.html) section on the web site for more details.
 

organization/_posts/2015/2015-02-10-startup.md

@@ -21,4 +21,4 @@ Michel: will present a summary of the HSF workshop at the GDB on Wednesday. Many
 
 Michel: have been contacted by IN2P3 to give them a short report about the SLAC workshop in February. During this discussion Giovanni Lamanna will also be present: this will also be useful to get another exchange with the astro community, with whom he is in close contact.
 
-Michel: having a look at Benedikt's slides (internal PH-SFT meeting) to prepare the GDB summary. The training mailing list is diaplayed on the slides with the wrong name. Andrea: will contact Benedikt and ask him to change them in Indico if possible.
+Michel: having a look at Benedikt's slides (internal PH-SFT meeting) to prepare the GDB summary. The training mailing list is displayed on the slides with the wrong name. Andrea: will contact Benedikt and ask him to change them in Indico if possible.

organization/_posts/2023/2023-05-25-coordination.md

@@ -123,7 +123,7 @@ The paper on *Potential of the Julia programming language for high energy physic
 
 Change of topic for the next meeting - we will hear from the DOE funded HEP CCE project, which is now reaching the end of its first funding phase.
 
-- Charles Leggett will present results on portable paralellisation layers
+- Charles Leggett will present results on portable parallelisation layers
 - Peter Van Gemmeren will present results on high-performance I/O
 
 [Meeting will be held jointly with ATLAS Core Software in Salle Curie](https://indico.cern.ch/event/1264297/), Wenesday 14 June at 16h30.

organization/_posts/2023/2023-06-08-coordination.md

@@ -114,7 +114,7 @@ Want to have an early meeting with the students, not just at the end of the codi
 
 Next week we will hear from the DOE funded HEP CCE project, which is now reaching the end of its first funding phase.
 
-- Charles Leggett will present results on portable paralellisation layers
+- Charles Leggett will present results on portable parallelisation layers
 - Peter Van Gemmeren will present results on high-performance I/O
 
 [Meeting will be held jointly with ATLAS Core Software in Salle Curie](https://indico.cern.ch/event/1264297/), Wenesday 14 June at 16h30.

organization/planning/plan-of-work-2023.md

@@ -47,7 +47,7 @@ and [30 March](https://indico.cern.ch/event/1225012/)
 
 ### Workshops
 
-* As travel restictions have now largely eased, we can organise more workshops
+* As travel restrictions have now largely eased, we can organise more workshops
 as in-person events, which we know are extremely productive, after last year's
 [Analysis Ecosystem II meeting](https://indico.cern.ch/event/1125222/)
 * In particular, we plan a [pre-CHEP workshop with WLCG](https://indico.cern.ch/event/1230126/), that should focus on