update Weaving footer

Author: ChrisRackauckas

tutorials/DiffEqUncertainty/01-expectation_introduction.jmd

@@ -346,7 +346,7 @@ p_dist = [truncated(Normal(-.7f0, .1f0), -1f0,0f0)]
 
 The performance gains realized by leveraging batch GPU processing is problem dependent. In this case, the number of batch evaluations required to overcome the overhead of using the GPU exceeds the number of simulations required to converge to the quadrature solution.
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/DiffEqUncertainty/02-AD_and_optimization.jmd

@@ -292,7 +292,7 @@ begin
 end
 ```
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/Testing/test.jmd

@@ -5,7 +5,7 @@ author: Chris Rackauckas
 
 This is a test of the builder system.
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/advanced/01-beeler_reuter.jmd

@@ -655,7 +655,7 @@ heatmap(sol.u[end])
 
 We achieve around a 6x speedup with running the explicit portion of our IMEX solver on a GPU. The major bottleneck of this technique is the communication between CPU and GPU. In its current form, not all of the internals of the method utilize GPU acceleration. In particular, the implicit equations solved by GMRES are performed on the CPU. This partial CPU nature also increases the amount of data transfer that is required between the GPU and CPU (performed every f call). Compiling the full ODE solver to the GPU would solve both of these issues and potentially give a much larger speedup. [JuliaDiffEq developers are currently working on solutions to alleviate these issues](http://www.stochasticlifestyle.com/solving-systems-stochastic-pdes-using-gpus-julia/), but these will only be compatible with native Julia solvers (and not Sundials).
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/advanced/02-advanced_ODE_solving.jmd

@@ -505,7 +505,7 @@ 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.sciml.ai/latest/solvers/dae_solve/#dae_solve_full-1)
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/exercises/02-workshop_solutions.jmd

@@ -717,7 +717,7 @@ sim = solve(ensprob, Tsit5(), EnsembleGPUArray(), trajectories=length(z0))
 
 # Information on the Build
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/introduction/01-ode_introduction.jmd

@@ -340,8 +340,7 @@ sol[3]
 
 These are the basic controls in DifferentialEquations.jl. All equations are defined via a problem type, and the `solve` command is used with an algorithm choice (or the default) to get a solution. Every solution acts the same, like an array `sol[i]` with `sol.t[i]`, and also like a continuous function `sol(t)` with a nice plot command `plot(sol)`. The Common Solver Options can be used to control the solver for any equation type. Lastly, the types used in the numerical solving are determined by the input types, and this can be used to solve with arbitrary precision and add additional optimizations (this can be used to solve via GPUs for example!). While this was shown on ODEs, these techniques generalize to other types of equations as well.
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
-SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
+SciMLTutorials.bench_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```
-

tutorials/introduction/02-choosing_algs.jmd

@@ -118,7 +118,7 @@ If you are familiar with MATLAB, SciPy, or R's DESolve, here's a quick translati
 - `ode15i` -> `IDA()`, though in many cases `Rodas4()` can handle the DAE and is
   significantly more efficient
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/introduction/03-optimizing_diffeq_code.jmd

@@ -486,7 +486,7 @@ Why is `CVODE_BDF` doing well? What's happening is that, because the problem is
 
 Julia gives you the tools to optimize the solver "all the way", but you need to make use of it. The main thing to avoid is temporary allocations. For small systems, this is effectively done via static arrays. For large systems, this is done via in-place operations and cache arrays. Either way, the resulting solution can be immensely sped up over vectorized formulations by using these principles.
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```

tutorials/introduction/04-callbacks_and_events.jmd

@@ -321,7 +321,7 @@ saved_values.saveval
 
 Go back to the Harmonic oscillator. Use the `SavingCallback` to save an array for the energy over time, and do this both with and without the `ManifoldProjection`. Plot the results to see the difference the projection makes.
 
-```{julia; echo=false; skip="notebook"}
+```julia, echo = false, skip="notebook"
 using SciMLTutorials
 SciMLTutorials.tutorial_footer(WEAVE_ARGS[:folder],WEAVE_ARGS[:file])
 ```