Merge pull request #729 from abhro/abhro-patch-1

Documentation fixes

docs/src/interfaces/Init_Solve.md

@@ -37,7 +37,7 @@ is distinctly different from the
 [LinearSolve init interface](https://docs.sciml.ai/LinearSolve/stable/tutorials/caching_interface)
 which is designed for caching efficiency with reusing factorizations.
 
-## __solve and High-Level Handling
+## `__solve` and High-Level Handling
 
 While `init` and `solve` are the common entry point for users, solver packages will
 mostly define dispatches on `SciMLBase.__init` and `SciMLBase.__solve`. The reason is

docs/src/interfaces/Problems.md

@@ -86,7 +86,7 @@ usage, a `AbstractSciMLProblem` might be associated with some solver configurati
 callback or tolerance. Thus, for flexibility the extra keyword arguments to the
 `AbstractSciMLProblem` are carried to the solver.
 
-### problem_type
+### `problem_type`
 
 `AbstractSciMLProblem` types include a non-public API definition of `problem_type` which holds
 a trait type corresponding to the way the `AbstractSciMLProblem` was constructed. For example,

docs/src/interfaces/SciMLFunctions.md

@@ -94,8 +94,8 @@ on setting up time/parameter dependent operators.
 The solver libraries internally use packages such as [FiniteDiff.jl](https://docs.sciml.ai/FiniteDiff/stable/)
 and [SparseDiffTools.jl](https://docs.sciml.ai/SparseDiffTools/stable/) for
 high performance calculation of sparse Jacobians and Hessians, along with matrix-free
-calculations of Jacobian-Vector products (J*v), vector-Jacobian products (v'*J),
-and Hessian-vector products (H*v). The SciML interface gives users the ability
+calculations of Jacobian-Vector products (`J*v`), vector-Jacobian products (`v'*J`),
+and Hessian-vector products (`H*v`). The SciML interface gives users the ability
 to control these connections in order to allow for top notch performance.
 
 The key arguments in the SciMLFunction is the `prototype`, which is an object

src/SciMLBase.jl

@@ -100,7 +100,7 @@ abstract type AbstractOptimizationCache end
 """
 $(TYPEDEF)
 
-Base for types which define nonlinear solve problems (f(u)=0).
+Base for types which define nonlinear solve problems (`f(u)=0`).
 """
 abstract type AbstractNonlinearProblem{uType, isinplace} <: AbstractDEProblem end
 abstract type AbstractIntervalNonlinearProblem{uType, isinplace} <:

src/alg_traits.jl

@@ -1,5 +1,5 @@
 """
-isautodifferentiable(alg::AbstractDEAlgorithm)
+    isautodifferentiable(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm is compatible with
 direct automatic differentiation, i.e. can have algorithms like
@@ -11,7 +11,7 @@ Defaults to false as only pure-Julia algorithms can have this be true.
 isautodifferentiable(alg::AbstractSciMLAlgorithm) = false
 
 """
-forwarddiffs_model(alg::AbstractDEAlgorithm)
+    forwarddiffs_model(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm uses ForwardDiff.jl
 on the model function is called with ForwardDiff.jl
@@ -21,7 +21,7 @@ Defaults to false as only pure-Julia algorithms can have this be true.
 forwarddiffs_model(alg::AbstractSciMLAlgorithm) = false
 
 """
-forwarddiffs_model_time(alg::AbstractDEAlgorithm)
+    forwarddiffs_model_time(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm uses ForwardDiff.jl
 on the model `f(u,p,t)` function is called with ForwardDiff.jl on the `t` argument.
@@ -32,7 +32,7 @@ have this as true
 forwarddiffs_model_time(alg::AbstractSciMLAlgorithm) = false
 
 """
-allows_arbitrary_number_types(alg::AbstractDEAlgorithm)
+    allows_arbitrary_number_types(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm is compatible with
 direct automatic differentiation, i.e. can have algorithms like
@@ -44,7 +44,7 @@ Defaults to false as only pure-Julia algorithms can have this be true.
 allows_arbitrary_number_types(alg::AbstractSciMLAlgorithm) = false
 
 """
-allowscomplex(alg::AbstractDEAlgorithm)
+    allowscomplex(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm is compatible with
 having complex numbers as the state variables.
@@ -54,7 +54,7 @@ Defaults to false.
 allowscomplex(alg::AbstractSciMLAlgorithm) = false
 
 """
-isadaptive(alg::AbstractDEAlgorithm)
+    isadaptive(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm uses adaptivity,
 i.e. has a non-quasi-static compute graph.
@@ -65,7 +65,7 @@ isadaptive(alg::AbstractDEAlgorithm) = true
 # Default to assuming adaptive, safer error("Adaptivity algorithm trait not set.")
 
 """
-isdiscrete(alg::AbstractDEAlgorithm)
+    isdiscrete(alg::AbstractDEAlgorithm)
 
 Trait declaration for whether an algorithm allows for
 discrete state values, such as integers.
@@ -75,7 +75,7 @@ Defaults to false.
 isdiscrete(alg::AbstractDEAlgorithm) = false
 
 """
-allowsbounds(opt)
+    allowsbounds(opt)
 
 Trait declaration for whether an optimizer allows for
 box constraints passed with `lb` and `ub` in
@@ -86,7 +86,7 @@ Defaults to false.
 allowsbounds(opt) = false
 
 """
-requiresbounds(opt)
+    requiresbounds(opt)
 
 Trait declaration for whether an optimizer requires
 box constraints passed with `lb` and `ub` in
@@ -97,7 +97,7 @@ Defaults to false.
 requiresbounds(opt) = false
 
 """
-allowsconstraints(opt)
+    allowsconstraints(opt)
 
 Trait declaration for whether an optimizer allows
 non-linear constraints specified in `cons` in
@@ -108,7 +108,7 @@ Defaults to false.
 allowsconstraints(opt) = false
 
 """
-requiresconstraints(opt)
+    requiresconstraints(opt)
 
 Trait declaration for whether an optimizer
 requires non-linear constraints specified in
@@ -119,7 +119,7 @@ Defaults to false.
 requiresconstraints(opt) = false
 
 """
-requiresgradient(opt)
+    requiresgradient(opt)
 
 Trait declaration for whether an optimizer
 requires gradient in `instantiate_function`.
@@ -129,7 +129,7 @@ Defaults to false.
 requiresgradient(opt) = false
 
 """
-requireshessian(opt)
+    requireshessian(opt)
 
 Trait declaration for whether an optimizer
 requires hessian in `instantiate_function`.
@@ -139,17 +139,17 @@ Defaults to false.
 requireshessian(opt) = false
 
 """
-requiresconsjac(opt)
+    requiresconsjac(opt)
 
 Trait declaration for whether an optimizer
-requires cons_j in `instantiate_function`, that is, does the optimizer require a constant Jacobian.
+requires `cons_j` in `instantiate_function`, that is, does the optimizer require a constant Jacobian.
 
 Defaults to false.
 """
 requiresconsjac(opt) = false
 
 """
-requiresconshess(opt)
+    requiresconshess(opt)
 
 Trait declaration for whether an optimizer
 requires cons_h in `instantiate_function`, that is, does the optimizer require a constant hessian.
@@ -159,7 +159,7 @@ Defaults to false.
 requiresconshess(opt) = false
 
 """
-allowscallback(opt)
+    allowscallback(opt)
 
 Trait declaration for whether an optimizer
 supports passing a `callback` to `solve`
@@ -170,7 +170,7 @@ Defaults to true.
 allowscallback(opt) = true
 
 """
-alg_order(alg)
+    alg_order(alg)
 
 The theoretic convergence order of the algorithm. If the method is adaptive order, this is treated
 as the maximum order of the algorithm.

src/debug.jl

@@ -49,11 +49,11 @@ into the AbstractSciMLProblem (e.x.: ODEProblem) but the parameters object `p` w
 expression. Two common reasons for this issue are:
 
 1. Forgetting to pass parameters into the problem constructor. For example, `ODEProblem(f,u0,tspan)` should
-be `ODEProblem(f,u0,tspan,p)` in order to use parameters.
+   be `ODEProblem(f,u0,tspan,p)` in order to use parameters.
 
 2. Using the wrong function signature. For example, with `ODEProblem`s the function signature is always
-`f(du,u,p,t)` for the in-place form or `f(u,p,t)` for the out-of-place form. Note that the `p` argument
-will always be in the function signature regardless of if the problem is defined with parameters!
+   `f(du,u,p,t)` for the in-place form or `f(u,p,t)` for the out-of-place form. Note that the `p` argument
+   will always be in the function signature regardless of if the problem is defined with parameters!
 """
 
 function __init__()

src/integrator_interface.jl

@@ -283,7 +283,7 @@ function reinit!(integrator::DEIntegrator, args...; kwargs...)
 end
 
 """
-initialize_dae!(integrator::DEIntegrator,initializealg = integrator.initializealg)
+    initialize_dae!(integrator::DEIntegrator,initializealg = integrator.initializealg)
 
 Runs the DAE initialization to find a consistent state vector. The optional
 argument `initializealg` can be used to specify a different initialization
@@ -894,7 +894,7 @@ end
 has_stats(i::DEIntegrator) = false
 
 """
-    is_integrator_adaptive(i::DEIntegrator)
+    isadaptive(i::DEIntegrator)
 
 Checks if the integrator is adaptive
 """

src/operators/diffeq_operator.jl

@@ -1,5 +1,5 @@
 """
-AffineDiffEqOperator{T} <: AbstractDiffEqOperator{T}
+    AffineDiffEqOperator{T} <: AbstractDiffEqOperator{T}
 
 `Ex: (A₁(t) + ... + Aₙ(t))*u + B₁(t) + ... + Bₘ(t)`
 

src/problems/problem_utils.jl

@@ -149,11 +149,11 @@ into the AbstractSciMLProblem (e.x.: ODEProblem) but the parameters object `p` w
 expression (e.x. `p[i]`, or `x .+ p`). Two common reasons for this issue are:
 
 1. Forgetting to pass parameters into the problem constructor. For example, `ODEProblem(f,u0,tspan)` should
-be `ODEProblem(f,u0,tspan,p)` in order to use parameters.
+   be `ODEProblem(f,u0,tspan,p)` in order to use parameters.
 
 2. Using the wrong function signature. For example, with `ODEProblem`s the function signature is always
-`f(du,u,p,t)` for the in-place form or `f(u,p,t)` for the out-of-place form. Note that the `p` argument
-will always be in the function signature regardless of if the problem is defined with parameters!
+   `f(du,u,p,t)` for the in-place form or `f(u,p,t)` for the out-of-place form. Note that the `p` argument
+   will always be in the function signature regardless of if the problem is defined with parameters!
 """
 
 struct NullParameterIndexError <: Exception end