Fix typos in examples

AnisotropicNetworks/NematicTensor.ipynb

@@ -10,11 +10,11 @@
     "- Introduction to the nematic order parameter and nematic tensor.\n",
     "\n",
     "## Anisotropic networks\n",
-    "While graphs are conventionally defined in terms of their adjacency matrix, many material networks that we encounter in materials science contain some degree of anisotropy, which is not captured by the conventional treatment. One of the most typical examples of this anisotropy is alignment of edge along one (or sometimes several) common directions. This has been shown to impart exotic properties to a variety of networks, including auxetic behavior in strut lattices, and axially dependent resistance in conductive films. It is therefore very important to be able to detect network anisotropy, using tools beyond graph theory. In soft matter physics, particle alignment is well quantified by the nematic tensor. Readers new to the nematic tensor, should consult the [tutorial](https://freud.readthedocs.io/en/latest/gettingstarted/examples/module_intros/order.Nematic.html) in documentation from the *freud* library, which is the library used for the computation.\n",
+    "While graphs are conventionally defined in terms of their adjacency matrix, many material networks that we encounter in materials science contain some degree of anisotropy, which is not captured by the conventional treatment. One of the most typical examples of this anisotropy is the alignment of edges along one (or sometimes several) common directions. This has been shown to impart exotic properties to a variety of networks, including auxetic behavior in strut lattices and axially dependent resistance in conductive films. It is therefore very important to be able to detect network anisotropy, using tools beyond graph theory. In soft matter physics, particle alignment is well quantified by the nematic tensor. Readers new to the nematic tensor should consult the [tutorial](https://freud.readthedocs.io/en/latest/gettingstarted/examples/module_intros/order.Nematic.html) in documentation for the *freud* library, which is the library *StructuralGT* uses for this computation.\n",
     "\n",
     "In *StructuralGT*, the nematic tensor is calculated by first calculating the orientations of all the edges, where each orientation is estimated from the line segment going through the start and end points of the edge. The orientations may be used, along with the nematic tensor, for analysis.\n",
     "\n",
