Make suggested docs changes

Author: imreddyTeja

docs/src/matrix_fields.md

@@ -107,7 +107,7 @@ scalar_field_matrix
 
 A FieldMatrix entry can be:
 
-- An `UniformScaling`, which contains a `Number`
+- A `UniformScaling`, which contains a `Number`
 - A `DiagonalMatrixRow`, which can contain either a `Number` or a tensor (represented as a `Geometry.Axis2Tensor`)
 - A `ColumnwiseBandMatrixField`, where each value is a [`BandMatrixRow`](@ref) with entries of any type that can be represented using the field's base number type.
 
@@ -162,29 +162,22 @@ An example of this is:
  A = MatrixFields.FieldMatrix((@name(name1), @name(name2)) => sample_entry)
 ```
 
-Now consider what happens indexing `A` with the key `(@name(name1.foo.bar.buz), @name(name2.biz.bop.fud))`.
+Now consider what happens when indexing `A` with the key `(@name(name1.foo.bar.buz), @name(name2.biz.bop.fud))`.
 
 First, `getindex` finds a key in `A` that contains the key being indexed. In this example, `(@name(name1.foo.bar.buz), @name(name2.biz.bop.fud))` is contained within `(@name(name1), @name(name2))`, so `(@name(name1), @name(name2))` is called the "parent key" and `(@name(foo.bar.buz), @name(biz.bop.fud))` is referred to as the "internal key".
 
 Next, the entry that `(@name(name1), @name(name2))` is paired with is recursively indexed
 by the internal key.
 
-The recursive indexing of an internal entry given some entry `entry` and internal_key `internal_name_pair`
+The recursive indexing of an internal entry given some entry `entry` and internal key `internal_name_pair`
 works as follows:
 
 1. If the  `internal_name_pair` is blank, return `entry`
-2. If the element type of each band of `entry` is an `Axis2Tensor`, and `internal_name_pair` is of the form
-`(@name(components.data.1...), @name(components.data.2...))` (potentially with different numbers),
-then extract the specified component, and recurse on it with the remaining `internal_name_pair`.
+2. If the element type of each band of `entry` is an `Axis2Tensor`, and `internal_name_pair` is of the form `(@name(components.data.1...), @name(components.data.2...))` (potentially with different numbers), then extract the specified component, and recurse on it with the remaining `internal_name_pair`.
 3. If the element type of each band of `entry` is a `Geometry.AdjointAxisVector`, then recurse on the parent of the adjoint.
-4. If `internal_name_pair[1]` is not empty, and the first name in it is a field of the element type of each band of `entry`,
-extract that field from `entry`, and recurse into it with the remaining names of `internal_name_pair[1]` and all of `internal_name_pair[2]`
-5. If `internal_name_pair[2]` is not empty, and the first name in it is a field of the element type of each band of `entry`,
-extract that field from `entry`, and recurse into it with all of `internal_name_pair[1]` and the remaining names of `internal_name_pair[2]`
-6. At this point, if none of the previous cases are true, both `internal_name_pair[1]` and `internal_name_pair[2]` should be
-non-empty, and it is assumed that `entry` is being used to implicitly represent some tensor structure. If the first name in
-`internal_name_pair[1]` is equivalent to `internal_name_pair[2]`, then both the first names are dropped, and entry is recursed onto.
-If the first names are different, both the first names are dropped, and the zero of entry is recursed onto.
+4. If `internal_name_pair[1]` is not empty, and the first name in it is a field of the element type of each band of `entry`, extract that field from `entry`, and recurse into it with the remaining names of `internal_name_pair[1]` and all of `internal_name_pair[2]`
+5. If `internal_name_pair[2]` is not empty, and the first name in it is a field of the element type of each band of `entry`, extract that field from `entry`, and recurse into it with all of `internal_name_pair[1]` and the remaining names of `internal_name_pair[2]`
+6. At this point, if none of the previous cases are true, both `internal_name_pair[1]` and `internal_name_pair[2]` should be non-empty, and it is assumed that `entry` is being used to implicitly represent some tensor structure. If the first name in `internal_name_pair[1]` is equivalent to `internal_name_pair[2]`, then both the first names are dropped, and entry is recursed onto. If the first names are different, both the first names are dropped, and the zero of entry is recursed onto.
 
 When the entry is a `ColumnWiseBandMatrixField`, indexing it will return a broadcasted object in
 the following situations:
@@ -224,7 +217,7 @@ A `ColumnwiseBandMatrixField` is a `Field` with a `BandMatrixRow` at each point.
 to represent a collection of banded matrices, where there is one band matrix for each column
 of the space the `Field` is on. Beyond only storing the diagonals of the band matrix, an `entry`
 can be optimized to use less memory. Each optimized representation can be indexed equivalently to
-non optimized representation, and used in addition, subtraction, Matrix-vector multiplication,
+non optimized representations, and used in addition, subtraction, matrix-vector multiplication,
 Matrix-matrix multiplication, `RecursiveApply`, and `FieldMatrixSolver`.
 
 For the following sections, `space` is a column space with $N_v$ levels. A column space is
@@ -240,8 +233,8 @@ $M$ represents $\frac{\partial f}{\partial g}$, so $M_{i,j} = \frac{\partial f_i
 
 Consider the case where $b_1 = 0$ and $b_2 = 0$, i.e $M$ is a diagonal matrix, and
 where $M = k * I$, and $k$ is of type `T_k`. This would happen if
-$\frac{\partial f_i}{\partial g_j} = [i=j] * k$. Instead of storing
-each element on the diagonal, less memory can be used by storing a single value that represents a scaling of the identity. This reduces memory usage by a factor of $N_v$.
+$\frac{\partial f_i}{\partial g_j} = \delta_{ij} * k$. Instead of storing
+each element on the diagonal, the `FieldMatrix` can store a single value that represents a scaling of the identity matrix, reducing memory usage by a factor of $N_v$:
 
 ```julia
 entry = fill(DiagonalMatrixRow(k), space)
