Update docstrings and documentation

Added docstrings for XdVAR descriptions and proof-read/made minor corrections the documentation

docs/src/community/Contributing.md

@@ -2,7 +2,7 @@
 
 ## What to expect
 
-This is currenlty a small project maintained by a small community of researchers and
+This is currently a small project maintained by a small community of researchers and
 developers, focused on academic research in data assimilation and machine learning
 methodology. This software is not intended for use in an operational data assimilation
 environment, or even for use with real data, as there are a variety of existing alternatives
@@ -36,23 +36,23 @@ bug you have encountered that will allow the community to reproduce and solve th
 Reproducibility is key, and if there are not sufficient details to reproduce an issue,
 the issue will be sent back for more details.
 
-## How to contribute new methods, models or other core core
+## How to contribute new methods, models or other core code
 
-The best way to contribute new code is to reach out to the community first, as this code
-base is in an early and active state of development and will occassionally face breaking
-changes in order to accomodate more generality and new features.  Please start with an
+The best way to contribute new code is to reach out to the community first as this code
+base is in an early and active state of development and will occasionally face breaking
+changes in order to accommodate more generality and new features.  Please start with an
 introduction of yourself in the 
 [Github discussions](https://github.com/cgrudz/DataAssimilationBenchmarks.jl/discussions)
 followed by a detailed feature request in the
 [Github issues](https://github.com/cgrudz/DataAssimilationBenchmarks.jl/issues),
 covering your use-case and what new functionality you are proposing. This will help
 the community anticipate your needs and the backend changes that might need to be implemented
-in order to accomodate new functionality. There is not currently a general system for
-how new data assmiliation methods or models are to be implemented, and it is therefore
+in order to accommodate new functionality. There is not currently a general system for
+implementing new data assimilation methods or models, and it is therefore
 critical to bring up your use-case to the community so that how this new feature is
-incorporated can be planned into the development.  Once the issue can be evaluated and
+incorporated can be planned into the development. Once the issue can be evaluated and
 discussed by the development community, the strategy is usually to create a fork of the
-main code base where new modules and features can be prototyped.  Once the new code
+main code base where new modules and features can be prototyped. Once the new code
 development is ready for a review, a pull request can be made where the new functionality
 may be merged, and possibly further refactored for general consistency and consolidation
 of codes.

docs/src/home/DataAssimilationBenchmarks.md

@@ -2,8 +2,8 @@
 The following type and type constructors are declared for optimizing numerical routines,
 for using multiple dispatch of functions with different specified input forms and for
 passing arguments between inner / outer loop steps of the DA twin experiment. Type
-constructors are designed to be flexible enough to handle multiple dispactch for
-automatic code differentiation, though seek to ensure type consistency within mehtods
+constructors are designed to be flexible enough to handle multiple dispatch for
+automatic code differentiation, though seek to ensure type consistency within methods
 for improved performance.
 
 ```@autodocs

docs/src/home/Getting Started.md

@@ -4,7 +4,7 @@
 
 The main module DataAssimilationBenchmarks.jl declares global types and type constructors.
 These conventions are utilized in sub-modules that implement the core numerical solvers
-for ordinary and stochastic differential equations, solvers for data assimilation routines
+for ordinary and stochastic differential equations, solvers for data assimilation routines,
 and the core process model code for running twin experiments with benchmark models, collected
 in the `methods` and `models` sub-directories.  Experiments define routines for driving
 standard benchmark case studies with

docs/src/home/Introduction.md

@@ -4,7 +4,7 @@
 
 The purpose of this package is to provide a research framework for the theoretical
 development and empirical validation of novel data assimilation techniques.
-While analytical proofs can be derived for classical methods such as the Kalman filter
+While analytical proofs can be derived for classical methods, such as the Kalman filter
 in linear-Gaussian dynamics, most currently developed DA
 techniques are designed for estimation in nonlinear, non-Gaussian models where no
 analytical solution typically exists.  Rigorous validation of novel data assimilation
@@ -24,7 +24,7 @@ simple test systems. Many basic research frameworks, furthermore, do not include
 standard operational techniques developed from classical VAR methods, due to the 
 difficulty in constructing tangent linear and adjoint codes.
 DataAssimilationBenchmarks.jl provides one framework for studying
-squential filters and smoothers that are commonly used in online, geoscientific
+sequential filters and smoothers that are commonly used in online, geoscientific
 prediction settings, including ensemble estimators, classical VAR techniques
 (currently in-development) and (in-planning) hybrid-EnVAR methods. 
 

docs/src/index.md

@@ -1,6 +1,6 @@
 # Description
 
-This is a data assimilation research code base with an emphasis on prototyping, testing and
+This is a data assimilation research code base with an emphasis on prototyping, testing, and
 validating sequential filters and smoothers in toy model twin experiments.
 This code is meant to be performant in the sense that large hyper-parameter discretizations
 can be explored to determine hyper-parameter sensitivity and reliability of results across

docs/src/submodules/analysis/ProcessExperimentData.md

@@ -11,7 +11,7 @@ the output .jld2 file and if this is not available, this will store `Inf` values
 Benchmark configurations for the above filtering and smoothing experiments are available in the open access article
 [Grudzien et al. 2021](https://gmd.copernicus.org/preprints/gmd-2021-306/),
 with details on the algorithm and parameter specifications discussed in the experiments section.  Performance of filtering and
-smoothing schemes should be validated versus the numerical results presented there for root mean square error and ensemble spread.
+smoothing schemes should be validated versus the numerical results for root mean square error and ensemble spread.
 Simple versions of these diagnostics are built for automatic testing of the filter and smoother experiments for state and parameter estimation
 in the L96-s model.  Further test cases are currently in development.  The deterministic Runge-Kutta and Euler scheme for ODEs are
 validated in the package tests, estimating the order of convergence with the least-squares log-10 line fit between step size

docs/src/submodules/experiments/FilterExps.md

@@ -16,10 +16,10 @@ these arguments are as follows:
   * `nanl` - the number of observation / analysis times to produce a posterior estimate;
   * `obs_un` - the observation error standard deviation, assuming a uniform scaling observation error covariance;
   * `obs_dim` - the dimension of the observation vector;
-  * `γ` - defines nonliearity in the [`DataAssimilationBenchmarks.ObsOperators.alternating_obs_operator`](@ref);
+  * `γ` - defines nonlinearity in the [`DataAssimilationBenchmarks.ObsOperators.alternating_obs_operator`](@ref);
   * `N_ens` - the ensemble size for ensemble-based filters;
   * `s_infl` - the multiplicative inflation for the empirical model state covariance;
-  * `p_infl` - the multiplicative inlfation for the empirical parameter sample covariance;
+  * `p_infl` - the multiplicative inflation for the empirical parameter sample covariance;
   * `p_err` - defines initial parameter sample standard deviation as `p_err` percent of the system parameter value;
   * `p_wlk` - defines the standard deviation of a Gaussian random walk as `p_wlk` percent of the estimated parameter value for a random parameter model.
 

docs/src/submodules/experiments/GenerateTimeSeries.md

@@ -11,8 +11,8 @@ specific experiment function:
      diffusion::Float64)::NamedTuple)
 ```
 Conventions for these arguments are as follows:
-  * `seed` - specifies initial condition for the pseudo-random number generator on which various simulation settings will depend, and will be reproduceable with the same `seed` value;
-  * `h` - is the numerical integration step size, controling the discretization error of the model evolution;
+  * `seed` - specifies initial condition for the pseudo-random number generator on which various simulation settings will depend and will be reproducible with the same `seed` value;
+  * `h` - is the numerical integration step size, controlling the discretization error of the model evolution;
   * `state_dim` - controls the size of the [Lorenz-96 model](@ref) model though other models such as the [IEEE39bus](@ref) model are of pre-defined size;
   * `tanl` - (__time-between-analysis__) defines the length of continuous time units between sequential observations;
   * `nanl` - (__number-of-analyses__) defines the number of observations / analyses to be saved;

docs/src/submodules/experiments/SmootherExps.md

@@ -17,7 +17,7 @@ with the required fields as specified in the experiment method.  Conventions for
 these arguments are the same as with the [FilterExps](@ref), with the additional options
 that configure  the data assimilation window (DAW) and how this is shifted in time:
   * `lag` - the number of past observation / analysis times to reanalyze in a DAW, corresponding to ``L`` in the figure above;
-  * `shift`- the nunber of observation / analysis times to shift the DAW, corresponding to ``S`` in the figure above;
+  * `shift`- the number of observation / analysis times to shift the DAW, corresponding to ``S`` in the figure above;
   * `mda` - (__Multiple Data Assimilation__), type `Bool`, determines whether the technique of multiple data assimilation is used (only compatible with `single_iteration` and `iterative` smoothers.
 
 Currently debugged and validated smoother experiment configurations include

docs/src/submodules/experiments/Workflow.md

@@ -7,7 +7,7 @@ data type.  A basic workflow to run a data assimilation twin
 experiment is to first generate a time series for observations using a choice of
 tuneable parameters using the [GenerateTimeSeries](@ref) submodule.  Once the time
 series data is generated from one of the benchmark models, one can use this data as a
-truth twin to generate pseudo-obseravtions. This time series can thus be re-used over
+truth twin to generate pseudo-observations. This time series can thus be re-used over
 multiple configurations of filters and smoothers, holding the pseudo-data fixed while
 varying other hyper-parameters.  Test cases in this package model this workflow,
 to first generate test data and then to implement a particular experiment based

docs/src/submodules/methods/EnsembleKalmanSchemes.md

@@ -5,11 +5,11 @@ which define the outer-loop of the data assimilation cycle.  Particularly, these
 how the sequential data assimilation cycle will pass over a time series of observations,
 with more details in the [SmootherExps](@ref) documents.
 
-Ensemble filters only produce analyses forward-in-time.  The classic lag-shift smoother runsi
+Ensemble filters only produce analyses forward-in-time.  The classic lag-shift smoother runs
 identically to the filter in its forecast and filter steps, but includes an additional retrospective
 analysis to past ensemble states stored in memory.  The single iteration smoother follows
 the same convention as the classic smoother, except in that new cycles are initiated from
-a past, reanlyzed ensemble state.  The Gauss-Newton iterative smoothers are 4D smoothers,
+a past, reanalyzed ensemble state.  The Gauss-Newton iterative smoothers are 4D smoothers,
 which iteratively optimize the initial condition at the beginning of a data assimilation
 cycle, and propagate this initial condition to initialize the subsequent cycle. A full
 discussion of these methods can be found in

docs/src/submodules/models/IEEE39bus.md

@@ -58,7 +58,7 @@ By definition the standard deviation of $W_{i,\Delta_t}$ is equal to $\sqrt{\Del
 for each time-discretization of the Wiener process of step size $\Delta$,
 $\frac{s \omega_R}{2 H_i}W_{i,\Delta_t}$ is a mean zero, Gaussian distributed variable
 with standard deviation $\frac{s \omega_\mathrm{R}}{2}\sqrt{\Delta}$.  The reference
-frequency in North America is 60 Hz and the tolerable deviation from this frequency under
+frequency in North America is 60 Hz, and the tolerable deviation from this frequency under
 normal operations is approximately $\pm 0.05$ Hz, or of magnitude
 approximately $0.08\%$.  In the above model, the
 reference frequency is in radians, related to the reference frequency in Hz as

docs/src/submodules/models/ObsOperators.md

@@ -17,7 +17,7 @@ vector arguments and multi-arrays using mutliple dispatch with the conventions:
 function H_obs(x::VecA(T), obs_dim::Int64, kwargs::StepKwargs) where T <: Real
 function H_obs(x::ArView(T), obs_dim::Int64, kwargs::StepKwargs) where T <: Real
 ```
-allowing for the same naming to be used for single states, time series of states and
+allowing for the same naming to be used for single states, time series of states, and
 ensembles of states.