-    "First, let's begin by extracting a graph from an SEM image of aligned nanowires, taken from a publication by [Wu et al.](https://doi.org/10.1016/j.matt.2024.09.014)."
+    "First, let's begin by extracting a graph from an SEM image of aligned nanowires, taken from a publication by [Wu et al](https://doi.org/10.1016/j.matt.2024.09.014)."
    ]
   },
   {
@@ -90,7 +90,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Let's now plot the network, and color the edges by their orientation."
+    "Let's now plot the network and color the edges by their orientation."
    ]
   },
   {

Introduction-to-StructuralGT/0-File-layouts.ipynb

@@ -7,11 +7,11 @@
     "# File layouts\n",
     "## Notebook overview\n",
     "- Explain how images of 2D networks should be stored before using *StructuralGT*\n",
-    "- Explain how image stacks of 3D networks should be named and stored, and named, before using *StructuralGT*\n",
+    "- Explain how image stacks of 3D networks should be named and stored before using *StructuralGT*\n",
     "- Give some examples of how *StructuralGT* will access the file system given a particular file system layout and set of constructor arguments\n",
     "\n",
     "## Interacting with network images using *StructuralGT*'s `Network` class\n",
-    "*StructuralGT* interacts with images of networks via the `Network` class. Before using the `Network` class, you must first ensure your network images are laid out in your directory appropriately. Network images may be either a single image from which you would like to extract a two-dimensional (2D) network or it may be a stack of 2D images which represent a three-dimensional (3D) network. In either case, when using *StructuralGT*, **each material network must be stored in it’s own directory.** Let's look at some examples of how the `Network` class behaves given a particular file system layouts and constructor arguments.\n",
+    "*StructuralGT* interacts with images of networks via the `Network` class. Before using the `Network` class, you must first ensure your network images are laid out in your directory appropriately. Network images may be either a single image from which you would like to extract a two-dimensional (2D) network or it may be a stack of 2D images which represent a three-dimensional (3D) network. In either case, when using *StructuralGT*, **each material network must be stored in its own directory.** Let's look at some examples of how the `Network` class behaves given particular file system layouts and constructor arguments.\n",
     "\n",
     "## 2D network images\n",
     "For 2D network images, it is simplest to store a single image in a directory. Let's take an image than was used in a publication with *StructuralGT*:\n",
@@ -105,15 +105,15 @@
    "metadata": {},
    "source": [
     "## 3D images\n",
-    "For 3D data, the images must be stored as a stack of 2D images and all of which must be named with an identical prefix, followed by a 4 digit identification of its depth, e.g. slice0000.tiff:\n",
+    "For 3D data, the images must be stored as a stack of 2D images and all of these images must be named with an identical prefix, followed by a 4 digit identification of its depth, e.g. slice0000.tiff:\n",
     "```\n",
     "Nanofibres/\n",
     "   slice0281.tif\n",
     "   slice0282.tif\n",
     "   ...\n",
     "   slice0292.tif\n",
     "   ```\n",
-    "For ease of demonstration the number of files in this directory is significantly smaller than that typically required. For 3D network images, `prefix` must be specified, and `dim` must be set to `3`."
+    "For ease of demonstration, the number of files in this directory is significantly smaller than that typically required. For 3D network images, `prefix` must be specified, and `dim` must be set to `3`."
    ]
   },
   {

Introduction-to-StructuralGT/1-Image-processing.ipynb

@@ -6,7 +6,7 @@
    "source": [
     "# Image processing\n",
     "## Notebook overview\n",
-    "- Explain how images networks should be processed before graph extraction\n",
+    "- Explain how image networks should be processed before graph extraction\n",
     "\n",
     "## Boilerplate code"
    ]
@@ -25,7 +25,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Once you have a `Network` object, the next step involves binarizing your networked images.  Optimal values for these parameters are best identified through trial and error, which can be efficiently carried out with the aid of the `Binarizer` class, which offers interactive binarization in a Jupyter Notebook. To use, pass the file name of the image to the constructor:"
+    "Once you have a `Network` object, the next step involves binarizing your networked images.  Optimal values for these parameters are best identified through trial and error, which can be efficiently carried out with the aid of the `Binarizer` class, which offers interactive binarization in a Jupyter Notebook. To use it, pass the file name of the image to the constructor:"
    ]
   },
   {
@@ -43,7 +43,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "When you are finished, tick the Export box. This saves the current image processing options to a `img_options.json` file in the same directory as the image you are working with:\n",
+    "When you are finished, tick the Export box. This saves the current image processing options to an `img_options.json` file in the same directory as the image you are working with:\n",
     "```\n",
     "Nanowires/\n",
     "   Nanowires.tif\n",
@@ -73,7 +73,7 @@
     "   Nanowires.tif\n",
     "   img_options.json\n",
     "```\n",
-    "If you later chose to carry out graph theoretic computations with *StructuralGT* on the `Nanowires` object, many of results will be stored at the `Binarized/` subdirectory, as opposed to at the `Nanowires/` level. This is because results depend on the particular choice of image processing parameters. If you wish to try a few different sets of parameters, specify how you would like to name the subdirectory for binarized image(s) and pass the different image processing options to different calls to `binarize()`. Image processing parameters may be passed as filenames or dictionaries:"
+    "If you later chose to carry out graph theoretic computations with *StructuralGT* on the `Nanowires` object, many of the results will be stored at the `Binarized/` subdirectory, as opposed to at the `Nanowires/` level. This is because those results depend on the particular choice of image processing parameters. If you wish to try a few different sets of parameters, specify how you would like to name the subdirectory for binarized image(s) and pass the different image processing options to different calls to `binarize()`. Image processing parameters may be passed as filenames or dictionaries:"
    ]
   },
   {
@@ -112,7 +112,7 @@
     "   Nanowires.tif\n",
     "   img_options.json\n",
     "```\n",
-    "You will see that the Gaussian blur removed much of the noise in the image, and so will be the best image to use in future tutorials."
+    "You will see that the Gaussian blur removed much of the noise in the image, and so it will be the best image to use in future tutorials."
    ]
   }
  ],

Introduction-to-StructuralGT/2-Graph-extraction.ipynb