@@ -265,21 +258,20 @@ The functions that index an entry with an internal key assume the implicit tenso
 when all of the following are true for `entry` where `T_k` is the element type of each band, and
 `(internal_key_1, internal_key_2)` is the internal key indexing `entry`.
 
-- the first key in the `internal_key_1` name chain is not a fieldname of `T_k`
-- the first key in the `internal_key_2` name chain is not a fieldname of `T_k`
-- `internal_key_1` and `internal_key_2` are both not empty
+- the `internal_key_1` name chain is not empty and its first name is not a field of `T_k`
+- the `internal_key_2` name chain is not empty and its first name is not a field of `T_k`
 
 For most use cases, `T_k` is a scalar.
 
 If the above conditions are met, the optimization assumes that the user intends the
 entry to have an implicit tensor structure, with the values of type `T_k` representing a scaling of the
-tensor identity. If both the first and second name in the name pair are equivalent, then they index onto the diagonal,
-and the value is returned. Otherwise, they index off the diagonal, and a zero value
+identity tensor. If both the first and second names in the name pair are equivalent, then they index onto the diagonal,
+and the scalar value of `k` is returned. Otherwise, they index off the diagonal, and a zero value
 is returned.
 
-This optimization is intended to be used when `T_f = T_g`, and they are both `AxisVectors`
-The notation $f_{n}[i]$ where $0 < n \leq N_v$  refers to the $i$ component of the element
-at the $n$ vertical level of $f$. In the following example, `T_f=T_g=Covariant12Vector`, and
+This optimization is intended to be used when `T_f = T_g`.
+The notation $f_{n}[i]$ where $0 < n \leq N_v$  refers to the $i$-th component of the element
+at the $n$-th vertical level of $f$. In the following example, `T_f` and `T_g` are both `Covariant12Vector`s, and
 $b_1 = b_2 = 1$, and
 
 ```math
@@ -310,9 +302,9 @@ J[(@name(f.components.data.:(2)), @name(g.components.data.:(1)))]
 
 This can be more optimally stored with the implicit tensor structure optimization:
 
-```@example 2
-∂f_∂g = fill(MatrixFields.TridiagonalMatrixRow(-0.5, 1.0, -0.5), space) # hide
-J = MatrixFields.FieldMatrix((@name(f), @name(g))=> ∂f_∂g) # hide
+```@setup 2
+∂f_∂g = fill(MatrixFields.TridiagonalMatrixRow(-0.5, 1.0, -0.5), space)
+J = MatrixFields.FieldMatrix((@name(f), @name(g))=> ∂f_∂g)
 ```
 
 ```julia
@@ -337,15 +329,5 @@ If it is the case that
 \end{cases}
 ```
 
-where $k$ is a constant scalar, both the implicit tensor structure optimization and
-`ScalingFieldMatrixEntry` optimization can both be applied:
-
-```julia
-∂f_∂g = fill(MatrixFields.DiagonalMatrixRow(k), space)
-```
-
-can equivalently be represented with
-
-```julia
-∂f_∂g = MatrixFields.DiagonalMatrixRow(k)
-```
+where $k$ is a constant scalar, the implicit tensor structure optimization and
+`ScalingFieldMatrixEntry` optimization can both be applied.

src/MatrixFields/field_name_dict.jl

@@ -343,7 +343,8 @@ what method can index a ClimaCore `Field` of `S` with `name_pair`.
 
 The third return value is one of the following:
 - `Val(:view)`: indexing with a view is possible
--  `Val(:view_of_blocks)`: indexing with a view of blocks is possible (this is not implemented)
+-  `Val(:view_of_blocks)`: indexing with a view of non-unfiform stride length is possible.\
+ This is not implemented, and currently treated the same as `Val(:broadcasted_fallback)`
 - `Val(:broadcasted_fallback)`: indexing with a view is not possible
 - `Val(:broadcasted_zero)`: indexing with a view is not possible, and the `name_pair` indexes
 off diagonal with implicit tensor structure optimization (see MatrixFields docs)