Update old links to juliadiffeq.org to sciml.ai

tutorials/advanced/01-beeler_reuter.jmd

@@ -7,7 +7,7 @@ author: Shahriar Iravanian
 
 [SciML](https://github.com/SciML) is a suite of optimized Julia libraries to solve ordinary differential equations (ODE). *SciML* provides a large number of explicit and implicit solvers suited for different types of ODE problems. It is possible to reduce a system of partial differential equations into an ODE problem by employing the [method of lines (MOL)](https://en.wikipedia.org/wiki/Method_of_lines). The essence of MOL is to discretize the spatial derivatives (by finite difference, finite volume or finite element methods) into algebraic equations and to keep the time derivatives as is. The resulting differential equations are left with only one independent variable (time) and can be solved with an ODE solver. [Solving Systems of Stochastic PDEs and using GPUs in Julia](http://www.stochasticlifestyle.com/solving-systems-stochastic-pdes-using-gpus-julia/) is a brief introduction to MOL and using GPUs to accelerate PDE solving in *JuliaDiffEq*. Here we expand on this introduction by developing an implicit/explicit (IMEX) solver for a 2D cardiac electrophysiology model and show how to use [CuArray](https://github.com/JuliaGPU/CuArrays.jl) and [CUDAnative](https://github.com/JuliaGPU/CUDAnative.jl) libraries to run the explicit part of the model on a GPU.
 
-Note that this tutorial does not use the [higher order IMEX methods built into DifferentialEquations.jl](https://docs.juliadiffeq.org/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1) but instead shows how to hand-split an equation when the explicit portion has an analytical solution (or approxiate), which is common in many scenarios.
+Note that this tutorial does not use the [higher order IMEX methods built into DifferentialEquations.jl](https://docs.sciml.ai/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1) but instead shows how to hand-split an equation when the explicit portion has an analytical solution (or approxiate), which is common in many scenarios.
 
 There are hundreds of ionic models that describe cardiac electrical activity in various degrees of detail. Most are based on the classic [Hodgkin-Huxley model](https://en.wikipedia.org/wiki/Hodgkin%E2%80%93Huxley_model) and define the time-evolution of different state variables in the form of nonlinear first-order ODEs. The state vector for these models includes the transmembrane potential, gating variables, and ionic concentrations. The coupling between cells is through the transmembrame potential only and is described as a reaction-diffusion equation, which is a parabolic PDE,
 
@@ -27,7 +27,7 @@ We have chosen the [Beeler-Reuter ventricular ionic model](https://www.ncbi.nlm.
 
 ## CPU-Only Beeler-Reuter Solver
 
-Let's start by developing a CPU only IMEX solver. The main idea is to use the *DifferentialEquations* framework to handle the implicit part of the equation and code the analytical approximation for explicit part separately. If no analytical approximation was known for the explicit part, one could use methods from [this list](https://docs.juliadiffeq.org/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1).
+Let's start by developing a CPU only IMEX solver. The main idea is to use the *DifferentialEquations* framework to handle the implicit part of the equation and code the analytical approximation for explicit part separately. If no analytical approximation was known for the explicit part, one could use methods from [this list](https://docs.sciml.ai/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1).
 
 First, we define the model constants:
 
@@ -129,7 +129,7 @@ end
 
 ### The Rush-Larsen Method
 
-We use an explicit solver for all the state variables except for the transmembrane potential which is solved with the help of an implicit solver. The explicit solver is a domain-specific exponential method, the Rush-Larsen method. This method utilizes an approximation on the model in order to transform the IMEX equation into a form suitable for an implicit ODE solver. This combination of implicit and explicit methods forms a specialized IMEX solver. For general IMEX integration, please see the [IMEX solvers documentation](https://docs.juliadiffeq.org/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1). While we could have used the general model to solve the current problem, for this specific model, the transformation approach is more efficient and is of practical interest.
+We use an explicit solver for all the state variables except for the transmembrane potential which is solved with the help of an implicit solver. The explicit solver is a domain-specific exponential method, the Rush-Larsen method. This method utilizes an approximation on the model in order to transform the IMEX equation into a form suitable for an implicit ODE solver. This combination of implicit and explicit methods forms a specialized IMEX solver. For general IMEX integration, please see the [IMEX solvers documentation](https://docs.sciml.ai/latest/solvers/split_ode_solve/#Implicit-Explicit-(IMEX)-ODE-1). While we could have used the general model to solve the current problem, for this specific model, the transformation approach is more efficient and is of practical interest.
 
 The [Rush-Larsen](https://ieeexplore.ieee.org/document/4122859/) method replaces the explicit Euler integration for the gating variables with direct integration. The starting point is the general ODE for the gating variables in Hodgkin-Huxley style ODEs,
 

tutorials/advanced/02-advanced_ODE_solving.jmd

@@ -16,13 +16,13 @@ SDEs, DDEs, DAEs, etc.
 
 For a detailed tutorial on how to optimize one's DifferentialEquations.jl code,
 please see the
-[Optimizing DiffEq Code tutorial](http://tutorials.juliadiffeq.org/html/introduction/03-optimizing_diffeq_code.html).
+[Optimizing DiffEq Code tutorial](http://tutorials.sciml.ai/html/introduction/03-optimizing_diffeq_code.html).
 
 ### Choosing a Good Solver
 
 Choosing a good solver is required for getting top notch speed. General
 recommendations can be found on the solver page (for example, the
-[ODE Solver Recommendations](https://docs.juliadiffeq.org/dev/solvers/ode_solve)).
+[ODE Solver Recommendations](https://docs.sciml.ai/dev/solvers/ode_solve)).
 The current recommendations can be simplified to a Rosenbrock method
 (`Rosenbrock23` or `Rodas5`) for smaller (<50 ODEs) problems, ESDIRK methods
 for slightly larger (`TRBDF2` or `KenCarp4` for <2000 ODEs), and Sundials
@@ -35,7 +35,7 @@ compare many solvers on many problems.
 
 ### Check Out the Speed FAQ
 
-See [this FAQ](https://docs.juliadiffeq.org/latest/basics/faq/#faq_performance-1)
+See [this FAQ](https://docs.sciml.ai/latest/basics/faq/#faq_performance-1)
 for information on common pitfalls and how to improve performance.
 
 ### Setting Up Your Julia Installation for Speed
@@ -69,7 +69,7 @@ the linear algebra routines. Please see the package for the limitations.
 
 When possible, use GPUs. If your ODE system is small and you need to solve it
 with very many different parameters, see the
-[ensembles interface](https://docs.juliadiffeq.org/dev/features/ensemble)
+[ensembles interface](https://docs.sciml.ai/dev/features/ensemble)
 and [DiffEqGPU.jl](https://github.com/JuliaDiffEq/DiffEqGPU.jl). If your problem
 is large, consider using a [CuArray](https://github.com/JuliaGPU/CuArrays.jl)
 for the state to allow for GPU-parallelism of the internal linear algebra.
@@ -365,7 +365,7 @@ GMRES linear solver.
 ```
 
 For more information on linear solver choices, see the
-[linear solver documentation](https://docs.juliadiffeq.org/dev/features/linear_nonlinear).
+[linear solver documentation](https://docs.sciml.ai/dev/features/linear_nonlinear).
 
 On this problem, handling the sparsity correctly seemed to give much more of a
 speedup than going to a Krylov approach, but that can be dependent on the problem
@@ -392,7 +392,7 @@ prob_ode_brusselator_2d_jacfree = ODEProblem(f,u0,(0.,11.5),p)
 
 ### Adding a Preconditioner
 
-The [linear solver documentation](https://docs.juliadiffeq.org/latest/features/linear_nonlinear/#iterativesolvers-jl-1)
+The [linear solver documentation](https://docs.sciml.ai/latest/features/linear_nonlinear/#iterativesolvers-jl-1)
 shows how you can add a preconditioner to the GMRES. For example, you can
 use packages like [AlgebraicMultigrid.jl](https://github.com/JuliaLinearAlgebra/AlgebraicMultigrid.jl)
 to add an algebraic multigrid (AMG) or [IncompleteLU.jl](https://github.com/haampie/IncompleteLU.jl)
@@ -431,7 +431,7 @@ be given (otherwise it will default to attempting an LU-decomposition).
 While much of the setup makes the transition to using Sundials automatic, there
 are some differences between the pure Julia implementations and the Sundials
 implementations which must be taken note of. These are all detailed in the
-[Sundials solver documentation](https://docs.juliadiffeq.org/latest/solvers/ode_solve/#ode_solve_sundials-1),
+[Sundials solver documentation](https://docs.sciml.ai/latest/solvers/ode_solve/#ode_solve_sundials-1),
 but here we will highlight the main details which one should make note of.
 
 Defining a sparse matrix and a Jacobian for Sundials works just like any other
@@ -451,7 +451,7 @@ using Sundials
 ```
 
 Details for setting up a preconditioner with Sundials can be found at the
-[Sundials solver page](https://docs.juliadiffeq.org/latest/solvers/ode_solve/#ode_solve_sundials-1).
+[Sundials solver page](https://docs.sciml.ai/latest/solvers/ode_solve/#ode_solve_sundials-1).
 
 ## Handling Mass Matrices
 
@@ -503,7 +503,7 @@ plot(sol, xscale=:log10, tspan=(1e-6, 1e5), layout=(3,1))
 
 Note that if your mass matrix is singular, i.e. your system is a DAE, then you
 need to make sure you choose
-[a solver that is compatible with DAEs](https://docs.juliadiffeq.org/latest/solvers/dae_solve/#dae_solve_full-1)
+[a solver that is compatible with DAEs](https://docs.sciml.ai/latest/solvers/dae_solve/#dae_solve_full-1)
 
 ```{julia; echo=false; skip="notebook"}
 using SciMLTutorials