diff --git a/.github/workflows/check-spelling.yml b/.github/workflows/check-spelling.yml new file mode 100644 index 0000000000..8825e58b06 --- /dev/null +++ b/.github/workflows/check-spelling.yml @@ -0,0 +1,44 @@ +name: Checks - spelling + +on: + pull_request: + workflow_dispatch: + +jobs: + spelling_check: + runs-on: ubuntu-latest + steps: + - name: Install python3-pip + run: | + sudo apt update + sudo apt install -y --no-install-recommends python3-pip + + - name: Install codespell + run: pip install codespell + + - name: Print codespell version + run: codespell --version + + - name: Check out repository code + uses: actions/checkout@v4 + with: + submodules: true + + - name: Run codespell + run: | + ./scripts/spelling.sh + + - name: Run git diff to see if anything changed + run: /usr/bin/git diff --name-only --exit-code + + - name: Run git diff if we failed + if: failure() + run: /usr/bin/git diff > spelling.patch + + - name: Archive diff as a patch if we failed + uses: actions/upload-artifact@v3 + if: failure() + with: + name: spelling.patch + path: | + ${{ github.workspace }}/spelling.patch diff --git a/CHANGELOG.md b/CHANGELOG.md index 3291523216..61bf6ea6d0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -10,6 +10,9 @@ Fixed the loading of ARKStep's default first order explicit method. +Fixed a CMake bug regarding usage of missing "print_warning" macro +that was only triggered when the deprecated `CUDA_ARCH` option was used. + ### Deprecation Notices ## Changes to SUNDIALS in release 7.1.1 @@ -1789,7 +1792,7 @@ update their code to set the corresponding `ops` structure member, `matvecsetup`, to `NULL`. The generic SUNMatrix API now defines error codes to be returned by SUNMatrix -operations. Operations which return an integer flag indiciating success/failure +operations. Operations which return an integer flag indicating success/failure may return different values than previously. A new SUNMatrix (and SUNLinearSolver) implementation was added to facilitate @@ -1901,7 +1904,7 @@ function signatures have been changed including MRIStepCreate which now takes an ARKStep memory structure for the fast integration as an input. The reinitialization functions `ERKStepReInit`, `ARKStepReInit`, and -`MRIStepReInit` have been updated to retain the minimum and maxiumum step +`MRIStepReInit` have been updated to retain the minimum and maximum step size values from before reinitialization rather than resetting them to the default values. @@ -1926,7 +1929,7 @@ being built. Fixed a memory leak in the PETSc `N_Vector` clone function. -Fixed a memeory leak in the ARKODE, CVODE, and IDA F77 interfaces when not using +Fixed a memory leak in the ARKODE, CVODE, and IDA F77 interfaces when not using the default nonlinear solver. Fixed a bug in the ARKStep time-stepping module in ARKODE that would result in @@ -2638,7 +2641,7 @@ with sparse direct solvers. #### KINSOL -The Picard iteration return was chanegd to always return the newest iterate upon +The Picard iteration return was changed to always return the newest iterate upon success. A minor bug in the line search was fixed to prevent an infinite loop when the diff --git a/CMakeLists.txt b/CMakeLists.txt index 989c1d7f7d..61b164f678 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -187,7 +187,7 @@ include(SundialsSetupCompilers) include(SundialsSetupTPLs) # =============================================================== -# Build options to be proccessed last +# Build options to be processed last # =============================================================== include(SundialsBuildOptionsPost) diff --git a/CODEOWNERS b/CODEOWNERS index 8d465ce4e5..e017386f2b 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -3,6 +3,6 @@ # These owners will be the default owners for everything in # the repo. Unless a later match takes precedence, -# globabl owners will be requested for review when someone +# global owners will be requested for review when someone # opens a pull request. * @balos1 @gardner48 @cswoodward @drreynolds diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4106e3738b..be273c77a2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,6 @@ # Contributing to SUNDIALS -There are two primary ways of contributing to SUNDIALS. The first way is by particpating +There are two primary ways of contributing to SUNDIALS. The first way is by participating in the development of SUNDIALS directly through contributions of code to the primary [SUNDIALS repository](https://github.com/LLNL/sundials). This is the best way to contribute bug fixes and minor improvements. At this time, the SUNDIALS team does not have the resources diff --git a/README.md b/README.md index c410afb6ca..1d84b9b6e2 100644 --- a/README.md +++ b/README.md @@ -15,50 +15,62 @@ equation (ODE) systems, differential-algebraic equation (DAE) systems, and nonlinear algebraic systems: * ARKODE - for integrating stiff, nonstiff, and multirate ODEs of the form + $$M(t) \\, y' = f_1(t,y) + f_2(t,y), \quad y(t_0) = y_0$$ * CVODE - for integrating stiff and nonstiff ODEs of the form + $$y' = f(t,y), \quad y(t_0) = y_0$$ * CVODES - for integrating and sensitivity analysis (forward and adjoint) of ODEs of the form + $$y' = f(t,y,p), \quad y(t_0) = y_0(p)$$ * IDA - for integrating DAEs of the form + $$F(t,y,y') = 0, \quad y(t_0) = y_0, \quad y'(t_0) = y_0'$$ * IDAS - for integrating and sensitivity analysis (forward and adjoint) of DAEs of the form + $$F(t,y,y',p) = 0, \quad y(t_0) = y_0(p), \quad y'(t_0) = y_0'(p)$$ * KINSOL - for solving nonlinear algebraic systems of the form + $$F(u) = 0 \quad \text{or} \quad G(u) = u$$ ## Installation ## -For installation directions see the [online install guide](https://sundials.readthedocs.io/en/latest/Install_link.html), -the installation chapter in any of the package user guides, or INSTALL_GUIDE.pdf. +For installation directions, see the [getting started](https://sundials.readthedocs.io/en/latest/sundials/index.html#getting-started) +section in the online documentation. In the [released tarballs](https://github.com/LLNL/sundials/releases), +installation directions are also available in `INSTALL_GUIDE.pdf` and the +installation chapter of the user guides in the `doc` directory. Warning to users who receive more than one of the individual packages at -different times: Mixing old and new versions of SUNDIALS may fail. To avoid -such failures, obtain all desired package at the same time. +different times: Mixing old and new versions of SUNDIALS may fail. To avoid such +failures, obtain all desired package at the same time. ## Support ## -Full user guides for all of the SUNDIALS packages are available [online](https://sundials.readthedocs.io) -and in the [doc](./doc) directory. Additionally, the [doc](./doc) directory -contains documentation for the package example programs. +Full user guides for all of the SUNDIALS packages are available [online](https://sundials.readthedocs.io). +In the [released tarballs](https://github.com/LLNL/sundials/releases), the `doc` +directory includes PDFs of the user guides and documentation for the example +programs. The example program documentation PDFs are also available on the +[releases page](https://github.com/LLNL/sundials/releases). For information on recent changes to SUNDIALS see the [CHANGELOG](./CHANGELOG.md) or the introduction chapter of any package user guide. A list of Frequently Asked Questions on build and installation procedures as -well as common usage issues is available on the SUNDIALS [FAQ](https://computing.llnl.gov/projects/sundials/faq). -For dealing with systems with unphysical solutions or discontinuities see the -SUNDIALS [usage notes](https://computing.llnl.gov/projects/sundials/usage-notes). +well as common usage issues is available on the SUNDIALS +[FAQ](https://computing.llnl.gov/projects/sundials/faq). For dealing with +systems with nonphysical solutions or discontinuities see the SUNDIALS +[usage notes](https://computing.llnl.gov/projects/sundials/usage-notes). -If you have a question not covered in the FAQ or usage notes, please submit -your question to the SUNDIALS [mailing list](https://computing.llnl.gov/projects/sundials/mailing-list). +If you have a question not covered in the FAQ or usage notes, please submit your +question as a [GitHub issue](https://github.com/LLNL/sundials/issues) or to the +SUNDIALS [mailing list](https://computing.llnl.gov/projects/sundials/mailing-list). ## Contributing ## @@ -76,14 +88,15 @@ any publications reporting work done using SUNDIALS packages. The SUNDIALS library has been developed over many years by a number of contributors. The current SUNDIALS team consists of Cody J. Balos, -David J. Gardner, Alan C. Hindmarsh, Daniel R. Reynolds, and Carol S. Woodward. -We thank Radu Serban for significant and critical past contributions. +David J. Gardner, Alan C. Hindmarsh, Daniel R. Reynolds, Steven B. Roberts, and +Carol S. Woodward. We thank Radu Serban for significant and critical past +contributions. Other contributors to SUNDIALS include: James Almgren-Bell, Lawrence E. Banks, Peter N. Brown, George Byrne, Rujeko Chinomona, Scott D. Cohen, Aaron Collier, Keith E. Grant, Steven L. Lee, Shelby L. Lockhart, John Loffeld, Daniel McGreer, -Yu Pan, Slaven Peles, Cosmin Petra, Steven B. Roberts, H. Hunter Schwartz, -Jean M. Sexton, Dan Shumaker, Steve G. Smith, Shahbaj Sohal, Allan G. Taylor, +Yu Pan, Slaven Peles, Cosmin Petra, H. Hunter Schwartz, Jean M. Sexton, +Dan Shumaker, Steve G. Smith, Shahbaj Sohal, Allan G. Taylor, Hilari C. Tiedeman, Chris White, Ting Yan, and Ulrike M. Yang. ## License ## @@ -93,7 +106,7 @@ and [NOTICE](./NOTICE) files for details. All new contributions must be made under the BSD 3-clause license. **Please Note** If you are using SUNDIALS with any third party libraries linked -in (e.g., LAPACK, KLU, SuperLU_MT, PETSc, or *hypre*), be sure to review the +in (e.g., LAPACK, KLU, SuperLU_MT, PETSc, *hypre*, etc.), be sure to review the respective license of the package as that license may have more restrictive terms than the SUNDIALS license. diff --git a/benchmarks/advection_reaction_3D/kokkos/ParallelGrid.hpp b/benchmarks/advection_reaction_3D/kokkos/ParallelGrid.hpp index 7bbf8743a7..78fafd71ad 100644 --- a/benchmarks/advection_reaction_3D/kokkos/ParallelGrid.hpp +++ b/benchmarks/advection_reaction_3D/kokkos/ParallelGrid.hpp @@ -72,7 +72,7 @@ class ParallelGrid public: // Constructor that creates a new ParallelGrid object. // [in] - the memory helper to use for allocating the MPI buffers - // [in,out] comm - on input, the overal MPI communicator, on output, the cartesian communicator + // [in,out] comm - on input, the overall MPI communicator, on output, the cartesian communicator // [in] a[] - an array of length 3 which defines the domain [a,b] // [in] b[] - an array of length 3 which defines the domain [a,b] // [in] npts[] - an array of length 3 which defines the number of mesh points in each dimension @@ -563,7 +563,7 @@ class ParallelGrid GLOBALINT nx, ny, nz; /* number of intervals globally */ int nxl, nyl, nzl; /* number of intervals locally */ - int npx, npy, npz; /* numner of processes */ + int npx, npy, npz; /* number of processes */ sunrealtype dx, dy, dz; /* mesh spacing */ sunrealtype ax, ay, az; /* domain in [a, b] */ sunrealtype bx, by, bz; diff --git a/benchmarks/advection_reaction_3D/kokkos/arkode_driver.cpp b/benchmarks/advection_reaction_3D/kokkos/arkode_driver.cpp index 2001c2736a..4f606bd7bf 100644 --- a/benchmarks/advection_reaction_3D/kokkos/arkode_driver.cpp +++ b/benchmarks/advection_reaction_3D/kokkos/arkode_driver.cpp @@ -33,7 +33,7 @@ typedef struct SUNNonlinearSolver local_nls; }* TaskLocalNewton_Content; -/* Content accessor macors */ +/* Content accessor macros */ #define GET_NLS_CONTENT(NLS) ((TaskLocalNewton_Content)(NLS->content)) #define LOCAL_NLS(NLS) (GET_NLS_CONTENT(NLS)->local_nls) diff --git a/benchmarks/advection_reaction_3D/kokkos/check_retval.h b/benchmarks/advection_reaction_3D/kokkos/check_retval.h index b72575c517..a64f816976 100644 --- a/benchmarks/advection_reaction_3D/kokkos/check_retval.h +++ b/benchmarks/advection_reaction_3D/kokkos/check_retval.h @@ -23,7 +23,7 @@ * opt == 0 means the function allocates memory and returns a * pointer so check if a NULL pointer was returned * opt == 1 means the function returns an integer where a - * value < 0 indicates an error occured + * value < 0 indicates an error occurred * --------------------------------------------------------------*/ static int check_retval(void* returnvalue, const char* funcname, int opt, int myid) { diff --git a/benchmarks/advection_reaction_3D/kokkos/rhs3D.hpp b/benchmarks/advection_reaction_3D/kokkos/rhs3D.hpp index 0dee917835..ea714ecaeb 100644 --- a/benchmarks/advection_reaction_3D/kokkos/rhs3D.hpp +++ b/benchmarks/advection_reaction_3D/kokkos/rhs3D.hpp @@ -23,7 +23,7 @@ * --------------------------------------------------------------*/ /* Compute the advection term f(t,y) = -c (grad * y). This is done using - upwind 1st order finite differences. At present, only periodic boudary + upwind 1st order finite differences. At present, only periodic boundary conditions are supported, which are handled via MPI's Cartesian communicator (even for serial runs). */ static int Advection(sunrealtype t, N_Vector y, N_Vector ydot, void* user_data) diff --git a/benchmarks/advection_reaction_3D/raja/ParallelGrid.hpp b/benchmarks/advection_reaction_3D/raja/ParallelGrid.hpp index e818194047..f234aa089a 100644 --- a/benchmarks/advection_reaction_3D/raja/ParallelGrid.hpp +++ b/benchmarks/advection_reaction_3D/raja/ParallelGrid.hpp @@ -45,7 +45,7 @@ class ParallelGrid public: // Constructor that creates a new ParallelGrid object. // [in] - the memory helper to use for allocating the MPI buffers - // [in,out] comm - on input, the overal MPI communicator, on output, the cartesian communicator + // [in,out] comm - on input, the overall MPI communicator, on output, the cartesian communicator // [in] a[] - an array of length 3 which defines the domain [a,b] // [in] b[] - an array of length 3 which defines the domain [a,b] // [in] npts[] - an array of length 3 which defines the number of mesh points in each dimension @@ -508,7 +508,7 @@ class ParallelGrid GLOBALINT nx, ny, nz; /* number of intervals globally */ int nxl, nyl, nzl; /* number of intervals locally */ - int npx, npy, npz; /* numner of processes */ + int npx, npy, npz; /* number of processes */ REAL dx, dy, dz; /* mesh spacing */ REAL ax, ay, az; /* domain in [a, b] */ REAL bx, by, bz; diff --git a/benchmarks/advection_reaction_3D/raja/advection_reaction_3D.hpp b/benchmarks/advection_reaction_3D/raja/advection_reaction_3D.hpp index 8499be6f0b..2caa282af9 100644 --- a/benchmarks/advection_reaction_3D/raja/advection_reaction_3D.hpp +++ b/benchmarks/advection_reaction_3D/raja/advection_reaction_3D.hpp @@ -89,7 +89,7 @@ struct UserData N_Vector vmask; N_Vector wmask; - /* problem paramaters */ + /* problem parameters */ sunrealtype xmax; /* maximum x value */ sunrealtype A; /* concentration of species A */ sunrealtype B; /* w source rate */ diff --git a/benchmarks/advection_reaction_3D/raja/arkode_driver.cpp b/benchmarks/advection_reaction_3D/raja/arkode_driver.cpp index 49dcc6d8cf..420c9d63c9 100644 --- a/benchmarks/advection_reaction_3D/raja/arkode_driver.cpp +++ b/benchmarks/advection_reaction_3D/raja/arkode_driver.cpp @@ -33,7 +33,7 @@ typedef struct SUNNonlinearSolver local_nls; }* TaskLocalNewton_Content; -/* Content accessor macors */ +/* Content accessor macros */ #define GET_NLS_CONTENT(NLS) ((TaskLocalNewton_Content)(NLS->content)) #define LOCAL_NLS(NLS) (GET_NLS_CONTENT(NLS)->local_nls) diff --git a/benchmarks/advection_reaction_3D/raja/check_retval.h b/benchmarks/advection_reaction_3D/raja/check_retval.h index b72575c517..a64f816976 100644 --- a/benchmarks/advection_reaction_3D/raja/check_retval.h +++ b/benchmarks/advection_reaction_3D/raja/check_retval.h @@ -23,7 +23,7 @@ * opt == 0 means the function allocates memory and returns a * pointer so check if a NULL pointer was returned * opt == 1 means the function returns an integer where a - * value < 0 indicates an error occured + * value < 0 indicates an error occurred * --------------------------------------------------------------*/ static int check_retval(void* returnvalue, const char* funcname, int opt, int myid) { diff --git a/benchmarks/diffusion_2D/diffusion_2D.cpp b/benchmarks/diffusion_2D/diffusion_2D.cpp index bd18cf1dfb..2a64400938 100644 --- a/benchmarks/diffusion_2D/diffusion_2D.cpp +++ b/benchmarks/diffusion_2D/diffusion_2D.cpp @@ -11,7 +11,7 @@ * SPDX-License-Identifier: BSD-3-Clause * SUNDIALS Copyright End * ----------------------------------------------------------------------------- - * Shared implementaiton file for 2D diffusion benchmark problem + * Shared implementation file for 2D diffusion benchmark problem * ---------------------------------------------------------------------------*/ #include "diffusion_2D.hpp" diff --git a/benchmarks/diffusion_2D/diffusion_2D.hpp b/benchmarks/diffusion_2D/diffusion_2D.hpp index 1ebb3394aa..a27c004e63 100644 --- a/benchmarks/diffusion_2D/diffusion_2D.hpp +++ b/benchmarks/diffusion_2D/diffusion_2D.hpp @@ -159,7 +159,7 @@ struct UserData sunrealtype* Ssend = NULL; sunrealtype* Nsend = NULL; - // Send requests for neighor exchange + // Send requests for neighbor exchange MPI_Request reqSW; MPI_Request reqSE; MPI_Request reqSS; @@ -192,7 +192,7 @@ struct UserData struct UserOutput { - // Ouput variables + // Output variables int output = 1; // 0 = no output, 1 = stats output, 2 = output to disk int nout = 20; // number of output times N_Vector error = NULL; // error vector diff --git a/benchmarks/diffusion_2D/main_arkode.cpp b/benchmarks/diffusion_2D/main_arkode.cpp index c35bf9e9c7..39c6274a6e 100644 --- a/benchmarks/diffusion_2D/main_arkode.cpp +++ b/benchmarks/diffusion_2D/main_arkode.cpp @@ -329,7 +329,7 @@ int main(int argc, char* argv[]) sunrealtype dTout = udata.tf / uout.nout; sunrealtype tout = dTout; - // Inital output + // Initial output flag = uout.open(&udata); if (check_flag(&flag, "UserOutput::open", 1)) { return 1; } @@ -524,7 +524,7 @@ void UserOptions::help() cout << endl; cout << "Integrator command line options:" << endl; cout << " --rtol : relative tolerance" << endl; - cout << " --atol : absoltue tolerance" << endl; + cout << " --atol : absolute tolerance" << endl; cout << " --nonlinear : disable linearly implicit flag" << endl; cout << " --order : method order" << endl; cout << " --fixedstep : used fixed step size" << endl; diff --git a/benchmarks/diffusion_2D/main_cvode.cpp b/benchmarks/diffusion_2D/main_cvode.cpp index 71172e4ce9..47420cdc98 100644 --- a/benchmarks/diffusion_2D/main_cvode.cpp +++ b/benchmarks/diffusion_2D/main_cvode.cpp @@ -310,7 +310,7 @@ int main(int argc, char* argv[]) sunrealtype dTout = udata.tf / uout.nout; sunrealtype tout = dTout; - // Inital output + // Initial output flag = uout.open(&udata); if (check_flag(&flag, "UserOutput::open", 1)) { return 1; } @@ -479,7 +479,7 @@ void UserOptions::help() cout << endl; cout << "Integrator command line options:" << endl; cout << " --rtol : relative tolerance" << endl; - cout << " --atol : absoltue tolerance" << endl; + cout << " --atol : absolute tolerance" << endl; cout << " --ls : linear solver" << endl; cout << " --lsinfo : output residual history" << endl; cout << " --liniters : max number of iterations" << endl; diff --git a/benchmarks/diffusion_2D/main_ida.cpp b/benchmarks/diffusion_2D/main_ida.cpp index 515256ddd9..ccd86c7ad5 100644 --- a/benchmarks/diffusion_2D/main_ida.cpp +++ b/benchmarks/diffusion_2D/main_ida.cpp @@ -305,7 +305,7 @@ int main(int argc, char* argv[]) sunrealtype dTout = udata.tf / uout.nout; sunrealtype tout = dTout; - // Inital output + // Initial output flag = uout.open(&udata); if (check_flag(&flag, "UserOutput::open", 1)) { return 1; } @@ -460,7 +460,7 @@ void UserOptions::help() cout << endl; cout << "Integrator command line options:" << endl; cout << " --rtol : relative tolerance" << endl; - cout << " --atol : absoltue tolerance" << endl; + cout << " --atol : absolute tolerance" << endl; cout << " --ls : linear solver" << endl; cout << " --liniters : max number of iterations" << endl; cout << " --epslin : linear tolerance factor" << endl; diff --git a/benchmarks/nvector/plot_nvector_performance_results.py b/benchmarks/nvector/plot_nvector_performance_results.py index 55bb5ae32e..c5e9f69301 100755 --- a/benchmarks/nvector/plot_nvector_performance_results.py +++ b/benchmarks/nvector/plot_nvector_performance_results.py @@ -15,7 +15,7 @@ # This script plots the output from test_nector_performance_* and assumes: # 1. vector lengths are powers of two starting from 0, and # 2. output files are named: output_nelem_nvec_nsum_ntest_timing.txt -# where nelem is the number of elements in the vector, nvec is the nuber of +# where nelem is the number of elements in the vector, nvec is the number of # vectors, nsum is the number of sums, ntest is the number of tests, and timing # indicates if timing was enabled. # ----------------------------------------------------------------------------- diff --git a/benchmarks/nvector/plot_nvector_performance_speedup.py b/benchmarks/nvector/plot_nvector_performance_speedup.py index 623d716c01..baaaf43682 100755 --- a/benchmarks/nvector/plot_nvector_performance_speedup.py +++ b/benchmarks/nvector/plot_nvector_performance_speedup.py @@ -15,7 +15,7 @@ # This script plots the output from test_nector_performance_* and assumes: # 1. vector lengths are powers of two starting from 0, and # 2. output files are named: output_nelem_nvec_nsum_ntest_timing.txt -# where nelem is the number of elements in the vector, nvec is the nuber of +# where nelem is the number of elements in the vector, nvec is the number of # vectors, nsum is the number of sums, ntest is the number of tests, and timing # indicates if timing was enabled. # ----------------------------------------------------------------------------- diff --git a/benchmarks/nvector/sycl/test_nvector_performance_sycl.cpp b/benchmarks/nvector/sycl/test_nvector_performance_sycl.cpp index 0691d036e4..52b12e966f 100644 --- a/benchmarks/nvector/sycl/test_nvector_performance_sycl.cpp +++ b/benchmarks/nvector/sycl/test_nvector_performance_sycl.cpp @@ -118,7 +118,7 @@ int main(int argc, char* argv[]) ? "Yes" : "No") << std::endl; - std::cout << " suports usm shared allocations? " + std::cout << " supports usm shared allocations? " << (dev.get_info<::sycl::info::device::usm_shared_allocations>() ? "Yes" : "No") diff --git a/benchmarks/nvector/test_nvector_performance.h b/benchmarks/nvector/test_nvector_performance.h index 23af102a8e..74528b749d 100644 --- a/benchmarks/nvector/test_nvector_performance.h +++ b/benchmarks/nvector/test_nvector_performance.h @@ -17,7 +17,7 @@ #include -/* define constatnts */ +/* define constants */ #define NEG_ONE SUN_RCONST(-1.0) #define ZERO SUN_RCONST(0.0) #define ONE SUN_RCONST(1.0) diff --git a/cmake/SundialsBuildOptionsPost.cmake b/cmake/SundialsBuildOptionsPost.cmake index 2bf6acd14f..e914eefd1f 100644 --- a/cmake/SundialsBuildOptionsPost.cmake +++ b/cmake/SundialsBuildOptionsPost.cmake @@ -11,7 +11,7 @@ # SPDX-License-Identifier: BSD-3-Clause # SUNDIALS Copyright End # --------------------------------------------------------------- -# SUNDIALS build options that are interepreted after all other +# SUNDIALS build options that are interpreted after all other # CMake configuration. # --------------------------------------------------------------- diff --git a/cmake/SundialsBuildOptionsPre.cmake b/cmake/SundialsBuildOptionsPre.cmake index 048137ff2d..96e17ea087 100644 --- a/cmake/SundialsBuildOptionsPre.cmake +++ b/cmake/SundialsBuildOptionsPre.cmake @@ -11,7 +11,7 @@ # SPDX-License-Identifier: BSD-3-Clause # SUNDIALS Copyright End # --------------------------------------------------------------- -# SUNDIALS build options that are interepreted prior to any +# SUNDIALS build options that are interpreted prior to any # other CMake configuration. # --------------------------------------------------------------- diff --git a/cmake/SundialsDeprecated.cmake b/cmake/SundialsDeprecated.cmake index a426ac1814..017e867c73 100644 --- a/cmake/SundialsDeprecated.cmake +++ b/cmake/SundialsDeprecated.cmake @@ -180,8 +180,8 @@ endif() # if(DEFINED CUDA_ARCH) - print_warning("The CMake option CUDA_ARCH is deprecated. " - "Use CMAKE_CUDA_ARCHITECTURES instead.") + message(DEPRECATION "The CMake option CUDA_ARCH is deprecated. " + "Use CMAKE_CUDA_ARCHITECTURES instead.") # convert sm_** to just ** string(REGEX MATCH "[0-9]+" arch_name "${CUDA_ARCH}") set(CMAKE_CUDA_ARCHITECTURES diff --git a/cmake/SundialsSetupCXX.cmake b/cmake/SundialsSetupCXX.cmake index f4967f16cc..187e597d40 100644 --- a/cmake/SundialsSetupCXX.cmake +++ b/cmake/SundialsSetupCXX.cmake @@ -41,7 +41,7 @@ set(DOCSTR "Enable C++ compiler specific extensions") sundials_option(CMAKE_CXX_EXTENSIONS BOOL "${DOCSTR}" ON) message(STATUS "C++ extensions set to ${CMAKE_CXX_EXTENSIONS}") -# SYCL requries C++17 +# SYCL requires C++17 if(ENABLE_SYCL AND (CMAKE_CXX_STANDARD LESS "17")) message(SEND_ERROR "CMAKE_CXX_STANDARD must be >= 17 because ENABLE_SYCL=ON") endif() diff --git a/cmake/SundialsSetupCompilers.cmake b/cmake/SundialsSetupCompilers.cmake index 797c743a3f..aad26bdaf7 100644 --- a/cmake/SundialsSetupCompilers.cmake +++ b/cmake/SundialsSetupCompilers.cmake @@ -21,12 +21,12 @@ include(SundialsIndexSize) # =============================================================== -# Platform specifc settings +# Platform specific settings # =============================================================== if(WIN32) # Under Windows, add compiler directive to inhibit warnings about use of - # unsecure functions. + # insecure functions. add_compile_definitions(_CRT_SECURE_NO_WARNINGS) # Under Windows, we need to have dll and exe files in the same directory to diff --git a/cmake/SundialsSetupCuda.cmake b/cmake/SundialsSetupCuda.cmake index 8a0703336b..ef01d0faba 100644 --- a/cmake/SundialsSetupCuda.cmake +++ b/cmake/SundialsSetupCuda.cmake @@ -11,7 +11,7 @@ # SPDX-License-Identifier: BSD-3-Clause # SUNDIALS Copyright End # --------------------------------------------------------------- -# Setup the CUDA languge and CUDA libraries. +# Setup the CUDA language and CUDA libraries. # --------------------------------------------------------------- # =============================================================== diff --git a/cmake/tpl/FindMAGMA.cmake b/cmake/tpl/FindMAGMA.cmake index 0d71560b72..f28780129f 100644 --- a/cmake/tpl/FindMAGMA.cmake +++ b/cmake/tpl/FindMAGMA.cmake @@ -97,7 +97,7 @@ if(MAGMA_LIBRARY AND MAGMA_INCLUDE_DIR) # Check if we need to find cusparse or cublas if(SUNDIALS_MAGMA_BACKENDS MATCHES "CUDA") # Replace cublas, cusparse with the CMake targets because the library - # path in the magma pkgconfig is not reliable. Sepcifically, the path + # path in the magma pkgconfig is not reliable. Specifically, the path # is wrong on systems like Perlmutter where the NVIDIA HPC SDK is # used. if(lib STREQUAL "-lcublas") diff --git a/cmake/tpl/SundialsHypre.cmake b/cmake/tpl/SundialsHypre.cmake index 9d880d2562..12d7b550b1 100644 --- a/cmake/tpl/SundialsHypre.cmake +++ b/cmake/tpl/SundialsHypre.cmake @@ -37,12 +37,12 @@ endif() # ----------------------------------------------------------------------------- if(ENABLE_HYPRE) - # Using hypre requres building with MPI enabled + # Using hypre requires building with MPI enabled if(NOT ENABLE_MPI) message( FATAL_ERROR "MPI is required for hypre support. Set ENABLE_MPI to ON.") endif() - # Using hypre requres C99 or newer + # Using hypre requires C99 or newer if(CMAKE_C_STANDARD STREQUAL "90") message(SEND_ERROR "CMAKE_C_STANDARD must be >= c99 with ENABLE_HYPRE=ON") endif() diff --git a/cmake/tpl/SundialsLapack.cmake b/cmake/tpl/SundialsLapack.cmake index 74261bb469..ecc3e4475b 100644 --- a/cmake/tpl/SundialsLapack.cmake +++ b/cmake/tpl/SundialsLapack.cmake @@ -11,7 +11,7 @@ # SPDX-License-Identifier: BSD-3-Clause # SUNDIALS Copyright End # ----------------------------------------------------------------------------- -# Module to find and setup LAPACK/BLAS corrrectly. +# Module to find and setup LAPACK/BLAS correctly. # Created from the SundialsTPL.cmake template. # All SUNDIALS modules that find and setup a TPL must: # @@ -160,8 +160,8 @@ if(NEED_FORTRAN_NAME_MANGLING) list(LENGTH options imax) set(iopt 0) - # We will attempt to sucessfully generate the "ctest1" executable as long as - # there still are entries in the "options" list + # We will attempt to successfully generate the "ctest1" executable as long + # as there still are entries in the "options" list while(${iopt} LESS ${imax}) # Get the current list entry (current scheme) list(GET options ${iopt} opt) diff --git a/doc/arkode/examples/source/c_serial.rst b/doc/arkode/examples/source/c_serial.rst index 4a9fce62cf..81d8b6b248 100644 --- a/doc/arkode/examples/source/c_serial.rst +++ b/doc/arkode/examples/source/c_serial.rst @@ -326,7 +326,7 @@ The problem implements the following testing scenario: :math:`u_0=1.2`, Numerical method ---------------- -This program solves the problem with the default thrid order method. +This program solves the problem with the default third order method. The problem is run using a fixed slow step size :math:`hs=0.025` and fast step size :math:`0.001`. @@ -854,7 +854,7 @@ is the product of two matrices: only a subset of the :math:`3\times3` blocks). Four different runs are made for this problem. The product -preconditoner is applied on the left and on the right. In each case, +preconditioner is applied on the left and on the right. In each case, both the modified and classical Gram-Schmidt orthogonalization options are tested. In the series of runs, ``ARKodeInit``, ``SUNSPGMR``, ``ARKSpilsSetLinearSolver``, ``SUNSPGMRSetGSType``, diff --git a/doc/arkode/examples/source/conf.py b/doc/arkode/examples/source/conf.py index 826730c1f7..703861d658 100644 --- a/doc/arkode/examples/source/conf.py +++ b/doc/arkode/examples/source/conf.py @@ -442,7 +442,7 @@ texinfo_documents = [ ('index', 'ARKODE_example', u'ARKODE Example Documentation', u'Daniel R. Reynolds', 'ARKODE_example', - 'Example programs for the ARKODE time integration package for multi-rate systems of ordinary differntial equations.', + 'Example programs for the ARKODE time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/arkode/guide/source/Butcher.rst b/doc/arkode/guide/source/Butcher.rst index 678510cd4f..0b7e401a56 100644 --- a/doc/arkode/guide/source/Butcher.rst +++ b/doc/arkode/guide/source/Butcher.rst @@ -915,7 +915,7 @@ or :c:func:`ARKodeButcherTable_LoadERK`. Accessible via the string ``"ARKODE_VERNER_8_5_6"`` to :c:func:`ARKStepSetTableName`, :c:func:`ERKStepSetTableName` or :c:func:`ARKodeButcherTable_LoadERKByName`. -This is the default 6th order explicit method (from :cite:p:`Ver:78`). +This is the default 6th order explicit method (from :cite:p:`HEJ:76`). .. math:: diff --git a/doc/arkode/guide/source/Mathematics.rst b/doc/arkode/guide/source/Mathematics.rst index ddbd7c4122..9d9835c53d 100644 --- a/doc/arkode/guide/source/Mathematics.rst +++ b/doc/arkode/guide/source/Mathematics.rst @@ -548,7 +548,7 @@ can be ignored). Optionally, a different algorithm leveraging compensated summation can be used that is more robust to roundoff error at the expense of 2 extra vector operations per stage and an additional 5 per time step. It also requires one extra vector to -be stored. However, it is signficantly more robust to roundoff error accumulation +be stored. However, it is significantly more robust to roundoff error accumulation :cite:p:`Sof:02`. When compensated summation is enabled, the following incremental form is used to compute a time step: diff --git a/doc/arkode/guide/source/Usage/ARKStep/User_callable.rst b/doc/arkode/guide/source/Usage/ARKStep/User_callable.rst index a6c07ac5e6..5a21f7ea15 100644 --- a/doc/arkode/guide/source/Usage/ARKStep/User_callable.rst +++ b/doc/arkode/guide/source/Usage/ARKStep/User_callable.rst @@ -841,7 +841,7 @@ Optional inputs for ARKStep The default is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for - ``tstop`` is disabled (and can be reenabled only though a new call to + ``tstop`` is disabled (and can be re-enabled only though a new call to :c:func:`ARKStepSetStopTime`). A stop time not reached before a call to :c:func:`ARKStepReInit` or @@ -886,7 +886,7 @@ Optional inputs for ARKStep * *ARK_MEM_NULL* if the ARKStep memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`ARKStepSetStopTime`. .. versionadded:: 5.5.1 diff --git a/doc/arkode/guide/source/Usage/ARKStep/XBraid.rst b/doc/arkode/guide/source/Usage/ARKStep/XBraid.rst index 665610283a..8245f0efc9 100644 --- a/doc/arkode/guide/source/Usage/ARKStep/XBraid.rst +++ b/doc/arkode/guide/source/Usage/ARKStep/XBraid.rst @@ -79,9 +79,9 @@ operations (e.g., computing vector sums or norms) as well as functions to initialize the problem state, access the current solution, and take a time step. The ARKBraid interface, built on the SUNBraidApp and SUNBraidVector structures, -provides all the functionaly needed combine ARKODE and XBraid for +provides all the functionality needed combine ARKODE and XBraid for parallel-in-time integration. As such, only a minimal number of changes are -necessary to update an exsting code that uses ARKODE to also use XBraid. +necessary to update an existing code that uses ARKODE to also use XBraid. @@ -123,7 +123,7 @@ Here, the SUNBraidOps structure is defined as typedef struct _SUNBraidOps *SUNBraidOps; The generic SUNBraidApp defines and implements the generic operations acting on -a SUNBraidApp obejct. These generic functions are nothing but wrappers to access +a SUNBraidApp object. These generic functions are nothing but wrappers to access the specific implementation through the object's operations structure. To illustrate this point we show below the implementation of the :c:func:`SUNBraidApp_GetVecTmpl()` function: @@ -876,7 +876,7 @@ A skeleton of the user's main program with XBraid In addition to the header files required for the integration of the ODE problem (see the section :numref:`ARKODE.Usage.Headers`), to use the ARKBraid -interace, the user's program must include the header file +interface, the user's program must include the header file ``arkode/arkode_xbraid.h`` which declares the needed function prototypes. The following is a skeleton of the user's main program (or calling program) for @@ -965,7 +965,7 @@ Advanced ARKBraid Utility Functions This section describes utility functions utilized in the ARKODE + XBraid interfacing. These functions are used internally by the above ARKBraid interface functions but are exposed to the user to assist in advanced usage of -ARKODE and XBraid that requries defining a custom SUNBraidApp implementation. +ARKODE and XBraid that requires defining a custom SUNBraidApp implementation. diff --git a/doc/arkode/guide/source/Usage/ERKStep/User_callable.rst b/doc/arkode/guide/source/Usage/ERKStep/User_callable.rst index 017aa17110..5bbb3e1f63 100644 --- a/doc/arkode/guide/source/Usage/ERKStep/User_callable.rst +++ b/doc/arkode/guide/source/Usage/ERKStep/User_callable.rst @@ -625,7 +625,7 @@ Optional inputs for ERKStep The default is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for - ``tstop`` is disabled (and can be reenabled only though a new call to + ``tstop`` is disabled (and can be re-enabled only though a new call to :c:func:`ERKStepSetStopTime`). A stop time not reached before a call to :c:func:`ERKStepReInit` or @@ -672,7 +672,7 @@ Optional inputs for ERKStep * *ARK_MEM_NULL* if the ERKStep memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`ERKStepSetStopTime`. .. versionadded:: 5.5.1 diff --git a/doc/arkode/guide/source/Usage/MRIStep/MRIStepCoupling.rst b/doc/arkode/guide/source/Usage/MRIStep/MRIStepCoupling.rst index 88fb32a748..53d5a8c7d5 100644 --- a/doc/arkode/guide/source/Usage/MRIStep/MRIStepCoupling.rst +++ b/doc/arkode/guide/source/Usage/MRIStep/MRIStepCoupling.rst @@ -24,7 +24,7 @@ supply a custom set of slow-to-fast time scale coupling coefficients by constructing a coupling table and attaching it with :c:func:`MRIStepSetCoupling`. The MRI coupling tables are stored in an :c:func:`MRIStepCoupling` object which is a pointer to a -:c:struct:`MRIStepCouplingMem` strucutre: +:c:struct:`MRIStepCouplingMem` structure: .. c:type:: MRIStepCouplingMem *MRIStepCoupling diff --git a/doc/arkode/guide/source/Usage/MRIStep/User_callable.rst b/doc/arkode/guide/source/Usage/MRIStep/User_callable.rst index 95f13fb608..24e8497c04 100644 --- a/doc/arkode/guide/source/Usage/MRIStep/User_callable.rst +++ b/doc/arkode/guide/source/Usage/MRIStep/User_callable.rst @@ -303,7 +303,7 @@ Rootfinding initialization function *nrtfn = 0*. Rootfinding is only supported for the slow (outer) integrator and should not - be actived for the fast (inner) integrator. + be activated for the fast (inner) integrator. .. deprecated:: 6.1.0 @@ -676,7 +676,7 @@ Optional inputs for MRIStep The default is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for - ``tstop`` is disabled (and can be reenabled only though a new call to + ``tstop`` is disabled (and can be re-enabled only though a new call to :c:func:`MRIStepSetStopTime`). A stop time not reached before a call to :c:func:`MRIStepReInit` or @@ -723,7 +723,7 @@ Optional inputs for MRIStep * *ARK_MEM_NULL* if the MRIStep memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`MRIStepSetStopTime`. .. versionadded:: 5.5.1 diff --git a/doc/arkode/guide/source/Usage/SPRKStep/User_callable.rst b/doc/arkode/guide/source/Usage/SPRKStep/User_callable.rst index d8f4dec8f9..14d45133d1 100644 --- a/doc/arkode/guide/source/Usage/SPRKStep/User_callable.rst +++ b/doc/arkode/guide/source/Usage/SPRKStep/User_callable.rst @@ -336,7 +336,7 @@ Optional inputs for SPRKStep The default is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for - ``tstop`` is disabled (and can be reenabled only though a new call to + ``tstop`` is disabled (and can be re-enabled only though a new call to :c:func:`SPRKStepSetStopTime`). A stop time not reached before a call to :c:func:`SPRKStepReInit` or @@ -359,7 +359,7 @@ Optional inputs for SPRKStep Disables the stop time set with :c:func:`SPRKStepSetStopTime`. - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`SPRKStepSetStopTime`. :param arkode_mem: pointer to the SPRKStep memory block. @@ -486,7 +486,7 @@ Optional inputs for IVP method selection This increases the computational cost by 2 extra vector operations per stage and an additional 5 per time step. It also requires one extra vector to be - stored. However, it is signficantly more robust to roundoff error + stored. However, it is significantly more robust to roundoff error accumulation. :param arkode_mem: pointer to the SPRKStep memory block. diff --git a/doc/arkode/guide/source/Usage/User_callable.rst b/doc/arkode/guide/source/Usage/User_callable.rst index fd9261eaa3..fd9b572382 100644 --- a/doc/arkode/guide/source/Usage/User_callable.rst +++ b/doc/arkode/guide/source/Usage/User_callable.rst @@ -1235,7 +1235,7 @@ Set max number of constraint failures :c:func:`ARKodeSetMaxNumConstr The default is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for - ``tstop`` is disabled (and can be reenabled only though a new call to + ``tstop`` is disabled (and can be re-enabled only though a new call to :c:func:`ARKodeSetStopTime`). A stop time not reached before a call to ``*StepReInit`` or @@ -1271,7 +1271,7 @@ Set max number of constraint failures :c:func:`ARKodeSetMaxNumConstr .. note:: - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`ARKodeSetStopTime`. .. versionadded:: 6.1.0 diff --git a/doc/arkode/guide/source/conf.py b/doc/arkode/guide/source/conf.py index a0817d416f..2975c7bd36 100644 --- a/doc/arkode/guide/source/conf.py +++ b/doc/arkode/guide/source/conf.py @@ -290,7 +290,7 @@ texinfo_documents = [ ('index', 'ARKODE', u'ARKODE Documentation', u'Daniel R. Reynolds, David J. Gardner, Carol S. Woodward, Rujeko Chinomona, and Cody J. Balos', 'ARKODE', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/arkode/guide/source/sunlinsol/ARKODE_interface.rst b/doc/arkode/guide/source/sunlinsol/ARKODE_interface.rst index ea807ed00c..ab90aae357 100644 --- a/doc/arkode/guide/source/sunlinsol/ARKODE_interface.rst +++ b/doc/arkode/guide/source/sunlinsol/ARKODE_interface.rst @@ -184,7 +184,7 @@ In certain instances, users may wish to provide a custom SUNLinSol implementation to ARKODE in order to leverage the structure of a problem. While the "standard" API for these routines is typically sufficient for most users, others may need additional ARKODE-specific information on top of what is -provided. For these purposes, we note the following advanced ouptut functions +provided. For these purposes, we note the following advanced output functions available in ARKStep and MRIStep: diff --git a/doc/arkode/guide/source/sunnonlinsol/ARKODE_interface.rst b/doc/arkode/guide/source/sunnonlinsol/ARKODE_interface.rst index 92046f510c..5d0f0b02f3 100644 --- a/doc/arkode/guide/source/sunnonlinsol/ARKODE_interface.rst +++ b/doc/arkode/guide/source/sunnonlinsol/ARKODE_interface.rst @@ -141,7 +141,7 @@ of user-supplied SUNNonlinSol modules are as follows. This is only compatible with time-stepping modules that support implicit algebraic solvers. - This routine is intended for users who whish to attach a custom + This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn`) or who need access to nonlinear system data to compute the nonlinear system function as part of @@ -150,7 +150,7 @@ of user-supplied SUNNonlinSol modules are as follows. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`ARKodeGetNonlinearSystemData()` **inside** the nonlinear system - function to access the requisite data for evaluting the nonlinear systen + function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` functions supplied by ARKODE (through @@ -259,7 +259,7 @@ of user-supplied SUNNonlinSol modules are as follows. .. note:: - This routine is intended for users who whish to attach a custom + This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn`) or who need access to nonlinear system data to compute the nonlinear system function as part of @@ -268,7 +268,7 @@ of user-supplied SUNNonlinSol modules are as follows. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`ARKStepGetNonlinearSystemData()` **inside** the nonlinear system - function to access the requisite data for evaluting the nonlinear systen + function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` functions supplied by ARKStep (through @@ -362,7 +362,7 @@ of user-supplied SUNNonlinSol modules are as follows. .. note:: - This routine is intended for users who whish to attach a custom + This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn()`) or who need access to nonlinear system data to compute the nonlinear system function as part of @@ -371,7 +371,7 @@ of user-supplied SUNNonlinSol modules are as follows. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`MRIStepGetNonlinearSystemData()` **inside** the nonlinear system - function to access the requisite data for evaluting the nonlinear systen + function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` functions supplied by MRIStep (through diff --git a/doc/cvode/cv_ex_cuda.tex b/doc/cvode/cv_ex_cuda.tex index 26578e73d2..c6a0e0645a 100644 --- a/doc/cvode/cv_ex_cuda.tex +++ b/doc/cvode/cv_ex_cuda.tex @@ -28,7 +28,7 @@ \subsection{An unpreconditioned Krylov example: cvAdvDiff\_kry\_cuda}\label{ss:c model at the device. In the example, model right hand side and Jacobian-vector product are implemented as {\cuda} kernels \id{fKernel} and \id{jtvKernel}, respectively. User provided {\CC} functions \id{f} and \id{jtv}, which are called -directly by {\cvode}, set thread partitioning and launch thier respective +directly by {\cvode}, set thread partitioning and launch their respective {\cuda} kernels. Vector data on the device is accessed using \id{N\_VGetDeviceArrayPointer\_Cuda} function. diff --git a/doc/cvode/cv_ex_intro.tex b/doc/cvode/cv_ex_intro.tex index e761486efd..efd01e2b72 100644 --- a/doc/cvode/cv_ex_intro.tex +++ b/doc/cvode/cv_ex_intro.tex @@ -121,7 +121,7 @@ \section{Introduction}\label{s:ex_intro} interaction terms only, using block-grouping. \newline Four different runs are made for this problem. - The product preconditoner is applied on the left and on the right. + The product preconditioner is applied on the left and on the right. In each case, both the modified and classical Gram-Schmidt options are tested. \item \id{cvHeat2D\_klu} solves a discretized 2D heat equation using diff --git a/doc/cvode/cv_ex_parallel.tex b/doc/cvode/cv_ex_parallel.tex index 146df50eba..d2a5102456 100644 --- a/doc/cvode/cv_ex_parallel.tex +++ b/doc/cvode/cv_ex_parallel.tex @@ -149,7 +149,7 @@ \subsection{A user preconditioner example: cvDiurnal\_kry\_p}\label{ss:cvDiurnal iteration and {\spgmr}. The left preconditioner is the block-diagonal part of the Newton matrix, with $2 \times 2$ blocks, and the corresponding diagonal blocks of the Jacobian are saved each time the -preconditioner is generated, for re-use later under certain conditions. +preconditioner is generated, for reuse later under certain conditions. The organization of the \id{cvDiurnal\_kry\_p} program deserves some comments. The right-hand side routine \id{f} calls two other routines: \id{ucomm}, which diff --git a/doc/cvode/cv_ex_serial.tex b/doc/cvode/cv_ex_serial.tex index 35d62d5f79..4e48db6c25 100644 --- a/doc/cvode/cv_ex_serial.tex +++ b/doc/cvode/cv_ex_serial.tex @@ -79,7 +79,7 @@ \subsection{A dense example: cvRoberts\_dns}\label{ss:cvRoberts} \id{SUNLinearSolver}. The next several lines allocate memory for the \id{y} and \id{abstol} vectors using \id{N\_VNew\_Serial} with a length argument of \id{NEQ} ($= 3$). The -lines following that load the initial values of the dependendent +lines following that load the initial values of the dependent variable vector into \id{y} and the absolute tolerances into \id{abstol} using the \id{Ith} macro. @@ -492,14 +492,14 @@ \subsection{A Krylov example: cvDiurnal\_kry}\label{ss:cvDiurnal} to allocate space for $J_{bd}$, $P$, and the pivot arrays; \id{InitUserData} to load problem constants in the \id{data} block; \id{FreeUserData} to free that block; \id{SetInitialProfiles} to load the initial values in \id{y}; -\id{PrintOutput} to retreive and print selected solution values and +\id{PrintOutput} to retrieve and print selected solution values and statistics; \id{PrintFinalStats} to print statistics; and \id{check\_flag} to check return values for error conditions. The output generated by \id{cvDiurnal\_kry.c} is shown below. Note that the number of preconditioner evaluations, \id{npe}, is much smaller than the number of preconditioner setups, \id{nsetups}, as a result of the -Jacobian re-use scheme. +Jacobian reuse scheme. %% \includeOutput{cvDiurnal\_dns}{../../examples/cvode/serial/cvDiurnal_kry.out} diff --git a/doc/cvode/cv_ex_tests.tex b/doc/cvode/cv_ex_tests.tex index 8b747c2ff9..177da0e766 100644 --- a/doc/cvode/cv_ex_tests.tex +++ b/doc/cvode/cv_ex_tests.tex @@ -94,7 +94,7 @@ \section{Parallel tests}\label{s:ex_tests} grows. This means that the highly portable MPI version of {\cvode}, with an appropriate choice of MPI implementation, is fully competitive with the Cray-specific version using the SHMEM library. While the overall costs do -not prepresent a well-scaled parallel algorithm (because of the +not represent a well-scaled parallel algorithm (because of the preconditioner choice), the cost per function evaluation is quite flat for EPCC and SHMEM, at .033 to .037 (for MPICH it ranges from .044 to .068). diff --git a/doc/cvode/guide/source/Constants.rst b/doc/cvode/guide/source/Constants.rst index bf2a8a40d5..ebb0971921 100644 --- a/doc/cvode/guide/source/Constants.rst +++ b/doc/cvode/guide/source/Constants.rst @@ -84,7 +84,7 @@ the CVODE output constants. +----------------------------+-----+----------------------------------------------------------------------------------------+ | ``CV_FIRST_RHSFUNC_ERR`` | -9 | The right-hand side function failed at the first call. | +----------------------------+-----+----------------------------------------------------------------------------------------+ - | ``CV_REPTD_RHSFUNC_ERR`` | -10 | The right-hand side function had repetead recoverable errors. | + | ``CV_REPTD_RHSFUNC_ERR`` | -10 | The right-hand side function had repeated recoverable errors. | +----------------------------+-----+----------------------------------------------------------------------------------------+ | ``CV_UNREC_RHSFUNC_ERR`` | -11 | The right-hand side function had a recoverable error, but no recovery is possible. | +----------------------------+-----+----------------------------------------------------------------------------------------+ diff --git a/doc/cvode/guide/source/Introduction.rst b/doc/cvode/guide/source/Introduction.rst index 651efba809..ba5bd22a84 100644 --- a/doc/cvode/guide/source/Introduction.rst +++ b/doc/cvode/guide/source/Introduction.rst @@ -47,7 +47,7 @@ and VODPK have been combined in the C-language package CVODE :cite:p:`CoHi:96`. At present, CVODE may utilize a variety of Krylov methods provided -in SUNDIALS that can be used in conjuction with Newton iteration: +in SUNDIALS that can be used in conjunction with Newton iteration: these include the GMRES (Generalized Minimal RESidual) :cite:p:`SaSc:86`, FGMRES (Flexible Generalized Minimum RESidual) :cite:p:`Saa:93`, Bi-CGStab (Bi-Conjugate diff --git a/doc/cvode/guide/source/Usage/index.rst b/doc/cvode/guide/source/Usage/index.rst index 722e20533e..3c56d48587 100644 --- a/doc/cvode/guide/source/Usage/index.rst +++ b/doc/cvode/guide/source/Usage/index.rst @@ -440,7 +440,7 @@ makes no sense (and is overly costly) after ``y[i]`` is below some noise level. ``abstol`` (if scalar) or ``abstol[i]`` (if a vector) needs to be set to that noise level. If the different components have different noise levels, then ``abstol`` should be a vector. See the example ``cvsRoberts_dns`` in the CVODE package, and the discussion of it in the CVODE Examples document -:cite:p:`cvodes_ex`. In that problem, the three components vary betwen 0 and 1, +:cite:p:`cvodes_ex`. In that problem, the three components vary between 0 and 1, and have different noise levels; hence the ``abstol`` vector. It is impossible to give any general advice on ``abstol`` values, because the appropriate noise levels are completely problem-dependent. The user or modeler hopefully has some idea as to what those @@ -764,7 +764,7 @@ rootfinding. In the ``CV_ONE_STEP`` mode, ``tout`` is used only on the first call, and only to get the direction and a rough scale of the independent variable. - If a stop time is enabled (through a call to ``CVodeSetStopTime``), then ``CVode`` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be reenabled only though a new call to ``CVodeSetStopTime``). + If a stop time is enabled (through a call to ``CVodeSetStopTime``), then ``CVode`` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be re-enabled only though a new call to ``CVodeSetStopTime``). All failure return values are negative and so the test ``flag < 0`` will trap all ``CVode`` failures. @@ -909,7 +909,7 @@ Main solver optional input functions **Arguments:** * ``cvode_mem`` -- pointer to the CVODE memory block. - * ``nst`` -- number of successful steps inbetween calls to the monitor function 0 by default; a 0 input will turn off monitoring. + * ``nst`` -- number of successful steps in between calls to the monitor function 0 by default; a 0 input will turn off monitoring. **Return value:** * ``CV_SUCCESS`` -- The optional value has been successfully set. @@ -1051,7 +1051,7 @@ Main solver optional input functions **Notes:** The default, if this routine is not called, is that no stop time is imposed. - Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be reenabled only though a new call to ``CVodeSetStopTime``). + Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be re-enabled only though a new call to ``CVodeSetStopTime``). A stop time not reached before a call to :c:func:`CVodeReInit` will remain active but can be disabled by calling :c:func:`CVodeClearStopTime`. @@ -1084,7 +1084,7 @@ Main solver optional input functions * ``CV_MEM_NULL`` if the CVODE memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`CVodeSetStopTime`. .. versionadded:: 6.5.1 @@ -2627,7 +2627,7 @@ described next. The values returned in ``ele`` are valid only if :c:func:`CVode` returned a non-negative value. - The ``ele`` vector, togther with the ``eweight`` vector from :c:func:`CVodeGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose components are the products of the components of these two vectors. Thus, for example, if there were recent error test failures, the components causing the failures are those with largest values for the products, denoted loosely as ``eweight[i]*ele[i]``. + The ``ele`` vector, together with the ``eweight`` vector from :c:func:`CVodeGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose components are the products of the components of these two vectors. Thus, for example, if there were recent error test failures, the components causing the failures are those with largest values for the products, denoted loosely as ``eweight[i]*ele[i]``. @@ -3145,7 +3145,7 @@ solver, a suffix (for Linear Solver) has been added here (e.g. ``lenrwLS``). * ``leniwLS`` -- the number of integer values in the CVDIAG workspace. **Return value:** - * ``CVDIAG_SUCCESS`` -- The optional output valus have been successfully set. + * ``CVDIAG_SUCCESS`` -- The optional output values have been successfully set. * ``CVDIAG_MEM_NULL`` -- The ``cvode_mem`` pointer is ``NULL``. * ``CVDIAG_LMEM_NULL`` -- The CVDIAG linear solver has not been initialized. @@ -3232,7 +3232,7 @@ known, simply make that location a value of tout. To stop when the location of the discontinuity is determined by the solution, use the rootfinding feature. In either case, it is critical that the RHS function *not* incorporate the discontinuity, but rather have a smooth -extention over the discontinuity, so that the step across it (and +extension over the discontinuity, so that the step across it (and subsequent rootfinding, if used) can be done efficiently. Then use a switch within the RHS function (communicated through ``user_data``) that can be flipped between the stopping of the integration and the restart, so that @@ -3383,7 +3383,7 @@ These weights will be used in place of those defined by Eq. .. warning:: - The error weight vector must have all components positive. It is the user's responsiblity to perform this test and return -1 if it is not satisfied. + The error weight vector must have all components positive. It is the user's responsibility to perform this test and return -1 if it is not satisfied. .. _CVODE.Usage.CC.user_fct_sim.rootFn: @@ -3406,7 +3406,7 @@ follows: * ``user_data`` a pointer to user data, the same as the ``user_data`` parameter passed to :c:func:`CVodeSetUserData`. **Return value:** - A ``CVRootFn`` should return 0 if successful or a non-zero value if an error occured (in which case the integration is haled and ``CVode`` returns ``CV_RTFUNC_FAIL``. + A ``CVRootFn`` should return 0 if successful or a non-zero value if an error occurred (in which case the integration is haled and ``CVode`` returns ``CV_RTFUNC_FAIL``. **Notes:** Allocation of memory for ``gout`` is automatically handled within CVODE. @@ -3429,7 +3429,7 @@ user-defined projection operation the projection function must have type * ``t`` -- the current value of the independent variable. * ``ycur`` -- the current value of the dependent variable vector :math:`y(t)`. * ``corr`` -- the correction, :math:`c`, to the dependent variable vector so that :math:`y(t) + c` satisfies the constraint equation. - * ``epsProj`` -- the tolerance to use in the nonlinear solver stopping test when solving the nonlinear constrainted least squares problem. + * ``epsProj`` -- the tolerance to use in the nonlinear solver stopping test when solving the nonlinear constrained least squares problem. * ``err`` -- is on input the current error estimate, if error projection is enabled (the default) then this should be overwritten with the projected error on output. If error projection is disabled then ``err`` is ``NULL``. * ``user_data`` a pointer to user data, the same as the ``user_data`` parameter passed to :c:func:`CVodeSetUserData`. @@ -3934,7 +3934,7 @@ the CVBANDPRE module: **Arguments:** * ``cvode_mem`` -- pointer to the CVODE memory block. - * ``lenrwBP`` -- the number of ``sunrealtype`` values in teh CVBANDPRE workspace. + * ``lenrwBP`` -- the number of ``sunrealtype`` values in the CVBANDPRE workspace. * ``leniwBP`` -- the number of integer values in the CVBANDPRE workspace. **Return value:** diff --git a/doc/cvode/guide/source/conf.py b/doc/cvode/guide/source/conf.py index 3d86ad65cb..4377102f1e 100644 --- a/doc/cvode/guide/source/conf.py +++ b/doc/cvode/guide/source/conf.py @@ -291,7 +291,7 @@ texinfo_documents = [ ('index', 'CVODE', u'CVODE Documentation', u'Alan C. Hindmarsh, Radu Serban, Cody J. Balos, David J. Gardner, Daniel R. Reynolds, and Carol S. Woodward', 'CVODE', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/cvode/guide/source/sunnonlinsol/CVODE_interface.rst b/doc/cvode/guide/source/sunnonlinsol/CVODE_interface.rst index be0259cf57..4300c48f3f 100644 --- a/doc/cvode/guide/source/sunnonlinsol/CVODE_interface.rst +++ b/doc/cvode/guide/source/sunnonlinsol/CVODE_interface.rst @@ -111,7 +111,7 @@ might need access to the current value of :math:`\gamma` to compute Jacobian dat custom ``SUNNonlinearSolver`` object. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`CVodeGetNonlinearSystemData` inside the - nonlinear system function to access the requisite data for evaluting + nonlinear system function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` diff --git a/doc/cvodes/cvs_ex_adj.tex b/doc/cvodes/cvs_ex_adj.tex index 00269acf6f..e7b6fc8ebb 100644 --- a/doc/cvodes/cvs_ex_adj.tex +++ b/doc/cvodes/cvs_ex_adj.tex @@ -132,7 +132,7 @@ \subsection{A serial dense example: cvsRoberts\_ASAi\_dns}\label{ss:cvsRoberts_A checkpoint information printed). The next segment of code deals with the setup of the backward problem. -First, a serial vector \id{yB} of length \id{NEQ} is allocated and initalized with the +First, a serial vector \id{yB} of length \id{NEQ} is allocated and initialized with the value of $\lambda (= 0.0)$ at the final time (\id{TB1} = 4.0E7). A second serial vector \id{qB} of dimension \id{NP} is created and initialized to $0.0$. This vector corresponds to the quadrature variables $\xi$ whose values at $t_0$ @@ -415,7 +415,7 @@ \subsection{A parallel example using CVBBDPRE: cvsAtmDisp\_ASAi\_kry\_bbd\_p} \id{f\_comm}, called in \id{f} and \id{fB} before evaluation of the local residual components. Since there is no additional communication required for the {\cvbbdpre} preconditioner, a \id{NULL} pointer is passed for \id{gloc} and \id{glocB} in the -calls to \id{CVBBDPrecInit} and \id{CVBBDPrecInitB}, respectivley. +calls to \id{CVBBDPrecInit} and \id{CVBBDPrecInitB}, respectively. For the sake of clarity, the \id{cvsAtmDisp\_ASAi\_kry\_bbd\_p} example does not use the most memory-efficient implementation possible, as the local segment of the diff --git a/doc/cvodes/cvs_ex_fwd.tex b/doc/cvodes/cvs_ex_fwd.tex index ec8f23fa9e..6c1d8f8803 100644 --- a/doc/cvodes/cvs_ex_fwd.tex +++ b/doc/cvodes/cvs_ex_fwd.tex @@ -252,7 +252,7 @@ \subsection{A serial dense example: cvsRoberts\_FSA\_dns} \id{pbar} (\id{pbar}$_i$ = \id{p}$_i$, which can typically be used for nonzero model parameters). Next, the program allocates memory for \id{yS}, by calling the {\nvecs} function -\id{N\_VCloneVectorArray\_Serial}, and initializaes all sensitivity variables to $0.0$. +\id{N\_VCloneVectorArray\_Serial}, and initializes all sensitivity variables to $0.0$. The call to \id{CVodeSensInit1} specifies the sensitivity solution method through the argument \id{sensi\_meth} (read from the command @@ -290,7 +290,7 @@ \subsection{A serial dense example: cvsRoberts\_FSA\_dns} The user-supplied functions \id{f} (for the right-hand side of the original ODEs) and \id{Jac} (for the system Jacobian) are identical to those in \id{cvRoberts\_dns.c}, -with the notable exeption that model parameters are extracted from the user-defined +with the notable exception that model parameters are extracted from the user-defined data structure \id{data}, which must first be cast to the \id{UserData} type. Similarly, the user-supplied function \id{ewt} is identical to that in \id{cvRoberts\_dns\_uw.c}. The user-supplied function \id{fS} computes the diff --git a/doc/cvodes/cvs_ex_intro.tex b/doc/cvodes/cvs_ex_intro.tex index 6ac7624626..efa1a58264 100644 --- a/doc/cvodes/cvs_ex_intro.tex +++ b/doc/cvodes/cvs_ex_intro.tex @@ -167,7 +167,7 @@ \section{Introduction}\label{s:ex_intro} interaction terms only, using block-grouping. \newline Four different runs are made for this problem. - The product preconditoner is applied on the left and on the right. + The product preconditioner is applied on the left and on the right. In each case, both the modified and classical Gram-Schmidt options are tested. diff --git a/doc/cvodes/guide/source/Constants.rst b/doc/cvodes/guide/source/Constants.rst index cbd469ad51..4be7173ac0 100644 --- a/doc/cvodes/guide/source/Constants.rst +++ b/doc/cvodes/guide/source/Constants.rst @@ -137,7 +137,7 @@ CVODES output constants | ``CV_FIRST_RHSFUNC_ERR`` | -9 | The right-hand side function failed at the first | | | | call. | +----------------------------------+------+--------------------------------------------------------+ - | ``CV_REPTD_RHSFUNC_ERR`` | -10 | The right-hand side function had repetead | + | ``CV_REPTD_RHSFUNC_ERR`` | -10 | The right-hand side function had repeated | | | | recoverable errors. | +----------------------------------+------+--------------------------------------------------------+ | ``CV_UNREC_RHSFUNC_ERR`` | -11 | The right-hand side function had a recoverable | @@ -180,7 +180,7 @@ CVODES output constants | ``CV_FIRST_QRHSFUNC_ERR`` | -32 | The quadrature right-hand side function failed at | | | | the first call. | +----------------------------------+------+--------------------------------------------------------+ - | ``CV_REPTD_QRHSFUNC_ERR`` | -33 | The quadrature ight-hand side function had repetead | + | ``CV_REPTD_QRHSFUNC_ERR`` | -33 | The quadrature ight-hand side function had repeated | | | | recoverable errors. | +----------------------------------+------+--------------------------------------------------------+ | ``CV_UNREC_QRHSFUNC_ERR`` | -34 | The quadrature right-hand side function had a | @@ -194,7 +194,7 @@ CVODES output constants | ``CV_FIRST_SRHSFUNC_ERR`` | -42 | The sensitivity right-hand side function failed at | | | | the first call. | +----------------------------------+------+--------------------------------------------------------+ - | ``CV_REPTD_SRHSFUNC_ERR`` | -43 | The sensitivity ight-hand side function had repetead | + | ``CV_REPTD_SRHSFUNC_ERR`` | -43 | The sensitivity ight-hand side function had repeated | | | | recoverable errors. | +----------------------------------+------+--------------------------------------------------------+ | ``CV_UNREC_SRHSFUNC_ERR`` | -44 | The sensitivity right-hand side function had a | @@ -211,7 +211,7 @@ CVODES output constants | ``CV_FIRST_QSRHSFUNC_ERR`` | -52 | The sensitivity right-hand side function failed at | | | | the first call. | +----------------------------------+------+--------------------------------------------------------+ - | ``CV_REPTD_QSRHSFUNC_ERR`` | -53 | The sensitivity ight-hand side function had repetead | + | ``CV_REPTD_QSRHSFUNC_ERR`` | -53 | The sensitivity ight-hand side function had repeated | | | | recoverable errors. | +----------------------------------+------+--------------------------------------------------------+ | ``CV_UNREC_QSRHSFUNC_ERR`` | -54 | The sensitivity right-hand side function had a | diff --git a/doc/cvodes/guide/source/Introduction.rst b/doc/cvodes/guide/source/Introduction.rst index fbf0685067..419fd7ee20 100644 --- a/doc/cvodes/guide/source/Introduction.rst +++ b/doc/cvodes/guide/source/Introduction.rst @@ -46,7 +46,7 @@ capabilities of both VODE and VODPK have been combined in the C-language package CVODE :cite:p:`CoHi:96`. At present, CVODE may utilize a variety of Krylov methods provided in SUNDIALS -that can be used in conjuction with Newton iteration: these include the GMRES +that can be used in conjunction with Newton iteration: these include the GMRES (Generalized Minimal RESidual) :cite:p:`SaSc:86`, FGMRES (Flexible Generalized Minimum RESidual) :cite:p:`Saa:93`, Bi-CGStab (Bi-Conjugate Gradient Stabilized) :cite:p:`Van:92`, TFQMR (Transpose-Free Quasi-Minimal Residual) @@ -77,7 +77,7 @@ resulting in PVODE :cite:p:`ByHi:99`, the parallel variant of CVODE. CVODES is written with a functionality that is a superset of that of the pair CVODE/PVODE. Sensitivity analysis capabilities, both forward and adjoint, have -been added to the main integrator. Enabling forward sensititivity computations +been added to the main integrator. Enabling forward sensitivity computations in CVODES will result in the code integrating the so-called *sensitivity equations* simultaneously with the original IVP, yielding both the solution and its sensitivity with respect to parameters in the model. Adjoint sensitivity @@ -181,7 +181,7 @@ The structure of this document is as follows: addition to those already described in Chapter :numref:`CVODES.Usage.SIM`. Following that we provide detailed descriptions of the user-callable interface routines specific to forward sensitivity analysis and - of the additonal optional user-defined routines. + of the additional optional user-defined routines. - Chapter :numref:`CVODES.Usage.ADJ` describes the usage of CVODES for adjoint sensitivity analysis. We begin by describing the CVODES checkpointing implementation for interpolation of diff --git a/doc/cvodes/guide/source/Mathematics.rst b/doc/cvodes/guide/source/Mathematics.rst index 6424a6b98f..6f5ec2b285 100644 --- a/doc/cvodes/guide/source/Mathematics.rst +++ b/doc/cvodes/guide/source/Mathematics.rst @@ -850,7 +850,7 @@ the solution of the combined ODE and sensitivity system for the vector matrix of the above linear system is based on exactly the same information as the matrix :math:`M` in :eq:`CVODES_Newtonmat`, it must be updated and factored at every step of the integration, in contrast to an - evalutaion of :math:`M` which is updated only occasionally. For problems with + evaluation of :math:`M` which is updated only occasionally. For problems with many parameters (relative to the problem size), the staggered direct method can outperform the methods described below :cite:p:`LPZ:99`. However, the computational cost associated with matrix updates and factorizations makes @@ -1132,7 +1132,7 @@ the gradient of :math:`G` with respect to :math:`p` is nothing but :label: CVODES_dgdp_1 The gradient of :math:`g(T,y,p)` with respect to :math:`p` can be then obtained -by using the Leibnitz differentiation rule. Indeed, from :eq:`CVODES_G`, +by using the Leibniz differentiation rule. Indeed, from :eq:`CVODES_G`, .. math:: \frac{\mathrm dg}{\mathrm dp}(T) = \frac{\mathrm d}{\mathrm dT}\frac{\mathrm dG}{\mathrm dp} diff --git a/doc/cvodes/guide/source/Usage/ADJ.rst b/doc/cvodes/guide/source/Usage/ADJ.rst index fde6cd2261..6ab2b68396 100644 --- a/doc/cvodes/guide/source/Usage/ADJ.rst +++ b/doc/cvodes/guide/source/Usage/ADJ.rst @@ -1142,7 +1142,7 @@ potentially non-differentiable factor. Krylov linear solver's convergence test constant is reduced from the nonlinear iteration test constant. This routine can be used in both the cases where the backward problem does and does not depend on the forward - sensitvities. + sensitivities. **Arguments:** * ``cvode_mem`` -- pointer to the CVODES memory block. @@ -1171,7 +1171,7 @@ potentially non-differentiable factor. converting from the integrator tolerance (WRMS norm) to the linear solver tolerance (L2 norm) for Newton linear system solves e.g., ``tol_L2 = fac * tol_WRMS``. This routine can be used in both the cases wherethe backward - problem does and does not depend on the forward sensitvities. + problem does and does not depend on the forward sensitivities. **Arguments:** * ``cvode_mem`` -- pointer to the CVODES memory block. @@ -1527,7 +1527,7 @@ provide a ``rhsBS`` function of type :c:type:`CVRhsFnBS` defined as follows: **Arguments:** * ``t`` -- is the current value of the independent variable. * ``y`` -- is the current value of the forward solution vector. - * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitvities of the forward solution. + * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitivities of the forward solution. * ``yB`` -- is the current value of the backward dependent variable vector. * ``yBdot`` -- is the output vector containing the right-hand side. * ``user_dataB`` -- is a pointer to user data, same as passed to ``CVodeSetUserDataB``. @@ -1596,7 +1596,7 @@ by of the correct accessor macros from each ``N_Vector`` implementation). For the sake of computational efficiency, the vector functions in the two ``N_Vector`` implementations provided with CVODES do not perform any - consistency checks with repsect to their ``N_Vector`` arguments + consistency checks with respect to their ``N_Vector`` arguments (see :numref:`NVectors`). The ``user_dataB`` pointer is passed to the user's ``fQB`` function every time it is called and can be the same as the ``user_data`` pointer used for the forward problem. @@ -1626,7 +1626,7 @@ defined by **Arguments:** * ``t`` -- is the current value of the independent variable. * ``y`` -- is the current value of the forward solution vector. - * ``yS`` -- a pointer to an array of ``Ns`` vectors continaing the sensitvities of the forward solution. + * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitivities of the forward solution. * ``yB`` -- is the current value of the backward dependent variable vector. * ``qBdot`` -- is the output vector containing the right-hand side ``fQBS`` of the backward quadrature equations. * ``user_dataB`` -- is a pointer to user data, same as passed to ``CVodeSetUserDataB``. @@ -1645,7 +1645,7 @@ defined by data consistently (including the use of the correct accessor macros from each ``N_Vector`` implementation). For the sake of computational efficiency, the vector functions in the two ``N_Vector`` implementations - provided with CVODES do not perform any consistency checks with repsect to + provided with CVODES do not perform any consistency checks with respect to their ``N_Vector`` arguments (see :numref:`NVectors`). The ``user_dataB`` pointer is passed to the user's ``fQBS`` function every time it is called and can be the same as the ``user_data`` pointer used @@ -1729,7 +1729,7 @@ non-``NULL`` ``SUNMatrix`` object was supplied to **Arguments:** * ``t`` -- is the current value of the independent variable. * ``y`` -- is the current value of the forward solution vector. - * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitvities of the forward solution. + * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitivities of the forward solution. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the backward right-hand side function :math:`f_B`. * ``JacB`` -- is the output approximate Jacobian matrix. @@ -1795,7 +1795,7 @@ J_B` (or an approximation of it) for the backward problem. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the backward right-hand side function :math:`f_B`. * ``AB`` -- is the output approximate linear system matrix. - * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or informtion saved from a previous information can be safely used (``jokB = SUNTRUE``). + * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous information can be safely used (``jokB = SUNTRUE``). * ``jcurB`` -- is an output flag which must be set to ``SUNTRUE`` if Jacobian-related data was recomputed or ``SUNFALSE`` otherwise. * ``gammaB`` -- is the scalar appearing in the matrix :math:`M_B = I - \gamma_B J_B`. * ``user_dataB`` -- is a pointer to the same user data passed to ``CVodeSetUserDataB``. @@ -1838,7 +1838,7 @@ J_B` (or an approximation of it) for the backward problem. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the backward right-hand side function :math:`f_B`. * ``AB`` -- is the output approximate linear system matrix. - * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or informtion saved from a previous information can be safely used (``jokB = SUNTRUE``). + * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous information can be safely used (``jokB = SUNTRUE``). * ``jcurB`` -- is an output flag which must be set to ``SUNTRUE`` if Jacobian-related data was recomputed or ``SUNFALSE`` otherwise. * ``gammaB`` -- is the scalar appearing in the matrix * ``user_dataB`` -- is a pointer to the same user data passed to ``CVodeSetUserDataB``. @@ -2010,7 +2010,7 @@ function of type :c:type:`CVLsJacTimesSetupFnB` or **Arguments:** * ``t`` -- is the current value of the independent variable. * ``y`` -- is the current value of the dependent variable vector, :math:`y(t)`. - * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitvities of the forward solution. + * ``yS`` -- a pointer to an array of ``Ns`` vectors containing the sensitivities of the forward solution. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the right-hand-side function for the backward problem. * ``user_dataB`` -- is a pointer to the same user data provided to ``CVodeSetUserDataB``. @@ -2128,7 +2128,7 @@ function of one of the following two types: * ``y`` -- is the current value of the forward solution vector. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the backward right-hand side function :math:`f_B`. - * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous invokation can be safely used (``jokB = SUNTRUE``). + * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous invocation can be safely used (``jokB = SUNTRUE``). * ``jcurPtr`` -- is an output flag which must be set to ``SUNTRUE`` if Jacobian-related data was recomputed or ``SUNFALSE`` otherwise. * ``gammaB`` -- is the scalar appearing in the matrix :math:`M_B = I - \gamma_B J_B`. * ``user_dataB`` -- is a pointer to the same user data passed to ``CVodeSetUserDataB``. @@ -2156,7 +2156,7 @@ function of one of the following two types: * ``yS`` -- is a pointer to an array containing the forward sensitivity vectors. * ``yB`` -- is the current value of the backward dependent variable vector. * ``fyB`` -- is the current value of the backward right-hand side function :math:`f_B`. - * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous invokation can be safely used (``jokB = SUNTRUE``). + * ``jokB`` -- is an input flag indicating whether Jacobian-related data needs to be recomputed (``jokB = SUNFALSE``) or information saved from a previous invocation can be safely used (``jokB = SUNTRUE``). * ``jcurPtr`` -- is an output flag which must be set to ``SUNTRUE`` if Jacobian-related data was recomputed or ``SUNFALSE`` otherwise. * ``gammaB`` -- is the scalar appearing in the matrix :math:`M_B = I - \gamma_B J_B`. * ``user_dataB`` -- is a pointer to the same user data passed to ``CVodeSetUserDataB``. diff --git a/doc/cvodes/guide/source/Usage/FSA.rst b/doc/cvodes/guide/source/Usage/FSA.rst index bec66d6d76..17723f0607 100644 --- a/doc/cvodes/guide/source/Usage/FSA.rst +++ b/doc/cvodes/guide/source/Usage/FSA.rst @@ -320,7 +320,7 @@ one, respectively. The form of the call to each of these routines is as follows: Passing ``fS1 = NULL`` indicates using the default internal difference quotient sensitivity right-hand side routine. If an error occurred, :c:func:`CVodeSensInit1` also sends an error message to the error handler - funciton. + function. In terms of the problem size :math:`N`, number of sensitivity vectors @@ -1317,7 +1317,7 @@ steps are in bold. #. :silver:`Create sensitivity nonlinear solver object` -#. :silver:`Attach the sensitvity nonlinear solver module` +#. :silver:`Attach the sensitivity nonlinear solver module` #. :silver:`Set sensitivity nonlinear solver optional inputs` @@ -1394,7 +1394,7 @@ of the call to this function is as follows: **Notes:** .. warning:: Before calling :c:func:`CVodeQuadSensInit`, the user must enable the - sensitivites by calling :c:func:`CVodeSensInit` or :c:func:`CVodeSensInit1`. If + sensitivities by calling :c:func:`CVodeSensInit` or :c:func:`CVodeSensInit1`. If an error occurred, :c:func:`CVodeQuadSensInit` also sends an error message to the error handler function. diff --git a/doc/cvodes/guide/source/Usage/SIM.rst b/doc/cvodes/guide/source/Usage/SIM.rst index 18dce59206..8bc54ff2a2 100644 --- a/doc/cvodes/guide/source/Usage/SIM.rst +++ b/doc/cvodes/guide/source/Usage/SIM.rst @@ -443,7 +443,7 @@ makes no sense (and is overly costly) after ``y[i]`` is below some noise level. ``abstol`` (if scalar) or ``abstol[i]`` (if a vector) needs to be set to that noise level. If the different components have different noise levels, then ``abstol`` should be a vector. See the example ``cvsRoberts_dns`` in the CVODES package, and the discussion of it in the CVODES Examples document -:cite:p:`cvodes_ex`. In that problem, the three components vary betwen 0 and 1, +:cite:p:`cvodes_ex`. In that problem, the three components vary between 0 and 1, and have different noise levels; hence the ``abstol`` vector. It is impossible to give any general advice on ``abstol`` values, because the appropriate noise levels are completely problem-dependent. The user or modeler hopefully has some idea as to what those @@ -772,7 +772,7 @@ rootfinding. In the ``CV_ONE_STEP`` mode, ``tout`` is used only on the first call, and only to get the direction and a rough scale of the independent variable. - If a stop time is enabled (through a call to ``CVodeSetStopTime``), then ``CVode`` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be reenabled only though a new call to ``CVodeSetStopTime``). + If a stop time is enabled (through a call to ``CVodeSetStopTime``), then ``CVode`` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be re-enabled only though a new call to ``CVodeSetStopTime``). All failure return values are negative and so the test ``flag < 0`` will trap all ``CVode`` failures. @@ -914,7 +914,7 @@ Main solver optional input functions **Arguments:** * ``cvode_mem`` -- pointer to the CVODES memory block. - * ``nst`` -- number of successful steps inbetween calls to the monitor function 0 by default; a 0 input will turn off monitoring. + * ``nst`` -- number of successful steps in between calls to the monitor function 0 by default; a 0 input will turn off monitoring. **Return value:** * ``CV_SUCCESS`` -- The optional value has been successfully set. @@ -1056,7 +1056,7 @@ Main solver optional input functions **Notes:** The default, if this routine is not called, is that no stop time is imposed. - Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be reenabled only though a new call to ``CVodeSetStopTime``). + Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and can be re-enabled only though a new call to ``CVodeSetStopTime``). A stop time not reached before a call to :c:func:`CVodeReInit` will remain active but can be disabled by calling :c:func:`CVodeClearStopTime`. @@ -1089,7 +1089,7 @@ Main solver optional input functions * ``CV_MEM_NULL`` if the CVODES memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`CVodeSetStopTime`. .. versionadded:: 6.5.1 @@ -2627,7 +2627,7 @@ described next. The values returned in ``ele`` are valid only if :c:func:`CVode` returned a non-negative value. - The ``ele`` vector, togther with the ``eweight`` vector from :c:func:`CVodeGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose components are the products of the components of these two vectors. Thus, for example, if there were recent error test failures, the components causing the failures are those with largest values for the products, denoted loosely as ``eweight[i]*ele[i]``. + The ``ele`` vector, together with the ``eweight`` vector from :c:func:`CVodeGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose components are the products of the components of these two vectors. Thus, for example, if there were recent error test failures, the components causing the failures are those with largest values for the products, denoted loosely as ``eweight[i]*ele[i]``. @@ -3136,7 +3136,7 @@ solver, a suffix (for Linear Solver) has been added here (e.g. ``lenrwLS``). * ``leniwLS`` -- the number of integer values in the CVDIAG workspace. **Return value:** - * ``CVDIAG_SUCCESS`` -- The optional output valus have been successfully set. + * ``CVDIAG_SUCCESS`` -- The optional output values have been successfully set. * ``CVDIAG_MEM_NULL`` -- The ``cvode_mem`` pointer is ``NULL``. * ``CVDIAG_LMEM_NULL`` -- The CVDIAG linear solver has not been initialized. @@ -3223,7 +3223,7 @@ known, simply make that location a value of tout. To stop when the location of the discontinuity is determined by the solution, use the rootfinding feature. In either case, it is critical that the RHS function *not* incorporate the discontinuity, but rather have a smooth -extention over the discontinuity, so that the step across it (and +extension over the discontinuity, so that the step across it (and subsequent rootfinding, if used) can be done efficiently. Then use a switch within the RHS function (communicated through ``user_data``) that can be flipped between the stopping of the integration and the restart, so that @@ -3382,7 +3382,7 @@ These weights will be used in place of those defined by Eq. .. warning:: - The error weight vector must have all components positive. It is the user's responsiblity to perform this test and return -1 if it is not satisfied. + The error weight vector must have all components positive. It is the user's responsibility to perform this test and return -1 if it is not satisfied. .. _CVODES.Usage.SIM.user_supplied.rootFn: @@ -3405,7 +3405,7 @@ follows: * ``user_data`` a pointer to user data, the same as the ``user_data`` parameter passed to :c:func:`CVodeSetUserData`. **Return value:** - A ``CVRootFn`` should return 0 if successful or a non-zero value if an error occured (in which case the integration is haled and ``CVode`` returns ``CV_RTFUNC_FAIL``. + A ``CVRootFn`` should return 0 if successful or a non-zero value if an error occurred (in which case the integration is haled and ``CVode`` returns ``CV_RTFUNC_FAIL``. **Notes:** Allocation of memory for ``gout`` is automatically handled within CVODES. @@ -3428,7 +3428,7 @@ user-defined projection operation the projection function must have type * ``t`` -- the current value of the independent variable. * ``ycur`` -- the current value of the dependent variable vector :math:`y(t)`. * ``corr`` -- the correction, :math:`c`, to the dependent variable vector so that :math:`y(t) + c` satisfies the constraint equation. - * ``epsProj`` -- the tolerance to use in the nonlinear solver stopping test when solving the nonlinear constrainted least squares problem. + * ``epsProj`` -- the tolerance to use in the nonlinear solver stopping test when solving the nonlinear constrained least squares problem. * ``err`` -- is on input the current error estimate, if error projection is enabled (the default) then this should be overwritten with the projected error on output. If error projection is disabled then ``err`` is ``NULL``. * ``user_data`` a pointer to user data, the same as the ``user_data`` parameter passed to :c:func:`CVodeSetUserData`. @@ -3855,7 +3855,7 @@ are in bold. #. **Set optional inputs for quadrature integration** Call :c:func:`CVodeSetQuadErrCon` to indicate whether or not quadrature - variables shoule be used in the step size control mechanism, and to specify + variables should be used in the step size control mechanism, and to specify the integration tolerances for quadrature variables. See :numref:`CVODES.Usage.purequad.optional_inputs` for details. diff --git a/doc/cvodes/guide/source/conf.py b/doc/cvodes/guide/source/conf.py index a8a21e28a1..a8e4f703f7 100644 --- a/doc/cvodes/guide/source/conf.py +++ b/doc/cvodes/guide/source/conf.py @@ -291,7 +291,7 @@ texinfo_documents = [ ('index', 'CVODES', u'CVODES Documentation', u'Alan C. Hindmarsh, Radu Serban, Cody J. Balos, David J. Gardner, Daniel R. Reynolds, and Carol S. Woodward', 'CVODES', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/cvodes/guide/source/sunnonlinsol/CVODES_interface.rst b/doc/cvodes/guide/source/sunnonlinsol/CVODES_interface.rst index fa046db709..3d4a42140d 100644 --- a/doc/cvodes/guide/source/sunnonlinsol/CVODES_interface.rst +++ b/doc/cvodes/guide/source/sunnonlinsol/CVODES_interface.rst @@ -49,7 +49,7 @@ the combined state and sensitivity nonlinear systems are also reformulated in terms of the correction to the predicted state and sensitivities. The nonlinear system functions provided by CVODES to the nonlinear solver module -internally update the current value of the new state (and the sensitvities) +internally update the current value of the new state (and the sensitivities) based on the input correction vector(s) i.e., :math:`y^n = y_{pred} + y_{cor}` and :math:`s_i^n = s_{i,pred} + s_{i,cor}`. The updated vector(s) are used when calling the right-hand side function and when setting up linear solves (e.g., @@ -125,7 +125,7 @@ need access to the current value of :math:`\gamma` to compute Jacobian data. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`CVodeGetNonlinearSystemData` inside the - nonlinear system function to access the requisite data for evaluting + nonlinear system function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` @@ -208,15 +208,15 @@ need access to the current value of :math:`\gamma` to compute Jacobian data. * ``CV_MEM_NULL`` -- The ``cvode_mem`` pointer is ``NULL``. **Notes:** - This routine is intended for users who whish to attach a custom + This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to ``SUNNonlinSolSetSysFn``) or who need access to - nonlinear system data to compute the nonlinear system fucntion as part of + nonlinear system data to compute the nonlinear system function as part of a custom ``SUNNonlinearSolver`` object. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`CVodeGetNonlinearSystemDataSens` inside the nonlinear system function used in the sensitivity nonlinear solve to access the - requisite data for evaluting the nonlinear system function of their + requisite data for evaluating the nonlinear system function of their choosing. This could be the same function used for solving for the new state (the simultaneous approach) or a different function (the staggered or stagggered1 approaches). Additionlly, the vectors ``ySn`` are only diff --git a/doc/ida/guide/source/Introduction.rst b/doc/ida/guide/source/Introduction.rst index 029b9a3523..b100289002 100644 --- a/doc/ida/guide/source/Introduction.rst +++ b/doc/ida/guide/source/Introduction.rst @@ -37,7 +37,7 @@ LLNL to support the ordinary differential equation (ODE) solvers CVODE nonlinear system solver KINSOL :cite:p:`kinsol_ug`. At present, IDA may utilize a variety of Krylov methods provided in SUNDIALS -that can be used in conjuction with Newton iteration: these include the GMRES +that can be used in conjunction with Newton iteration: these include the GMRES (Generalized Minimal RESidual) :cite:p:`SaSc:86`, FGMRES (Flexible Generalized Minimum RESidual) :cite:p:`Saa:93`, Bi-CGStab (Bi-Conjugate Gradient Stabilized) :cite:p:`Van:92`, TFQMR (Transpose-Free Quasi-Minimal Residual) diff --git a/doc/ida/guide/source/Usage/index.rst b/doc/ida/guide/source/Usage/index.rst index 2402ae83eb..36b20b743e 100644 --- a/doc/ida/guide/source/Usage/index.rst +++ b/doc/ida/guide/source/Usage/index.rst @@ -449,7 +449,7 @@ For many users, the appropriate choices for tolerance values in ``reltol`` and different components have different noise levels, then ``abstol`` should be a vector. See the example ``idaRoberts_dns`` in the IDA package, and the discussion of it in the IDA Examples document :cite:p:`ida_ex`. In that - problem, the three components vary betwen 0 and 1, and have different noise + problem, the three components vary between 0 and 1, and have different noise levels; hence the ``abstol`` vector. It is impossible to give any general advice on ``abstol`` values, because the appropriate noise levels are completely problem-dependent. The user or modeler hopefully has some idea as @@ -840,7 +840,7 @@ rootfinding (with :c:func:`IDARootInit`). If a stop time is enabled (through a call to :c:func:`IDASetStopTime`), then :c:func:`IDASolve` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and - can be reenabled only though a new call to :c:func:`IDASetStopTime`). + can be re-enabled only though a new call to :c:func:`IDASetStopTime`). All failure return values are negative and therefore a test ``flag < 0`` will trap all :c:func:`IDASolve` failures. @@ -1067,7 +1067,7 @@ Main solver optional input functions **Notes:** The default, if this routine is not called, is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for ``tstop`` - is disabled (and can be reenabled only though a new call to + is disabled (and can be re-enabled only though a new call to :c:func:`IDASetStopTime`). A stop time not reached before a call to :c:func:`IDAReInit` will @@ -1085,7 +1085,7 @@ Main solver optional input functions * ``IDA_MEM_NULL`` if the IDA memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`IDASetStopTime`. .. versionadded:: 6.5.1 @@ -2492,7 +2492,7 @@ described next. .. note:: - The ``ele`` vector, togther with the ``eweight`` vector from + The ``ele`` vector, together with the ``eweight`` vector from :c:func:`IDAGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose @@ -3054,7 +3054,7 @@ To stop when the location of the discontinuity is known, simply make that location a value of :math:`t_{\text{out}}`. To stop when the location of the discontinuity is determined by the solution, use the rootfinding feature. In either case, it is critical that the residual function *not* incorporate the -discontinuity, but rather have a smooth extention over the discontinuity, so +discontinuity, but rather have a smooth extension over the discontinuity, so that the step across it (and subsequent rootfinding, if used) can be done efficiently. Then use a switch within the residual function (communicated through ``user_data``) that can be flipped between the stopping of the @@ -3164,7 +3164,7 @@ Error weight function **Return value:** * ``0`` -- if it the error weights were successfully set. - * ``-1`` -- if any error occured. + * ``-1`` -- if any error occurred. **Notes:** Allocation of memory for ``ewt`` is handled within IDA. @@ -3172,7 +3172,7 @@ Error weight function .. warning:: The error weight vector must have all components positive. It is the - user's responsiblity to perform this test and return -1 if it is not + user's responsibility to perform this test and return -1 if it is not satisfied. @@ -3203,8 +3203,8 @@ as follows: parameter passed to :c:func:`IDASetUserData`. **Return value:** - ``0`` if successful or non-zero if an error occured (in which case the - integration is halted and :c:func:`IDASolve` returs ``IDA_RTFUNC_FAIL``). + ``0`` if successful or non-zero if an error occurred (in which case the + integration is halted and :c:func:`IDASolve` returns ``IDA_RTFUNC_FAIL``). **Notes:** Allocation of memory for ``gout`` is handled within IDA. @@ -3247,7 +3247,7 @@ user may provide a function of type :c:type:`IDALsJacFn` defined as follows: value if a recoverable error occurred, or a negative value if a nonrecoverable error occurred. - In the case of a recoverable eror return, the integrator will attempt to + In the case of a recoverable error return, the integrator will attempt to recover by reducing the stepsize, and hence changing :math:`\alpha` in :eq:`IDA_DAE_Jacobian`. diff --git a/doc/ida/guide/source/conf.py b/doc/ida/guide/source/conf.py index a92a878cf5..53f27fadba 100644 --- a/doc/ida/guide/source/conf.py +++ b/doc/ida/guide/source/conf.py @@ -291,7 +291,7 @@ texinfo_documents = [ ('index', 'IDA', u'IDA Documentation', u'Alan C. Hindmarsh, Radu Serban, Cody J. Balos, David J. Gardner, Daniel R. Reynolds, and Carol S. Woodward', 'IDA', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/ida/guide/source/sunnonlinsol/IDA_interface.rst b/doc/ida/guide/source/sunnonlinsol/IDA_interface.rst index 36feccee89..2ec40ffb7a 100644 --- a/doc/ida/guide/source/sunnonlinsol/IDA_interface.rst +++ b/doc/ida/guide/source/sunnonlinsol/IDA_interface.rst @@ -117,13 +117,13 @@ the current :math:`y` and :math:`\dot{y}` vectors to compute Jacobian data. This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn`) or who need access to - nonlinear system data to compute the nonlinear system fucntion as part of a + nonlinear system data to compute the nonlinear system function as part of a custom ``SUNNonlinearSolver`` object. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`IDAGetNonlinearSystemData` inside the nonlinear system function to - access the requisite data for evaluting the nonlinear system function of + access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` functions supplied by IDA (through calls to diff --git a/doc/ida/ida_ex_fortran.tex b/doc/ida/ida_ex_fortran.tex index af9260e4dc..60ab483870 100644 --- a/doc/ida/ida_ex_fortran.tex +++ b/doc/ida/ida_ex_fortran.tex @@ -66,7 +66,7 @@ \subsection{A parallel example: fidaHeat2D\_kry\_bbd\_p}\label{ss:fidaHeat2D_bbd a call to \id{FNVINITP} to initialize {\nvecp}, and a call to \id{SETINITPROFILE} to initialize the \id{UU}, \id{UP}, \id{ID}, and \id{CONSTR} arrays (containing the solution vector, solution derivative vector, -the differential/algebraic bit vector, and the contraint specification +the differential/algebraic bit vector, and the constraint specification vector, respectively). A call to \id{FIDASETIIN} and two calls to \id{FIDASETVIN} are made to suppress error control on the algebraic variables, and to supply the \id{ID} array and constraints array (making diff --git a/doc/ida/ida_ex_serial.tex b/doc/ida/ida_ex_serial.tex index fb9e8fd934..6322125609 100644 --- a/doc/ida/ida_ex_serial.tex +++ b/doc/ida/ida_ex_serial.tex @@ -61,7 +61,7 @@ \subsection{A dense example: idaRoberts\_dns}\label{ss:idaRoberts} After various declarations, the \id{main} program begins by allocating memory for the \id{yy}, \id{yp}, and \id{avtol} vectors using \id{N\_VNew\_Serial} with a length argument of \id{NEQ} ($= 3$). The -lines following that load the initial values of the dependendent +lines following that load the initial values of the dependent variable vectors into \id{yy} and \id{yp}, and set the relative tolerance \id{rtol} and absolute tolerance vector \id{avtol}. Serial \id{N\_Vector} values are set by first accessing the pointer to their underlying data using @@ -389,7 +389,7 @@ \subsection{A Krylov example: idaHeat2D\_kry}\label{ss:idaHeat2D} of the PDE (using central differences) in the rest of the domain. The user-supplied functions \id{PsetupHeat} and \id{PsolveHeat} together define the -left preconditoner matrix $P$ approximating the system Jacobian matrix +left preconditioner matrix $P$ approximating the system Jacobian matrix $J = \partial F/ \partial u + \alpha \partial F/ \partial u'$ (where the DAE system is $F(t,u,u') = 0$), and solve the linear systems $P z = r$. Preconditioning is done in this case by keeping only the diagonal elements of diff --git a/doc/ida/ida_ex_trilinos.tex b/doc/ida/ida_ex_trilinos.tex index aa4ad1140e..58dc769c4b 100644 --- a/doc/ida/ida_ex_trilinos.tex +++ b/doc/ida/ida_ex_trilinos.tex @@ -49,7 +49,7 @@ \subsection{A nonstiff shared memory parallel example: idaHeat2D\_kry\_tpetra} changing the example code. Once the communicator and map are set, a Tpetra vector is created as: \begin{verbatim} - /* Create a Tpetra vector and return refernce counting pointer to it. */ + /* Create a Tpetra vector and return reference counting pointer to it. */ Teuchos::RCP rcpuu = Teuchos::rcp(new vector_type(mpiMap)); \end{verbatim} diff --git a/doc/idas/guide/source/Introduction.rst b/doc/idas/guide/source/Introduction.rst index 771da6ec5b..5f1b554c5f 100644 --- a/doc/idas/guide/source/Introduction.rst +++ b/doc/idas/guide/source/Introduction.rst @@ -37,7 +37,7 @@ at LLNL to support the ordinary differential equation (ODE) solvers CVODE nonlinear system solver KINSOL :cite:p:`kinsol_ug`. At present, IDAS may utilize a variety of Krylov methods provided in SUNDIALS -that can be used in conjuction with Newton iteration: these include the GMRES +that can be used in conjunction with Newton iteration: these include the GMRES (Generalized Minimal RESidual) :cite:p:`SaSc:86`, FGMRES (Flexible Generalized Minimum RESidual) :cite:p:`Saa:93`, Bi-CGStab (Bi-Conjugate Gradient Stabilized) :cite:p:`Van:92`, TFQMR (Transpose-Free Quasi-Minimal Residual) @@ -119,7 +119,7 @@ The structure of this document is as follows: that are required in addition to those already described in Chapter :numref:`IDAS.Usage.SIM`. Following that we provide detailed descriptions of the user-callable interface routines specific to forward - sensitivity analysis and of the additonal optional user-defined routines. + sensitivity analysis and of the additional optional user-defined routines. * Chapter :numref:`IDAS.Usage.ADJ` describes the usage of IDAS for adjoint sensitivity analysis. We begin by describing the IDAS checkpointing diff --git a/doc/idas/guide/source/Usage/ADJ.rst b/doc/idas/guide/source/Usage/ADJ.rst index 60c76147d7..af8b782a28 100644 --- a/doc/idas/guide/source/Usage/ADJ.rst +++ b/doc/idas/guide/source/Usage/ADJ.rst @@ -1115,7 +1115,7 @@ setting increments for the finite-difference approximation, via a call to increments used in the difference quotient approximations to matrix-vector products for the backward problem. This routine can be used in both the cases where the backward problem does and does not depend on the forward - sensitvities. + sensitivities. **Arguments:** * ``ida_mem`` -- pointer to the IDAS memory block. @@ -1245,7 +1245,7 @@ These may be accomplished through calling the following functions: Krylov linear solver's convergence test constant is reduced from the nonlinear iteration test constant. (See :numref:`IDAS.Mathematics.ivp_sol`). This routine can be used in both the cases wherethe backward problem does - and does not depend on the forward sensitvities. + and does not depend on the forward sensitivities. **Arguments:** * ``ida_mem`` -- pointer to the IDAS memory block. @@ -1275,7 +1275,7 @@ These may be accomplished through calling the following functions: converting from the integrator tolerance (WRMS norm) to the linear solver tolerance (L2 norm) for Newton linear system solves e.g., ``tol_L2 = fac * tol_WRMS``. This routine can be used in both the cases wherethe backward - problem does and does not depend on the forward sensitvities. + problem does and does not depend on the forward sensitivities. **Arguments:** * ``ida_mem`` -- pointer to the IDAS memory block. @@ -1746,7 +1746,7 @@ The user must provide an ``fQB`` function of type ``IDAQuadRhsFnB`` defined by data consistently (including the use of the correct accessor macros from each ``N_Vector`` implementation). For the sake of computational efficiency, the vector functions in the two ``N_Vector`` implementations - provided with IDAS do not perform any consistency checks with repsect to + provided with IDAS do not perform any consistency checks with respect to their ``N_Vector`` arguments (see :numref:`NVectors`). The ``user_dataB`` pointer is passed to the user's ``fQB`` function every time it is called and can be the same as the ``user_data`` pointer used for the forward diff --git a/doc/idas/guide/source/Usage/FSA.rst b/doc/idas/guide/source/Usage/FSA.rst index 6309026184..38f5608634 100644 --- a/doc/idas/guide/source/Usage/FSA.rst +++ b/doc/idas/guide/source/Usage/FSA.rst @@ -1224,7 +1224,7 @@ in the notation of :eq:`IDAS_QUAD`. The form of the call to this function is as .. warning:: Before calling :c:func:`IDAQuadSensInit`, the user must enable the - sensitivites by calling :c:func:`IDASensInit`. If an error occurred, + sensitivities by calling :c:func:`IDASensInit`. If an error occurred, :c:func:`IDAQuadSensInit` also sends an error message to the error handler function. diff --git a/doc/idas/guide/source/Usage/SIM.rst b/doc/idas/guide/source/Usage/SIM.rst index 981291a4aa..f8bbe96021 100644 --- a/doc/idas/guide/source/Usage/SIM.rst +++ b/doc/idas/guide/source/Usage/SIM.rst @@ -447,7 +447,7 @@ For many users, the appropriate choices for tolerance values in ``reltol`` and different components have different noise levels, then ``abstol`` should be a vector. See the example ``idaRoberts_dns`` in the IDAS package, and the discussion of it in the IDAS Examples document :cite:p:`ida_ex`. In that - problem, the three components vary betwen 0 and 1, and have different noise + problem, the three components vary between 0 and 1, and have different noise levels; hence the ``abstol`` vector. It is impossible to give any general advice on ``abstol`` values, because the appropriate noise levels are completely problem-dependent. The user or modeler hopefully has some idea as @@ -845,7 +845,7 @@ rootfinding (with :c:func:`IDARootInit`). If a stop time is enabled (through a call to :c:func:`IDASetStopTime`), then :c:func:`IDASolve` returns the solution at ``tstop``. Once the integrator returns at a stop time, any future testing for ``tstop`` is disabled (and - can be reenabled only though a new call to :c:func:`IDASetStopTime`). + can be re-enabled only though a new call to :c:func:`IDASetStopTime`). All failure return values are negative and therefore a test ``flag < 0`` will trap all :c:func:`IDASolve` failures. @@ -1072,7 +1072,7 @@ Main solver optional input functions **Notes:** The default, if this routine is not called, is that no stop time is imposed. Once the integrator returns at a stop time, any future testing for ``tstop`` - is disabled (and can be reenabled only though a new call to + is disabled (and can be re-enabled only though a new call to :c:func:`IDASetStopTime`). A stop time not reached before a call to :c:func:`IDAReInit` will @@ -1090,7 +1090,7 @@ Main solver optional input functions * ``IDA_MEM_NULL`` if the IDA memory is ``NULL`` **Notes:** - The stop time can be reenabled though a new call to + The stop time can be re-enabled though a new call to :c:func:`IDASetStopTime`. .. versionadded:: 6.5.1 @@ -1802,7 +1802,7 @@ to set optional inputs controlling the initial condition calculation. If :c:func:`IDASetMaxBacksIC` is called in a Forward Sensitivity Analysis, the the limit ``maxbacks`` applies in the calculation of both the initial state - values and the initial sensititivies. + values and the initial sensitivities. .. c:function:: int IDASetLineSearchOffIC(void * ida_mem, sunbooleantype lsoff) @@ -2518,7 +2518,7 @@ described next. .. note:: - The ``ele`` vector, togther with the ``eweight`` vector from + The ``ele`` vector, together with the ``eweight`` vector from :c:func:`IDAGetErrWeights`, can be used to determine how the various components of the system contributed to the estimated local error test. Specifically, that error test uses the RMS norm of a vector whose @@ -3084,7 +3084,7 @@ To stop when the location of the discontinuity is known, simply make that location a value of :math:`t_{\text{out}}`. To stop when the location of the discontinuity is determined by the solution, use the rootfinding feature. In either case, it is critical that the residual function *not* incorporate the -discontinuity, but rather have a smooth extention over the discontinuity, so +discontinuity, but rather have a smooth extension over the discontinuity, so that the step across it (and subsequent rootfinding, if used) can be done efficiently. Then use a switch within the residual function (communicated through ``user_data``) that can be flipped between the stopping of the @@ -3204,7 +3204,7 @@ Error weight function **Return value:** * ``0`` -- if it the error weights were successfully set. - * ``-1`` -- if any error occured. + * ``-1`` -- if any error occurred. **Notes:** Allocation of memory for ``ewt`` is handled within IDAS. @@ -3212,7 +3212,7 @@ Error weight function .. warning:: The error weight vector must have all components positive. It is the - user's responsiblity to perform this test and return -1 if it is not + user's responsibility to perform this test and return -1 if it is not satisfied. @@ -3243,7 +3243,7 @@ as follows: parameter passed to :c:func:`IDASetUserData`. **Return value:** - ``0`` if successful or non-zero if an error occured (in which case the + ``0`` if successful or non-zero if an error occurred (in which case the integration is halted and :c:func:`IDASolve` returns ``IDA_RTFUNC_FAIL``). **Notes:** @@ -3287,7 +3287,7 @@ user may provide a function of type :c:type:`IDALsJacFn` defined as follows: value if a recoverable error occurred, or a negative value if a nonrecoverable error occurred. - In the case of a recoverable eror return, the integrator will attempt to + In the case of a recoverable error return, the integrator will attempt to recover by reducing the stepsize, and hence changing :math:`\alpha` in :eq:`IDAS_DAE_Jacobian`. @@ -3658,7 +3658,7 @@ steps are in bold. #. **Set optional inputs for quadrature integration** Call :c:func:`IDASetQuadErrCon` to indicate whether or not quadrature - variables shoule be used in the step size control mechanism, and to specify + variables should be used in the step size control mechanism, and to specify the integration tolerances for quadrature variables. See :numref:`IDAS.Usage.Purequad.quad_optional_input` for details. diff --git a/doc/idas/guide/source/conf.py b/doc/idas/guide/source/conf.py index 8613adcf6a..e0da18474a 100644 --- a/doc/idas/guide/source/conf.py +++ b/doc/idas/guide/source/conf.py @@ -292,7 +292,7 @@ texinfo_documents = [ ('index', 'IDAS', u'IDAS Documentation', u'Alan C. Hindmarsh, Radu Serban, Cody J. Balos, David J. Gardner, Daniel R. Reynolds, and Carol S. Woodward', 'IDAS', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/idas/guide/source/sunnonlinsol/IDAS_interface.rst b/doc/idas/guide/source/sunnonlinsol/IDAS_interface.rst index d2d6cc8746..54f8375db9 100644 --- a/doc/idas/guide/source/sunnonlinsol/IDAS_interface.rst +++ b/doc/idas/guide/source/sunnonlinsol/IDAS_interface.rst @@ -40,7 +40,7 @@ reformulated in terms of the correction to the predicted sensitivities. The nonlinear system function provided by IDAS to the nonlinear solver module internally updates the current value of the new state and its derivative based -on the current corretion passed to the function (as well as the sensitivities). +on the current correction passed to the function (as well as the sensitivities). These values are used when calling the DAE residual function and when setting up linear solves (e.g., for updating the Jacobian or preconditioner). @@ -149,13 +149,13 @@ the current :math:`y` and :math:`\dot{y}` vectors to compute Jacobian data. This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn`) or who need access to - nonlinear system data to compute the nonlinear system fucntion as part of a + nonlinear system data to compute the nonlinear system function as part of a custom ``SUNNonlinearSolver`` object. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`IDAGetNonlinearSystemData` inside the nonlinear system function to - access the requisite data for evaluting the nonlinear system function of + access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the ``SUNNonlinearSolver`` object (existing or custom) leverages the :c:type:`SUNNonlinSolLSetupFn` and/or :c:type:`SUNNonlinSolLSolveFn` functions supplied by IDAS (through calls to @@ -203,11 +203,11 @@ the current :math:`y` and :math:`\dot{y}` vectors to compute Jacobian data. This routine is intended for users who wish to attach a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object (through a call to :c:func:`SUNNonlinSolSetSysFn`) or who need access to - nonlinear system data to compute the nonlinear system fucntion as part of + nonlinear system data to compute the nonlinear system function as part of a custom ``SUNNonlinearSolver`` object. When supplying a custom :c:type:`SUNNonlinSolSysFn` to an existing ``SUNNonlinearSolver`` object, the user should call :c:func:`IDAGetNonlinearSystemDataSens` inside the - nonlinear system function to access the requisite data for evaluting the + nonlinear system function to access the requisite data for evaluating the nonlinear system function of their choosing. Additionlly, if the the vectors ``yySn`` and ``ypSn`` are provided as additional workspace and do not need to be filled in by the user's :c:type:`SUNNonlinSolSysFn`. If diff --git a/doc/idas/idas_ex_intro.tex b/doc/idas/idas_ex_intro.tex index fde54914d3..d2ca2de7eb 100644 --- a/doc/idas/idas_ex_intro.tex +++ b/doc/idas/idas_ex_intro.tex @@ -296,7 +296,7 @@ \section{Introduction}\label{s:ex_intro} {\em builddir}\id{/lib/libsundials\_idas.}{\em lib} instead of {\em builddir}\id{/lib/libsundials\_ida.}{\em lib}. -We also give our output files for each of thes examples described below, +We also give our output files for each of the examples described below, but users should be cautioned that their results may differ slightly from these. Differences in solution values may differ within the tolerances, and differences in cumulative counters, such as numbers of steps or Newton iterations, may differ diff --git a/doc/kinsol/guide/source/Usage/index.rst b/doc/kinsol/guide/source/Usage/index.rst index dd1bcacec1..ebe2aeef76 100644 --- a/doc/kinsol/guide/source/Usage/index.rst +++ b/doc/kinsol/guide/source/Usage/index.rst @@ -1030,7 +1030,7 @@ negative, so a test ``retval`` :math:`<0` will catch any error. .. c:function:: int KINSetDampingAA(void * kin_mem, sunrealtype beta) The function :c:func:`KINSetDampingAA` specifies the value of the Anderson - acceleration damping paramter. + acceleration damping parameter. **Arguments:** * ``kin_mem`` -- pointer to the KINSOL memory block. @@ -1946,7 +1946,7 @@ supplied, the default is a difference quotient approximation to these products. This function computes the product :math:`J v` (or an approximation to it). **Arguments:** - * ``v`` -- is the vector by which the Jacobian must be multplied to the right. + * ``v`` -- is the vector by which the Jacobian must be multiplied to the right. * ``Jv`` -- is the computed output vector. * ``u`` -- is the current value of the dependent variable vector. * ``user_data`` -- is a pointer to user data, the same as the ``user_data`` @@ -1999,7 +1999,7 @@ of type :c:type:`KINLsPrecSolveFn`, defined as follows: * ``uscale`` -- is a vector containing diagonal elements of the scaling matrix ``u`` * ``fval`` -- is the vector :math:`F(u)` evaluated at ``u`` * ``fscale`` -- is a vector containing diagonal elements of the scaling matrix for ``fval`` - * ``v`` -- on inpuut, ``v`` is set to the right-hand side vector of the linear system, ``r``. On output, ``v`` must contain the solution ``z`` of the linear system :math:`Pz=r` + * ``v`` -- on input, ``v`` is set to the right-hand side vector of the linear system, ``r``. On output, ``v`` must contain the solution ``z`` of the linear system :math:`Pz=r` * ``user_data`` -- is a pointer to user data, the same as the ``user_data`` parameter passed to :c:func:`KINSetUserData`. @@ -2131,7 +2131,7 @@ communication. **Return value:** An :c:type:`KINBBDLocalFn` function type should return 0 to indicate success, - or non-zero if an error occured. + or non-zero if an error occurred. **Notes:** This function must assume that all inter-processor communication of data @@ -2155,7 +2155,7 @@ communication. **Return value:** An :c:type:`KINBBDLocalFn` function type should return 0 to indicate success, - or non-zero if an error occured. + or non-zero if an error occurred. **Notes:** The ``Gcomm`` function is expected to save communicated data in space defined diff --git a/doc/kinsol/guide/source/conf.py b/doc/kinsol/guide/source/conf.py index c8cef7c6ac..074821a0a3 100644 --- a/doc/kinsol/guide/source/conf.py +++ b/doc/kinsol/guide/source/conf.py @@ -296,7 +296,7 @@ texinfo_documents = [ ('index', 'KINSOL', u'KINSOL Documentation', u'Alan C. Hindmarsh, Radu Serban, Cody J. Balos, David J. Gardner, Daniel R. Reynolds, and Carol S. Woodward', 'KINSOL', - 'Time integration package for multi-rate systems of ordinary differntial equations.', + 'Time integration package for multi-rate systems of ordinary differential equations.', 'Miscellaneous'), ] diff --git a/doc/kinsol/kin_ex_c.tex b/doc/kinsol/kin_ex_c.tex index 74fd91f289..8fea81bf05 100644 --- a/doc/kinsol/kin_ex_c.tex +++ b/doc/kinsol/kin_ex_c.tex @@ -89,7 +89,7 @@ \subsection{A serial dense example: kinFerTron\_dns}\label{ss:kinFerTron_dns} functions \id{SetInitialGuess1} and \id{SetInitialGuess2} and the constraint vector \id{c} is initialized to $[0,0,1,-1,1,-1]$ indicating that there are no additional constraints on the first two components of \id{u} (i.e. $x_1$ and -$x_2$) and that the 3rd and 5th compnents should be non-negative, while +$x_2$) and that the 3rd and 5th components should be non-negative, while the 4th and 6th should be non-positive. The calls to \id{N\_VNew\_Serial}, and also later calls to various \id{KIN***} @@ -275,7 +275,7 @@ \subsection{A serial Krylov example: kinFoodWeb\_kry}\label{ss:kinFoodWeb_kry} to load problem constants in the \id{data} block; \id{FreeUserData} to free that block; \id{SetInitialProfiles} to load the initial values in \id{cc}; \id{PrintHeader} to print the heading for the output; -\id{PrintOutput} to retreive and print selected solution values; +\id{PrintOutput} to retrieve and print selected solution values; \id{PrintFinalStats} to print statistics; and \id{check\_flag} to check return values for error conditions. @@ -326,7 +326,7 @@ \subsection{A parallel example: kinFoodWeb\_kry\_bbd\_p}\label{ss:kinFoodWeb_kry The function \id{func\_local} is also passed as the \id{gloc} argument to \id{KINBBDPrecInit}. Since all communication needed for the evaluation of the -local aproximation of $f$ used in building the band-block-diagonal preconditioner +local approximation of $f$ used in building the band-block-diagonal preconditioner is already done for the evaluation of $f$ in \id{func}, a \id{NULL} pointer is passed as the \id{gcomm} argument to \id{KINBBDPrecInit}. diff --git a/doc/kinsol/kin_ex_fortran.tex b/doc/kinsol/kin_ex_fortran.tex index 2c7b263144..c8c1f25c69 100644 --- a/doc/kinsol/kin_ex_fortran.tex +++ b/doc/kinsol/kin_ex_fortran.tex @@ -95,7 +95,7 @@ \subsection{A parallel example: fkinDiagon\_kry\_p}\label{ss:fkinDiagon_kry_p} \id{fkinDiagon\_kry}. Upon successful return from \id{fkinsol}, the solution segment local to the process with id equal to $0$ is printed to unit 6. Finally, the {\kinsol} memory is released and the {\mpi} -environent is terminated. +environment is terminated. For this simple example, no inter-process communication is required to evaluate the nonlinear system function $f$ or the preconditioner. diff --git a/doc/shared/Changelog.rst b/doc/shared/Changelog.rst index 5bf5c04203..bc9d5c1ad9 100644 --- a/doc/shared/Changelog.rst +++ b/doc/shared/Changelog.rst @@ -1999,7 +1999,7 @@ implemented a custom :c:type:`SUNMatrix` will need to at least update their code to set the corresponding ``ops`` structure member, ``matvecsetup``, to ``NULL``. The generic :c:type:`SUNMatrix` API now defines error codes to be returned by -matrix operations. Operations which return an integer flag indiciating +matrix operations. Operations which return an integer flag indicating success/failure may return different values than previously. A new :c:type:`SUNMatrix` (and :c:type:`SUNLinearSolver`) implementation was @@ -2112,7 +2112,7 @@ function signatures have been changed including :c:func:`MRIStepCreate` which now takes an ARKStep memory structure for the fast integration as an input. The reinitialization functions :c:func:`ERKStepReInit`, :c:func:`ARKStepReInit`, -and :c:func:`MRIStepReInit` have been updated to retain the minimum and maxiumum +and :c:func:`MRIStepReInit` have been updated to retain the minimum and maximum step size values from before reinitialization rather than resetting them to the default values. @@ -2138,7 +2138,7 @@ being built. Fixed a memory leak in the PETSc :c:type:`N_Vector` clone function. -Fixed a memeory leak in the ARKODE, CVODE, and IDA F77 interfaces when not using +Fixed a memory leak in the ARKODE, CVODE, and IDA F77 interfaces when not using the default nonlinear solver. Fixed a bug in the ARKStep time-stepping module in ARKODE that would result in @@ -2878,7 +2878,7 @@ with sparse direct solvers. *KINSOL* -The Picard iteration return was chanegd to always return the newest iterate upon +The Picard iteration return was changed to always return the newest iterate upon success. A minor bug in the line search was fixed to prevent an infinite loop when the diff --git a/doc/shared/RecentChanges.rst b/doc/shared/RecentChanges.rst index cc4a9f919c..2002b0ffd6 100644 --- a/doc/shared/RecentChanges.rst +++ b/doc/shared/RecentChanges.rst @@ -6,4 +6,7 @@ Fixed the loading of ARKStep's default first order explicit method. +Fixed a CMake bug regarding usage of missing "print_warning" macro +that was only triggered when the deprecated ``CUDA_ARCH`` option was used. + **Deprecation Notices** diff --git a/doc/shared/nvectors/NVector_CUDA.rst b/doc/shared/nvectors/NVector_CUDA.rst index df27c93672..d81ba70e7c 100644 --- a/doc/shared/nvectors/NVector_CUDA.rst +++ b/doc/shared/nvectors/NVector_CUDA.rst @@ -45,7 +45,7 @@ if the vector owns the execution policies and memory helper objects (i.e., it is in change of freeing the objects), :c:type:`SUNMemory` objects for the vector data on the host and device, pointers to execution policies that control how streaming and reduction kernels are launched, a :c:type:`SUNMemoryHelper` for performing memory -operations, and a private data structure which holds additonal members that +operations, and a private data structure which holds additional members that should not be accessed directly. When instantiated with :c:func:`N_VNew_Cuda`, the underlying data will be @@ -84,7 +84,7 @@ accessor functions: .. c:function:: sunbooleantype N_VIsManagedMemory_Cuda(N_Vector v) - This function returns a boolean flag indiciating if the vector + This function returns a boolean flag indicating if the vector data array is in managed memory or not. @@ -272,7 +272,7 @@ options as the vector they are cloned from while vectors created with **Notes** * When there is a need to access components of an ``N_Vector_Cuda``, ``v``, - it is recommeded to use functions :c:func:`N_VGetDeviceArrayPointer_Cuda()` or + it is recommended to use functions :c:func:`N_VGetDeviceArrayPointer_Cuda()` or :c:func:`N_VGetHostArrayPointer_Cuda()`. However, when using managed memory, the function :c:func:`N_VGetArrayPointer` may also be used. @@ -375,7 +375,7 @@ In total, SUNDIALS provides 3 execution policies: .. cpp:function:: SUNCudaBlockReduceExecPolicy(const size_t blockDim, const cudaStream_t stream = 0) - Is for kernels performing a reduction across indvidual thread blocks. The + Is for kernels performing a reduction across individual thread blocks. The number of threads per block (blockDim) can be set to any valid multiple of the CUDA warp size. The grid size (gridDim) can be set to any value greater than 0. If it is set to 0, then the grid size will be chosen so @@ -384,7 +384,7 @@ In total, SUNDIALS provides 3 execution policies: .. cpp:function:: SUNCudaBlockReduceAtomicExecPolicy(const size_t blockDim, const cudaStream_t stream = 0) - Is for kernels performing a reduction across indvidual thread blocks using + Is for kernels performing a reduction across individual thread blocks using atomic operations. The number of threads per block (blockDim) can be set to any valid multiple of the CUDA warp size. The grid size (gridDim) can be set to any value greater than 0. If it is set to 0, then the grid size diff --git a/doc/shared/nvectors/NVector_HIP.rst b/doc/shared/nvectors/NVector_HIP.rst index f722e9cfac..050e379982 100644 --- a/doc/shared/nvectors/NVector_HIP.rst +++ b/doc/shared/nvectors/NVector_HIP.rst @@ -44,7 +44,7 @@ The content members are the vector length (size), a boolean flag that signals if the vector owns the data (i.e. it is in charge of freeing the data), pointers to vector data on the host and the device, pointers to :cpp:type:`SUNHipExecPolicy` implementations that control how the HIP kernels are launched for streaming and -reduction vector kernels, and a private data structure which holds additonal members +reduction vector kernels, and a private data structure which holds additional members that should not be accessed directly. When instantiated with :c:func:`N_VNew_Hip`, the underlying data will be @@ -81,7 +81,7 @@ accessor functions: .. c:function:: sunbooleantype N_VIsManagedMemory_Hip(N_Vector v) - This function returns a boolean flag indiciating if the vector + This function returns a boolean flag indicating if the vector data array is in managed memory or not. @@ -255,7 +255,7 @@ options as the vector they are cloned from while vectors created with **Notes** * When there is a need to access components of an ``N_Vector_Hip``, ``v``, - it is recommeded to use functions :c:func:`N_VGetDeviceArrayPointer_Hip()` or + it is recommended to use functions :c:func:`N_VGetDeviceArrayPointer_Hip()` or :c:func:`N_VGetHostArrayPointer_Hip()`. However, when using managed memory, the function :c:func:`N_VGetArrayPointer` may also be used. @@ -359,7 +359,7 @@ In total, SUNDIALS provides 4 execution policies: .. cpp:function:: SUNHipBlockReduceExecPolicy(const size_t blockDim, const hipStream_t stream = 0) - Is for kernels performing a reduction across indvidual thread blocks. The + Is for kernels performing a reduction across individual thread blocks. The number of threads per block (blockDim) can be set to any valid multiple of the HIP warp size. The grid size (gridDim) can be set to any value greater than 0. If it is set to 0, then the grid size will be chosen so that there @@ -368,7 +368,7 @@ In total, SUNDIALS provides 4 execution policies: .. cpp:function:: SUNHipBlockReduceAtomicExecPolicy(const size_t blockDim, const hipStream_t stream = 0) - Is for kernels performing a reduction across indvidual thread blocks using + Is for kernels performing a reduction across individual thread blocks using atomic operations. The number of threads per block (blockDim) can be set to any valid multiple of the HIP warp size. The grid size (gridDim) can be set to any value greater than 0. If it is set to 0, then the grid size diff --git a/doc/shared/nvectors/NVector_MPIManyVector.rst b/doc/shared/nvectors/NVector_MPIManyVector.rst index fdaeaf31c9..f7907c446c 100644 --- a/doc/shared/nvectors/NVector_MPIManyVector.rst +++ b/doc/shared/nvectors/NVector_MPIManyVector.rst @@ -27,7 +27,7 @@ construction of distinct NVECTOR modules for each component, that are then combined together to form the NVECTOR_MPIMANYVECTOR. Three potential use cases for this module include: -A. *Heterogenous computational architectures (single-node or multi-node)*: +A. *Heterogeneous computational architectures (single-node or multi-node)*: for data partitioning between different computing resources on a node, architecture-specific subvectors may be created for each partition. For example, a user could create one MPI-parallel component based on diff --git a/doc/shared/nvectors/NVector_MPIPlusX.rst b/doc/shared/nvectors/NVector_MPIPlusX.rst index 88905edd50..d22070eaef 100644 --- a/doc/shared/nvectors/NVector_MPIPlusX.rst +++ b/doc/shared/nvectors/NVector_MPIPlusX.rst @@ -71,7 +71,7 @@ user-callable routines: .. c:function:: N_Vector N_VMake_MPIPlusX(MPI_Comm comm, N_Vector *local_vector, SUNContext sunctx) - This function creates a MPIPlusX vector from an exisiting local + This function creates a MPIPlusX vector from an existing local (i.e. on node) NVECTOR object, and a user-created MPI communicator. The input *comm* should be this user-created MPI communicator. diff --git a/doc/shared/nvectors/NVector_ManyVector.rst b/doc/shared/nvectors/NVector_ManyVector.rst index cded89fd73..5afeccb8dc 100644 --- a/doc/shared/nvectors/NVector_ManyVector.rst +++ b/doc/shared/nvectors/NVector_ManyVector.rst @@ -24,7 +24,7 @@ construction of distinct NVECTOR modules for each component, that are then combined together to form the NVECTOR_MANYVECTOR. Two potential use cases for this flexibility include: -A. *Heterogenous computational architectures*: +A. *Heterogeneous computational architectures*: for data partitioning between different computing resources on a node, architecture-specific subvectors may be created for each partition. For example, a user could create one GPU-accelerated component based diff --git a/doc/shared/nvectors/NVector_OpenMP.rst b/doc/shared/nvectors/NVector_OpenMP.rst index 4f84694770..2947c403db 100644 --- a/doc/shared/nvectors/NVector_OpenMP.rst +++ b/doc/shared/nvectors/NVector_OpenMP.rst @@ -276,7 +276,7 @@ options as the vector they are cloned from while vectors created with loop than it is to use ``NV_Ith_OMP(v,i)`` within the loop. * :c:func:`N_VNewEmpty_OpenMP` and :c:func:`N_VMake_OpenMP` set the field - *own_data* to ``SUNFALSE``. The implemenation of :c:func:`N_VDestroy` will + *own_data* to ``SUNFALSE``. The implementation of :c:func:`N_VDestroy` will not attempt to free the pointer data for any ``N_Vector`` with *own_data* set to ``SUNFALSE``. In such a case, it is the user's responsibility to deallocate the data pointer. diff --git a/doc/shared/nvectors/NVector_Operations.rst b/doc/shared/nvectors/NVector_Operations.rst index e184b829de..475abc4a84 100644 --- a/doc/shared/nvectors/NVector_Operations.rst +++ b/doc/shared/nvectors/NVector_Operations.rst @@ -104,7 +104,7 @@ operations below. Returns a pointer to a ``sunrealtype`` array from the ``N_Vector`` *v*. Note that this assumes that the internal data in the ``N_Vector`` is a contiguous array of ``sunrealtype`` and is - accesible from the CPU. + accessible from the CPU. This routine is only used in the solver-specific interfaces to the dense and banded diff --git a/doc/shared/nvectors/NVector_PETSc.rst b/doc/shared/nvectors/NVector_PETSc.rst index f7284ae7f8..3d0983e149 100644 --- a/doc/shared/nvectors/NVector_PETSc.rst +++ b/doc/shared/nvectors/NVector_PETSc.rst @@ -162,7 +162,7 @@ options as the vector they are cloned from while vectors created with **Notes** * When there is a need to access components of an ``N_Vector_Petsc v``, it - is recommeded to extract the PETSc vector via ``x_vec = N_VGetVector_Petsc(v);`` + is recommended to extract the PETSc vector via ``x_vec = N_VGetVector_Petsc(v);`` and then access components using appropriate PETSc functions. * The functions :c:func:`N_VNewEmpty_Petsc` and :c:func:`N_VMake_Petsc`, set the diff --git a/doc/shared/nvectors/NVector_Trilinos.rst b/doc/shared/nvectors/NVector_Trilinos.rst index c891f07ab6..d5b404ea58 100644 --- a/doc/shared/nvectors/NVector_Trilinos.rst +++ b/doc/shared/nvectors/NVector_Trilinos.rst @@ -104,7 +104,7 @@ The module NVECTOR_TRILINOS provides the following additional user-callable rout in SUNDIALS. * When there is a need to access components of an ``N_Vector_Trilinos v``, - it is recommeded to extract the Trilinos vector object via ``x_vec = + it is recommended to extract the Trilinos vector object via ``x_vec = N_VGetVector_Trilinos(v)`` and then access components using the appropriate Trilinos functions. diff --git a/doc/shared/sunadaptcontroller/SUNAdaptController_Soderlind.rst b/doc/shared/sunadaptcontroller/SUNAdaptController_Soderlind.rst index 6c8a77bcb8..0c1b0cc620 100644 --- a/doc/shared/sunadaptcontroller/SUNAdaptController_Soderlind.rst +++ b/doc/shared/sunadaptcontroller/SUNAdaptController_Soderlind.rst @@ -254,7 +254,7 @@ also provides the following additional user-callable routines: h' = h_n \varepsilon_n^{-\hat{k}_1/(p+1)} \left(\frac{\varepsilon_n}{\varepsilon_{n-1}}\right)^{-\hat{k}_2/(p+1)}. The inputs to this function correspond to the values of :math:`\hat{k}_1` and :math:`\hat{k}_2`, - which are internally transformed into the Soderlind coeficients :math:`k_1 = \hat{k}_1+\hat{k}_2` + which are internally transformed into the Soderlind coefficients :math:`k_1 = \hat{k}_1+\hat{k}_2` and :math:`k_2 = -\hat{k}_2`. :param C: the SUNAdaptController_Soderlind object. @@ -300,7 +300,7 @@ also provides the following additional user-callable routines: h' = h_n \varepsilon_n^{-\hat{k}_1/(p+1)} \left(\frac{\varepsilon_n}{\varepsilon_{n-1}}\right)^{-\hat{k}_2/(p+1)} \left(\frac{h_n}{h_{n-1}}\right). The inputs to this function correspond to the values of :math:`\hat{k}_1` and :math:`\hat{k}_2`, - which are internally transformed into the Soderlind coeficients :math:`k_1 = \hat{k}_1+\hat{k}_2`, + which are internally transformed into the Soderlind coefficients :math:`k_1 = \hat{k}_1+\hat{k}_2`, :math:`k_2 = -\hat{k}_2`, and :math:`k_4=1`. :param C: the SUNAdaptController_Soderlind object. diff --git a/doc/shared/sundials.bib b/doc/shared/sundials.bib index 1f9d585a91..b000f2c3dc 100644 --- a/doc/shared/sundials.bib +++ b/doc/shared/sundials.bib @@ -1880,6 +1880,14 @@ @article{Gust:94 doi = {10.1145/198429.198437} } +@techreport{HEJ:76, + title = {User's guide for {DVERK}: {A} subroutine for solving non-stiff {ODE}'s}, + author = {Hull, TE and Enright, WH and Jackson, KR}, + year = {1976}, + number = {100}, + institution={University of Toronto. Department of Computer Science} +} + @article{Jay:21, title = {Symplecticness conditions of some low order partitioned methods for non-autonomous Hamiltonian systems}, author = {Jay, Laurent O}, @@ -2133,17 +2141,6 @@ @article{Sof:04 doi = {10.1016/j.mcm.2005.01.010} } -@article{Ver:78, - author = {Verner, J.H}, - title = {Explicit Runge-Kutta methods with estimates of the local truncation error}, - journal = {SIAM Journal of Numerical Analysis}, - volume = {15}, - number = {4}, - pages = {772-790}, - year = {1978}, - doi = {10.1137/0715051} -} - @article{Ver:10, author = {Verner, J.H}, title = {Numerically optimal {Runge–Kutta} pairs with interpolants}, diff --git a/doc/shared/sundials/Errors.rst b/doc/shared/sundials/Errors.rst index 20cbcc5405..ce273ea76e 100644 --- a/doc/shared/sundials/Errors.rst +++ b/doc/shared/sundials/Errors.rst @@ -18,7 +18,7 @@ Error Checking .. versionadded:: 7.0.0 Until version 7.0.0, error reporting and handling was inconsistent throughout SUNDIALS. Starting with version 7.0.0 all of SUNDIALS (the core, implementations of core modules, and -packages) reports error mesages through the :c:type:`SUNLogger` API. Furthermore, functions in the +packages) reports error messages through the :c:type:`SUNLogger` API. Furthermore, functions in the SUNDIALS core API (i.e., ``SUN`` or ``N_V`` functions only) either return a :c:type:`SUNErrCode`, or (if they don't return a :c:type:`SUNErrCode`) they internally record an error code (if an error occurs) within the :c:type:`SUNContext` for the execution stream. This "last error" is accessible @@ -45,17 +45,17 @@ Thus, in user code, SUNDIALS core API functions can be checked for errors in one length = 2; v = N_VNew_Serial(length, sunctx); sunerr = SUNContext_GetLastError(sunctx); - if (sunerr) { /* an error occured, do something */ } + if (sunerr) { /* an error occurred, do something */ } // If the function returns a SUNErrCode, we can check it directly sunerr = N_VLinearCombination(...); - if (sunerr) { /* an error occured, do something */ } + if (sunerr) { /* an error occurred, do something */ } // Another function that does not return a SUNErrCode. dotprod = N_VDotProd(...); SUNContext_GetLastError(sunctx); if (sunerr) { - /* an error occured, do something */ + /* an error occurred, do something */ } else { print("dotprod = %.2f\n", dotprod); } @@ -114,11 +114,11 @@ The error handlers provided in SUNDIALS are: Logs the error that occurred using the :c:type:`SUNLogger` from ``sunctx``. This is the default error handler. - :param line: the line number at which the error occured - :param func: the function in which the error occured - :param file: the file in which the error occured + :param line: the line number at which the error occurred + :param func: the function in which the error occurred + :param file: the file in which the error occurred :param msg: the message to log, if this is ``NULL`` then the default error message for the error code will be used - :param err_code: the error code for the error that occured + :param err_code: the error code for the error that occurred :param err_user_data: the user pointer provided to :c:func:`SUNContext_PushErrHandler` :param sunctx: pointer to a valid :c:type:`SUNContext` object @@ -128,13 +128,13 @@ The error handlers provided in SUNDIALS are: const char* msg, SUNErrCode err_code, \ void* err_user_data, SUNContext sunctx) - Logs the error and aborts the program if an error occured. + Logs the error and aborts the program if an error occurred. - :param line: the line number at which the error occured - :param func: the function in which the error occured - :param file: the file in which the error occured + :param line: the line number at which the error occurred + :param func: the function in which the error occurred + :param file: the file in which the error occurred :param msg: this parameter is ignored - :param err_code: the error code for the error that occured + :param err_code: the error code for the error that occurred :param err_user_data: the user pointer provided to :c:func:`SUNContext_PushErrHandler` :param sunctx: pointer to a valid :c:type:`SUNContext` object @@ -145,13 +145,13 @@ The error handlers provided in SUNDIALS are: const char* msg, SUNErrCode err_code, \ void* err_user_data, SUNContext sunctx) - Logs the error and calls ``MPI_Abort`` if an error occured. + Logs the error and calls ``MPI_Abort`` if an error occurred. - :param line: the line number at which the error occured - :param func: the function in which the error occured - :param file: the file in which the error occured + :param line: the line number at which the error occurred + :param func: the function in which the error occurred + :param file: the file in which the error occurred :param msg: this parameter is ignored - :param err_code: the error code for the error that occured + :param err_code: the error code for the error that occurred :param err_user_data: the user pointer provided to :c:func:`SUNContext_PushErrHandler` :param sunctx: pointer to a valid :c:type:`SUNContext` object diff --git a/doc/shared/sundials/GPU.rst b/doc/shared/sundials/GPU.rst index 8607643adf..e3c12bb41c 100644 --- a/doc/shared/sundials/GPU.rst +++ b/doc/shared/sundials/GPU.rst @@ -64,7 +64,7 @@ data partitioning (achievable with the NVECTOR_MANYVECTOR, see programming environments they support, and what class of memory they support (unmanaged or UVM). Users may also supply their own GPU-enabled :c:type:`N_Vector`, :c:type:`SUNMatrix`, or :c:type:`SUNLinearSolver` - implementation, and the capabilties will be leveraged since SUNDIALS operates + implementation, and the capabilities will be leveraged since SUNDIALS operates on data through these APIs. .. ifconfig:: package_name != 'kinsol' @@ -77,7 +77,7 @@ data partitioning (achievable with the NVECTOR_MANYVECTOR, see programming environments they support, and what class of memory they support (unmanaged or UVM). Users may also supply their own GPU-enabled :c:type:`N_Vector`, :c:type:`SUNMatrix`, :c:type:`SUNLinearSolver`, or - :c:type:`SUNNonlinearSolver` implementation, and the capabilties will be + :c:type:`SUNNonlinearSolver` implementation, and the capabilities will be leveraged since SUNDIALS operates on data through these APIs. In addition, SUNDIALS provides a memory management helper module @@ -174,7 +174,7 @@ accelerated SUNDIALS are: #. Write user-supplied functions so that they use data only in the device memory space (again, unless an atypical data partitioning is used). A few examples of these functions are the right-hand side evaluation function, the Jacobian - evalution function, or the preconditioner evaulation function. In the context + evaluation function, or the preconditioner evaluation function. In the context of CUDA and the right-hand side function, one way a user might ensure data is accessed on the device is, for example, calling a CUDA kernel, which does all of the computation, from a CPU function which simply extracts the underlying diff --git a/doc/shared/sundials/Install.rst b/doc/shared/sundials/Install.rst index d666fc7b29..d75eca6e9e 100644 --- a/doc/shared/sundials/Install.rst +++ b/doc/shared/sundials/Install.rst @@ -31,7 +31,7 @@ by cloning the `SUNDIALS GitHub repository `_ SUNDIALS release compressed archives (``.tar.gz``) from the SUNDIALS `website `_. -The compressed archives allow for downloading of indvidual SUNDIALS packages. +The compressed archives allow for downloading of individual SUNDIALS packages. The name of the distribution archive is of the form ``SOLVER-7.1.0.tar.gz``, where ``SOLVER`` is one of: ``sundials``, ``cvode``, ``cvodes``, ``arkode``, ``ida``, ``idas``, or ``kinsol``, and ``7.1.0`` @@ -187,7 +187,7 @@ Using CMake with the ``cmake-gui`` GUI follows a similar process: #. The first time you click ``Configure``, make sure to pick the appropriate generator (the following will assume generation of Unix - Makfiles). + Makefiles). #. New values are highlighted in red @@ -591,7 +591,7 @@ illustration only. Default: ``OFF`` .. warning:: There is a known issue with MSYS/gfortran and SUNDIALS shared libraries - that causes linking the Fortran interfaces to fail when buidling SUNDIALS. For + that causes linking the Fortran interfaces to fail when building SUNDIALS. For now the work around is to only build with static libraries when using MSYS with gfortran on Windows. @@ -612,7 +612,7 @@ illustration only. .. cmakeoption:: SUNDIALS_BUILD_WITH_MONITORING - Build SUNDIALS with capabilties for fine-grained monitoring of solver progress + Build SUNDIALS with capabilities for fine-grained monitoring of solver progress and statistics. This is primarily useful for debugging. Default: OFF @@ -624,7 +624,7 @@ illustration only. .. cmakeoption:: SUNDIALS_BUILD_WITH_PROFILING - Build SUNDIALS with capabilties for fine-grained profiling. + Build SUNDIALS with capabilities for fine-grained profiling. This requires POSIX timers or the Windows ``profileapi.h`` timers. Default: OFF @@ -669,8 +669,8 @@ illustration only. .. cmakeoption:: SUNDIALS_GINKGO_BACKENDS - Semi-colon separated list of Ginkgo target architecutres/executors to build for. - Options currenty supported are REF (the Ginkgo reference executor), OMP, CUDA, HIP, and SYCL. + Semi-colon separated list of Ginkgo target architectures/executors to build for. + Options currently supported are REF (the Ginkgo reference executor), OMP, CUDA, HIP, and SYCL. Default: "REF;OMP" @@ -901,7 +901,7 @@ illustration only. .. cmakeoption:: PETSC_INCLUDES - Semi-colon separated list of PETSc include directroies. Unless provided by + Semi-colon separated list of PETSc include directories. Unless provided by the user, this is autopopulated based on the PETSc installation found in ``PETSC_DIR``. @@ -935,7 +935,7 @@ illustration only. Default: ``OFF`` - .. note:: See additional information on building wtih + .. note:: See additional information on building with SuperLU_DIST enabled in :numref:`Installation.CMake.ExternalLibraries`. .. cmakeoption:: SUPERLUDIST_DIR @@ -1264,7 +1264,7 @@ CUDA (for NVIDIA devices), HIP (for AMD devices) and SYCL/DPC++ (for Intel devic supported hardware). To enable Ginkgo in SUNDIALS, set the :cmakeop:`ENABLE_GINKGO` to ``ON`` and provide the path to the root of the Ginkgo installation in :cmakeop:`Ginkgo_DIR`. Additionally, :cmakeop:`SUNDIALS_GINKGO_BACKENDS` must be set to a list of Ginkgo target -architecutres/executors. E.g., +architectures/executors. E.g., .. code-block:: bash diff --git a/doc/shared/sunlinsol/SUNLinSol_API.rst b/doc/shared/sunlinsol/SUNLinSol_API.rst index 6650b88d20..9bc00e30da 100644 --- a/doc/shared/sunlinsol/SUNLinSol_API.rst +++ b/doc/shared/sunlinsol/SUNLinSol_API.rst @@ -900,7 +900,7 @@ SUNLinSol implementations. As SUNDIALS packages utilize generic SUNLinSol modules they may naturally leverage user-supplied ``SUNLinearSolver`` implementations, thus there exist a wide range of possible linear solver combinations. Some intended use cases for both the -SUNDIALS-provided and user-supplied SUNLinSol modules are discussd in the +SUNDIALS-provided and user-supplied SUNLinSol modules are discussed in the sections below. @@ -949,7 +949,7 @@ Matrix-based iterative linear solvers (reusing :math:`A`) Matrix-based iterative linear solver modules require a matrix and compute an inexact solution to the linear system *defined by the matrix*. This -matrix will be updated infrequently and resued across multiple solves +matrix will be updated infrequently and reused across multiple solves to amortize the cost of matrix construction. As in the direct linear solver case, only thin SUNMATRIX and SUNLinSol wrappers for the underlying matrix and linear solver structures need to be created to utilize diff --git a/doc/shared/sunlinsol/SUNLinSol_Ginkgo.rst b/doc/shared/sunlinsol/SUNLinSol_Ginkgo.rst index 34fd25c82d..5b1a4e0a3d 100644 --- a/doc/shared/sunlinsol/SUNLinSol_Ginkgo.rst +++ b/doc/shared/sunlinsol/SUNLinSol_Ginkgo.rst @@ -45,9 +45,9 @@ Using SUNLINEARSOLVER_GINKGO After choosing a compatible ``N_Vector`` (see :numref:`SUNMatrix.Ginkgo.CompatibleNVectors`) and creating a Ginkgo-enabled ``SUNMatrix`` (see :numref:`SUNMatrix.Ginkgo`) to use the SUNLINEARSOLVER_GINKGO module, we first create a Ginkgo stopping criteria object. Importantly, the ``sundials::ginkgo::DefaultStop`` class provided -by SUNDIALS implements a stopping critierion that matches the default SUNDIALS stopping critierion. +by SUNDIALS implements a stopping criterion that matches the default SUNDIALS stopping criterion. Namely, it checks if the max iterations (5 by default) were reached or if the absolute residual -norm was below a speicified tolerance. The critierion can be created just like any other +norm was below a specified tolerance. The criterion can be created just like any other Ginkgo stopping criteria: .. code-block:: cpp @@ -59,7 +59,7 @@ Ginkgo stopping criteria: but it is optional. However, to use the Ginkgo multigrid or cbgmres linear solvers, different Ginkgo criterion must be used. -Once we have created our stopping critierion, we create a Ginkgo solver factory object and +Once we have created our stopping criterion, we create a Ginkgo solver factory object and wrap it in a :cpp:type:`sundials::ginkgo::LinearSolver` object. In this example, we create a Ginkgo conjugate gradient solver: @@ -185,7 +185,7 @@ In this section we list the public API of the :cpp:type:`sundials::ginkgo::Linea .. cpp:function:: gko::LinOp* Solve(N_Vector b, N_Vector x, sunrealtype tol) - Solve the linear system Ax = b to the specificed tolerance. + Solve the linear system Ax = b to the specified tolerance. :param b: the right-hand side vector :param x: the solution vector diff --git a/doc/shared/sunlinsol/SUNLinSol_SuperLUDIST.rst b/doc/shared/sunlinsol/SUNLinSol_SuperLUDIST.rst index 177d9558b2..462c0c7c7e 100644 --- a/doc/shared/sunlinsol/SUNLinSol_SuperLUDIST.rst +++ b/doc/shared/sunlinsol/SUNLinSol_SuperLUDIST.rst @@ -164,7 +164,7 @@ information: * ``berr`` -- the componentwise relative backward error of the computed solution, -* ``grid`` -- pointer to the SuperLU_DIST structure that strores the 2D process grid +* ``grid`` -- pointer to the SuperLU_DIST structure that stores the 2D process grid * ``lu`` -- pointer to the SuperLU_DIST structure that stores the distributed ``L`` and ``U`` factors, @@ -172,7 +172,7 @@ information: * ``scaleperm`` -- pointer to the SuperLU_DIST structure that stores vectors describing the transformations done to the matrix ``A``, -* ``options`` -- pointer to the SuperLU_DIST stucture which contains options that control +* ``options`` -- pointer to the SuperLU_DIST structure which contains options that control how the linear system is factorized and solved, * ``solve`` -- pointer to the SuperLU_DIST solve structure, diff --git a/doc/shared/sunlinsol/SUNLinSol_cuSolverSp.rst b/doc/shared/sunlinsol/SUNLinSol_cuSolverSp.rst index 23894bd7ef..58ce79681d 100644 --- a/doc/shared/sunlinsol/SUNLinSol_cuSolverSp.rst +++ b/doc/shared/sunlinsol/SUNLinSol_cuSolverSp.rst @@ -125,7 +125,7 @@ In addition, the module provides the following user-callable routines: The function ``SUNLinSol_cuSolverSp_batchQR_GetDeviceSpace`` returns the cuSOLVER batch QR method internal buffer size, in bytes, in the argument ``cuSolverInternal`` and the cuSOLVER - batch QR workspace buffer size, in bytes, in the agrument + batch QR workspace buffer size, in bytes, in the argument ``cuSolverWorkspace``. The size of the internal buffer is proportional to the number of matrix blocks while the size of the workspace is almost independent of the number of blocks. diff --git a/doc/shared/sunmatrix/SUNMatrix_Description.rst b/doc/shared/sunmatrix/SUNMatrix_Description.rst index 11f69ab896..fe17e6f3f2 100644 --- a/doc/shared/sunmatrix/SUNMatrix_Description.rst +++ b/doc/shared/sunmatrix/SUNMatrix_Description.rst @@ -207,7 +207,7 @@ set and all operations are copied when cloning a matrix. SUNMATRIX_CUSPARSE CUDA sparse CSR matrix SUNMATRIX_CUSTOM User-provided custom matrix SUNMATRIX_DENSE Dense :math:`M \times N` matrix - SUNMATRIX_GINKGO SUNMatrix wraper for Ginkgo matrices + SUNMATRIX_GINKGO SUNMatrix wrapper for Ginkgo matrices SUNMATRIX_MAGMADENSE Dense :math:`M \times N` matrix SUNMATRIX_ONEMKLDENSE oneMKL dense :math:`M \times N` matrix SUNMATRIX_SLUNRLOC SUNMatrix wrapper for SuperLU_DIST SuperMatrix diff --git a/doc/shared/sunmatrix/SUNMatrix_KokkosDense.rst b/doc/shared/sunmatrix/SUNMatrix_KokkosDense.rst index 899782dcbf..bbcadfe20c 100644 --- a/doc/shared/sunmatrix/SUNMatrix_KokkosDense.rst +++ b/doc/shared/sunmatrix/SUNMatrix_KokkosDense.rst @@ -142,7 +142,7 @@ class. :param rows: number of matrix rows :param cols: number of matrix columns - :param ex: an execuation space + :param ex: an execution space :param sunctx: the SUNDIALS simulation context object (:c:type:`SUNContext`) .. cpp:function:: DenseMatrix(size_type blocks, size_type block_rows, \ @@ -166,7 +166,7 @@ class. :param blocks: number of matrix blocks :param block_rows: number of rows in a block :param block_cols: number of columns in a block - :param ex: an execuation space + :param ex: an execution space :param sunctx: the SUNDIALS simulation context object (:c:type:`SUNContext`) .. cpp:function:: DenseMatrix(DenseMatrix&& that_matrix) noexcept diff --git a/doc/shared/sunmemory/SUNMemory_Description.rst b/doc/shared/sunmemory/SUNMemory_Description.rst index 3499367c7b..2efc154aa4 100644 --- a/doc/shared/sunmemory/SUNMemory_Description.rst +++ b/doc/shared/sunmemory/SUNMemory_Description.rst @@ -70,7 +70,7 @@ This API consists of three new SUNDIALS types: :c:type:`SUNMemoryType`, .. c:enumerator:: SUNMEMTYPE_PINNED - Page-locked memory accesible on the host + Page-locked memory accessible on the host .. c:enumerator:: SUNMEMTYPE_DEVICE diff --git a/doc/shared/sunnonlinsol/SUNNonlinSol_API.rst b/doc/shared/sunnonlinsol/SUNNonlinSol_API.rst index d169c83001..4715ee8e29 100644 --- a/doc/shared/sunnonlinsol/SUNNonlinSol_API.rst +++ b/doc/shared/sunnonlinsol/SUNNonlinSol_API.rst @@ -122,7 +122,7 @@ initialization (:c:func:`SUNNonlinSolInitialize`), setup * *mem* -- the SUNDIALS integrator memory structure. **Return value:** - The return value is zero for a successul solve, a positive value + The return value is zero for a successful solve, a positive value for a recoverable error (i.e., the solve failed and the integrator should reduce the step size and reattempt the step), and a negative value for an unrecoverable error (i.e., the solve failed the and @@ -357,7 +357,7 @@ module have types defined in the header file * *mem* -- is the SUNDIALS integrator memory structure. **Return value:** - The return value is zero for a successul solve, a positive value for + The return value is zero for a successful solve, a positive value for a recoverable error, and a negative value for an unrecoverable error. **Notes:** @@ -383,7 +383,7 @@ module have types defined in the header file * *mem* -- is the SUNDIALS integrator memory structure. **Return value:** - The return value is zero for a successul solve, a positive value for + The return value is zero for a successful solve, a positive value for a recoverable error, and a negative value for an unrecoverable error. **Notes:** @@ -415,7 +415,7 @@ module have types defined in the header file * *mem* -- is the SUNDIALS integrator memory structure. **Return value:** - The return value is zero for a successul solve, a positive value for + The return value is zero for a successful solve, a positive value for a recoverable error, and a negative value for an unrecoverable error. **Notes:** diff --git a/doc/shared/sunnonlinsol/SUNNonlinSol_PetscSNES.rst b/doc/shared/sunnonlinsol/SUNNonlinSol_PetscSNES.rst index e9d9c856f1..1cb332300d 100644 --- a/doc/shared/sunnonlinsol/SUNNonlinSol_PetscSNES.rst +++ b/doc/shared/sunnonlinsol/SUNNonlinSol_PetscSNES.rst @@ -25,7 +25,7 @@ configured to use PETSc. Instructions on how to do this are given in SUNNonlinSol_PetscSNES module, include the header file ``sunnonlinsol/sunnonlinsol_petscsnes.h``. The library to link to is ``libsundials_sunnonlinsolpetsc.lib`` where ``.lib`` is typically ``.so`` for -shared libaries and ``.a`` for static libraries. Users of the +shared libraries and ``.a`` for static libraries. Users of the SUNNonlinSol_PetscSNES module should also see :numref:`NVectors.NVPETSc` which discusses the NVECTOR interface to the PETSc ``Vec`` API. @@ -184,4 +184,4 @@ These entries of the *content* field contain the following information: * ``r`` -- the nonlinear residual, * ``y`` -- wrapper for PETSc vectors used in the system function, * ``f`` -- wrapper for PETSc vectors used in the system function, -* ``Sys`` -- nonlinear system definining function. +* ``Sys`` -- nonlinear system defining function. diff --git a/doc/sundials/ug.tex b/doc/sundials/ug.tex index aa3d25945c..a7478dc4e8 100644 --- a/doc/sundials/ug.tex +++ b/doc/sundials/ug.tex @@ -486,7 +486,7 @@ \setlength{\leftmargin}{\labelwidth+\labelsep}}} {\end{list}} %%----------------------------------------------------- -%% Underlying list environemnt for function definitions +%% Underlying list environment for function definitions %%----------------------------------------------------- \newenvironment{Ventry}[1][\quad] {\begin{list}{}{ @@ -652,7 +652,7 @@ \makeatletter \long\def\addDepName#1{\def\@tempa{#1}\ifx\@tempa\empty\item[Deprecated Name]{None}\else\item[Deprecated Name]{For backward compatibility, the wrapper - function \id{#1} with idential input and output arguments is also + function \id{#1} with identical input and output arguments is also provided.}\fi} \makeatother diff --git a/doc/superbuild/source/contributing/index.rst b/doc/superbuild/source/contributing/index.rst index 947443d9f5..4bc71a6bc5 100644 --- a/doc/superbuild/source/contributing/index.rst +++ b/doc/superbuild/source/contributing/index.rst @@ -16,7 +16,7 @@ Contributing ============ -There are two primary ways of contributing to SUNDIALS. The first way is by particpating +There are two primary ways of contributing to SUNDIALS. The first way is by participating in the development of SUNDIALS directly through contributions of code to the primary `SUNDIALS repository `_. This is the best way to contribute bug fixes and minor improvements. At this time, the SUNDIALS team does not have the resources diff --git a/doc/superbuild/source/developers/appendix/GitCheatSheet.rst b/doc/superbuild/source/developers/appendix/GitCheatSheet.rst index 3e3c7f2a5c..1f7d86fa7d 100644 --- a/doc/superbuild/source/developers/appendix/GitCheatSheet.rst +++ b/doc/superbuild/source/developers/appendix/GitCheatSheet.rst @@ -248,7 +248,7 @@ the :ref:`Workflow` section. reordering, squashing, updating commit messages, etc.) before pushing to the remote repository. - Rebase the commited but not pushed changes on the current branch and execute + Rebase the committed but not pushed changes on the current branch and execute a given command (``cmd``) between each step in the rebase .. code-block:: none diff --git a/doc/superbuild/source/developers/getting_started/Workflow.rst b/doc/superbuild/source/developers/getting_started/Workflow.rst index 5da388e53a..52967d44b8 100644 --- a/doc/superbuild/source/developers/getting_started/Workflow.rst +++ b/doc/superbuild/source/developers/getting_started/Workflow.rst @@ -149,7 +149,7 @@ branches and the ``master`` for maintenance branches. work. #. During the development cycle it is a good practice to periodically push local - commits to the remote repo. To push your locally commited changes use: + commits to the remote repo. To push your locally committed changes use: .. code-block:: none @@ -259,7 +259,7 @@ Manually resolve the conflicts in an editor: $ git rebase --continue -#. If desired, push the updated local brach to the remote repo with +#. If desired, push the updated local branch to the remote repo with .. code-block:: none @@ -293,7 +293,7 @@ merge tool: $ git rebase --continue -#. If desired, push the updated local brach to the remote repo with +#. If desired, push the updated local branch to the remote repo with .. code-block:: none diff --git a/doc/superbuild/source/developers/style_guide/SourceCode.rst b/doc/superbuild/source/developers/style_guide/SourceCode.rst index 5a05602867..ba5a9c4ff8 100644 --- a/doc/superbuild/source/developers/style_guide/SourceCode.rst +++ b/doc/superbuild/source/developers/style_guide/SourceCode.rst @@ -17,7 +17,7 @@ Naming ====== -All exported symbols that will be publically available must be namespaced +All exported symbols that will be publicly available must be namespaced appropriately! * ``SUN_`` or ``SUNDIALS_`` for macros diff --git a/doc/superbuild/source/developers/testing/Answers.rst b/doc/superbuild/source/developers/testing/Answers.rst index ecefcfbd4d..6d64f7e4ea 100644 --- a/doc/superbuild/source/developers/testing/Answers.rst +++ b/doc/superbuild/source/developers/testing/Answers.rst @@ -32,7 +32,7 @@ Due to difference in microarichtectures and the nature of floating point arithme possible that the output generated on one machine may differ from the output generated on another. As such, we specify that the the answer files that are embedded in ``examples/`` (the ``.out`` files) should match what is produced on the Jenkins CI machine. We also have a `separate git -repostiory `_ which holds answers for other machines, +repository `_ which holds answers for other machines, such as the GitHub Actions virtual machines. diff --git a/doc/superbuild/source/developers/testing/CI.rst b/doc/superbuild/source/developers/testing/CI.rst index 00ded30a77..a71b4e5930 100644 --- a/doc/superbuild/source/developers/testing/CI.rst +++ b/doc/superbuild/source/developers/testing/CI.rst @@ -94,7 +94,7 @@ environment so that its buildcache can be leveraged. We also maintain two containers for the {int32, double} pair that are built automatically (in a GitHub action) every week against the latest Spack develop commit. This allows us to test against -the latest versions of dependencies reguarly and detect interface breakages. +the latest versions of dependencies regularly and detect interface breakages. GitLab CI Testing @@ -264,7 +264,7 @@ These submodules work in conjunction with ``spack_packages/sundials/package.py`` to configure and build any third-party libraries needed by the SUNDIALS configuration and generates an initial CMake cache file for building SUNDIALS. Other packages can be added to ``spack_packages//package.py`` -if the default Spack package needs to be overriden. We do this currently for +if the default Spack package needs to be overridden. We do this currently for Caliper, as we need a newer version than in the Spack commit currently used. Updating Spack diff --git a/examples/arkode/CXX_parallel/ark_brusselator1D.h b/examples/arkode/CXX_parallel/ark_brusselator1D.h index b95390bc4a..8f4b873e9e 100644 --- a/examples/arkode/CXX_parallel/ark_brusselator1D.h +++ b/examples/arkode/CXX_parallel/ark_brusselator1D.h @@ -148,7 +148,7 @@ struct UserData N_Vector vmask; N_Vector wmask; - /* problem paramaters */ + /* problem parameters */ int nvar; /* number of species */ long int nx; /* number of intervals globally */ int nxl; /* number of intervals locally */ @@ -197,7 +197,7 @@ typedef struct SUNNonlinearSolver local_nls; }* TaskLocalNewton_Content; -/* Content accessor macors */ +/* Content accessor macros */ #define GET_NLS_CONTENT(NLS) ((TaskLocalNewton_Content)(NLS->content)) #define LOCAL_NLS(NLS) (GET_NLS_CONTENT(NLS)->local_nls) diff --git a/examples/arkode/CXX_parallel/ark_brusselator1D_task_local_nls.cpp b/examples/arkode/CXX_parallel/ark_brusselator1D_task_local_nls.cpp index 8bee143d0b..b5029ca9a5 100644 --- a/examples/arkode/CXX_parallel/ark_brusselator1D_task_local_nls.cpp +++ b/examples/arkode/CXX_parallel/ark_brusselator1D_task_local_nls.cpp @@ -22,7 +22,7 @@ * w_t = -c * w_x + (B - w) / ep - w * u * * for t in [0, 10], x in [0, xmax] with periodic boundary conditions. The - * initial condition is a Gaussian pertubation of the steady state + * initial condition is a Gaussian perturbation of the steady state * solution without advection * * u(0,x) = k1 * A / k4 + p(x) @@ -1730,7 +1730,7 @@ void InputError(char* name) * opt == 0 means the function allocates memory and returns a * pointer so check if a NULL pointer was returned * opt == 1 means the function returns an integer where a - * value < 0 indicates an error occured + * value < 0 indicates an error occurred * --------------------------------------------------------------*/ int check_retval(void* returnvalue, const char* funcname, int opt) { diff --git a/examples/arkode/CXX_parallel/ark_diffusion_reaction_p.cpp b/examples/arkode/CXX_parallel/ark_diffusion_reaction_p.cpp index 63108a9bd2..5643211620 100644 --- a/examples/arkode/CXX_parallel/ark_diffusion_reaction_p.cpp +++ b/examples/arkode/CXX_parallel/ark_diffusion_reaction_p.cpp @@ -16,7 +16,7 @@ * u_t = Dux u_xx + Duy u_yy + A + u * u * v - (B + 1) * u * v_t = Dvx u_xx + Dvy u_yy + B * u - u * u * v * - * where u and v represent the concentrations of the two chemcial species, the + * where u and v represent the concentrations of the two chemical species, the * diffusion rates are Dux = Duy = Dvx = Dvy = 1e-3, and the species with * constant concentration over time are A = 1 and B = 3. * @@ -159,7 +159,7 @@ struct UserData bool reaction = true; // -------------------------- - // Discretization parameteres + // Discretization parameters // -------------------------- // Global and local number of nodes in the x and y directions @@ -228,7 +228,7 @@ struct UserData sunrealtype* SWsend = NULL; sunrealtype* NErecv = NULL; - // Recieve and send requests + // Receive and send requests MPI_Request reqRW, reqRE, reqRS, reqRN; MPI_Request reqSW, reqSE, reqSS, reqSN; MPI_Request reqRC, reqSC; @@ -307,7 +307,7 @@ struct UserData N_Vector diag = NULL; // inverse of Jacobian diagonal // --------------- - // Ouput variables + // Output variables // --------------- int output = 1; // 0 = no output, 1 = output stats, 2 = write to disk @@ -597,7 +597,7 @@ int main(int argc, char* argv[]) sunrealtype dTout = udata.tf / udata.nout; sunrealtype tout = dTout; - // Inital output + // Initial output flag = OpenOutput(&udata); if (check_flag(&flag, "OpenOutput", 1)) { return 1; } @@ -2349,14 +2349,14 @@ static void InputHelp() << " --mri-cvode-local : use MRI with CVODE task-local stepper" << endl; cout << " --rtol_imex : IMEX relative tolerance" << endl; - cout << " --atol_imex : IMEX absoltue tolerance" << endl; + cout << " --atol_imex : IMEX absolute tolerance" << endl; cout << " --h_imex : IMEX fixed step size" << endl; cout << " --order_imex : IMEX method order" << endl; cout << " --rtol_slow : MRI slow relative tolerance" << endl; - cout << " --atol_slow : MRI slow absoltue tolerance" << endl; + cout << " --atol_slow : MRI slow absolute tolerance" << endl; cout << " --h_slow : MRI slow step size" << endl; cout << " --rtol_fast : MRI fast relative tolerance" << endl; - cout << " --atol_fast : MRI fast absoltue tolerance" << endl; + cout << " --atol_fast : MRI fast absolute tolerance" << endl; cout << " --h_fast : MRI fast step size" << endl; cout << " --controller : time step adaptivity" << endl; cout << " --nonlinear : nonlinearly implicit" << endl; @@ -2839,7 +2839,7 @@ static int OutputStatsMRICVODE(void* arkode_mem, MRIStepInnerStepper stepper, return 0; } -// Ouput timing stats +// Output timing stats static int OutputTiming(UserData* udata) { if (udata->outproc) diff --git a/examples/arkode/CXX_parallel/ark_heat2D_p.cpp b/examples/arkode/CXX_parallel/ark_heat2D_p.cpp index 566a7a4b41..0bf8d97ba7 100644 --- a/examples/arkode/CXX_parallel/ark_heat2D_p.cpp +++ b/examples/arkode/CXX_parallel/ark_heat2D_p.cpp @@ -153,7 +153,7 @@ struct UserData sunrealtype* Ssend; sunrealtype* Nsend; - // Send requests for neighor exchange + // Send requests for neighbor exchange MPI_Request reqSW; MPI_Request reqSE; MPI_Request reqSS; @@ -180,7 +180,7 @@ struct UserData // Inverse of Jacobian diagonal for preconditioner N_Vector d; - // Ouput variables + // Output variables int output; // output level int nout; // number of output times ofstream uout; // output file stream @@ -486,7 +486,7 @@ int main(int argc, char* argv[]) sunrealtype dTout = udata->tf / udata->nout; sunrealtype tout = dTout; - // Inital output + // Initial output flag = OpenOutput(udata); if (check_flag(&flag, "OpenOutput", 1)) { return 1; } @@ -1576,7 +1576,7 @@ static void InputHelp() cout << " --noforcing : disable forcing term" << endl; cout << " --tf