@@ -27,7 +27,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Once an image has been binarized, the *skeleton*, which is a 1-pixel wide representation of the network, is computed. This is achieved by calling the `img_to_skel()` method. This saves a `.gsd`, which can be openend with OVITO. It also sets the `skeleton` attribute, which can be examined to predict the quality of our subsequent graph extraction:"
+    "Once an image has been binarized, the *skeleton*, which is a 1-pixel wide representation of the network, is computed. This is achieved by calling the `img_to_skel()` method. This saves a `.gsd` file, which can be opened with OVITO. It also sets the `skeleton` attribute, which can be examined to predict the quality of our subsequent graph extraction:"
    ]
   },
   {
@@ -72,7 +72,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "There are several options that may be passed to `img_to_skel()`. They are too numerous to cover here but can be found at the API documentation. To extract the graph from the skeleton, the `set_graph()` method should be called. Again, optional parameters for this method are covered in the API. "
+    "There are several options that may be passed to `img_to_skel()`. They are too numerous to cover here but can be found in the API documentation. To extract the graph from the skeleton, the `set_graph()` method should be called. Again, optional parameters for this method are covered in the documentation. "
    ]
   },
   {
@@ -105,7 +105,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Calling `set_graph` does 2 things: its sets the `graph` attribute, and stores features of the graph in a `.json` and `.gsd` file, from which the `Network` can later be loaded. The `graph` object is an `igraph.Graph` object, from the [igraph](https://python.igraph.org/en/stable/) library. *igraph* is a library for carrying out computations on graphs. Access to an `igraph.Graph` object hence affords the user all of the capabilities of this library. For example, consulting the *igraph* [documentation](https://python.igraph.org/en/stable/api/igraph.Graph.html) on the `igraph.Graph` object, we may examine the adjacency matrix, and confirm it is a square matrix with length equal to the number of nodes:"
+    "Calling `set_graph` does 2 things: it sets the `graph` attribute, and it stores features of the graph in a `.json` file and a `.gsd` file, from which the `Network` can later be loaded. The `graph` object actually has the class `igraph.Graph`, from the external [igraph](https://python.igraph.org/en/stable/) library. Using the `igraph.Graph` class interface, we can learn a lot about our graph. For example, consulting the *igraph* [documentation](https://python.igraph.org/en/stable/api/igraph.Graph.html) on this class, we can see that we may examine the adjacency matrix via the `get_adjacency()` method, allowing us to confirm that it is a square matrix with side length equal to the number of nodes:"
    ]
   },
   {

Introduction-to-StructuralGT/3-Graph-calculations.ipynb

@@ -28,11 +28,11 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "As explained before, *StructuralGT*'s `Network` object is the representation of the system. The other objects to be aware of are the `Compute` modules, which operate on `Network` objects to perform graph theoretic computations which are especially pertinent to materials science. All `Compute` modules follow similar use, and are modelled off of the `Compute` modules developed in the [freud](https://freud.readthedocs.io/en/latest/) library for particle trajectory analysis:\n",
+    "As explained before, *StructuralGT*'s `Network` object is the representation of the system. The other objects to be aware of are the `Compute` modules, which operate on `Network` objects to perform graph theoretic computations which are especially pertinent to materials science. All `Compute` modules follow have a similar interface, and they are modelled off of the `Compute` modules developed in the [freud](https://freud.readthedocs.io/en/latest/) library for particle trajectory analysis. Most importantly:\n",
     "- They are instantiated separately from the `Network`. If you wish to use node or edge weights, pass the relevant argument here.\n",
     "- Their `compute` method is called with the `Network` as an argument.\n",
     "- Results are then stored in attributes of the `Compute` module.\n",
-    "In this section, we will give an example of the `Degree` module, from the `structural` library, which calculated the number of edges connected to every node."
+    "In this section, we will give an example of the `Degree` module (from the `structural` library), which calculates the number of edges connected to every node."
    ]
   },
   {
@@ -60,7 +60,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "This indicates that, on average, there are ~2.78 edges connected to each node, which seems reasonable. We can investigate the local distribution by calling the `node_plot` method of the `Network`, passsing the array of degrees from the `Degree` module."
+    "This indicates that, on average, there are ~2.79 edges connected to each node, which seems reasonable. We can investigate the local distribution by calling the `node_plot()` method of the `Network`, passsing the array of degrees from the `Degree` module."
    ]
   },
   {
@@ -97,7 +97,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "This is just one of the simplest ways a `Compute` module can be used for structural characterization. For property prediction, check out the tutorials on linear networked transport phenomena. For non-linear transport problems, the betweenness module may be helpful. For analysing geometric, instead of topological network properties, checkout the geometric module."
+    "This is just one of the simplest ways a `Compute` module can be used for structural characterization. For property prediction, check out the tutorials on linear networked transport phenomena. For non-linear transport problems, the betweenness module may be helpful. For analysing geometric (instead of topological) network properties, check out the geometric module."
    ]
   }
  ],