From f7b2e7a757ebefdf50f5f9d45825f9921f468051 Mon Sep 17 00:00:00 2001 From: Hossein Pourbozorg Date: Tue, 20 May 2025 00:13:20 +0330 Subject: [PATCH] Replace `ArbFloats` by `ArbNumerics` --- docs/src/basics/faq.md | 8 ++++---- docs/src/basics/overview.md | 2 +- docs/src/features/callback_functions.md | 2 +- docs/src/index.md | 4 ++-- docs/src/solvers/ode_solve.md | 10 +++++----- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/src/basics/faq.md b/docs/src/basics/faq.md index c2899714d..e008b0a25 100644 --- a/docs/src/basics/faq.md +++ b/docs/src/basics/faq.md @@ -12,9 +12,9 @@ For guidelines on debugging ODE solve issues, see First of all, don't panic. You may have experienced one of the following warnings: > dt <= dtmin. Aborting. There is either an error in your model specification or the true solution is unstable. -> +> > NaN dt detected. Likely a NaN value in the state, parameters, or derivative value caused this outcome. -> +> > Instability detected. Aborting These are all pointing to a similar behavior: for some reason or another, the @@ -185,7 +185,7 @@ numerically and thus results in much better performance. This is seen in many in SciMLBenchmarks. Thus it is recommended that in almost all or most situations, one should use the mass matrix form of the DAE solver. -However, it is generally recommended that if you are solving a DAE that you use +However, it is generally recommended that if you are solving a DAE that you use [ModelingToolkit.jl](https://mtk.sciml.ai/dev/) because it has many utilities for pre-processing DAEs to make them more numerically stable. For example, if your algebraic conditions are not uniquely matching to algebraic variables (i.e. you have at least one unique algebraic variable @@ -455,7 +455,7 @@ thing you can do is use You can't. For floating-point numbers, you shouldn't use below `abstol=1e-14` and `reltol=1e-14`. If you need lower than that, use arbitrary precision numbers -like BigFloats or [ArbFloats.jl](https://github.com/JuliaArbTypes/ArbFloats.jl). +like BigFloats or [ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl). ## Autodifferentiation and Dual Numbers diff --git a/docs/src/basics/overview.md b/docs/src/basics/overview.md index f36e991d1..0a6829f82 100644 --- a/docs/src/basics/overview.md +++ b/docs/src/basics/overview.md @@ -31,7 +31,7 @@ timespan and `BigFloat` for specifying the initial condition, then the solution will solve using `Rational{BigInt}` for the timesteps and `BigFloat` for the independent variables. A wide variety of number types are compatible with the solvers such as complex numbers, unitful numbers (via Unitful.jl), -decimals (via DecFP), dual numbers, and many more which may not have been tested +decimals (via [DecFP](https://github.com/JuliaMath/DecFP.jl)), dual numbers, and many more which may not have been tested yet (thanks to the power of multiple dispatch!). For information on type-compatibility, please see the solver pages for the specific problems. diff --git a/docs/src/features/callback_functions.md b/docs/src/features/callback_functions.md index d8c077ee9..30d4a0d5c 100644 --- a/docs/src/features/callback_functions.md +++ b/docs/src/features/callback_functions.md @@ -522,7 +522,7 @@ However, at some point we will hit machine epsilon, the value where `t + eps(t) == t`, so we cannot measure infinitely many bounces and instead will be limited by the floating-point accuracy of our number representation. Using alternative number types like -[ArbFloats.jl](https://github.com/JuliaArbTypes/ArbFloats.jl) can allow for this +[ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl) can allow for this to be done at very high accuracy, but still not infinite. Thus, what we need to do is determine a tolerance after which we assume the accumulation has been reached and define the exit behavior. In this case, we will say when the diff --git a/docs/src/index.md b/docs/src/index.md index ca27a464a..c0b1df973 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -42,7 +42,7 @@ DifferentialEquations.jl integrates with the Julia package sphere with: - Automatic plotting of time series and phase plots - Built-in interpolations - Wraps for common C/Fortran methods like Sundials and Hairer's radau - - Arbitrary precision with BigFloats and Arbfloats + - Arbitrary precision with BigFloats and [ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl) - Arbitrary array types, allowing the definition of differential equations on matrices and distributed arrays - Unit checked arithmetic with Unitful @@ -67,7 +67,7 @@ Additionally, DifferentialEquations.jl comes with built-in analysis features, in for guidance on PRs, issues, and other matters relating to contributing to SciML. - See the [SciML Style Guide](https://github.com/SciML/SciMLStyle) for common coding practices and other style decisions. - There are a few community forums: - + + The #diffeq-bridged and #sciml-bridged channels in the [Julia Slack](https://julialang.org/slack/) + The #diffeq-bridged and #sciml-bridged channels in the diff --git a/docs/src/solvers/ode_solve.md b/docs/src/solvers/ode_solve.md index 6c5c155d8..b343d0d52 100644 --- a/docs/src/solvers/ode_solve.md +++ b/docs/src/solvers/ode_solve.md @@ -71,7 +71,7 @@ At medium tolerances (`>1e-8`?) it is recommended you use `Rodas5P`, `Rodas4P` (the former is more efficient, but the latter is more reliable), `Kvaerno5`, or `KenCarp4`. As native DifferentialEquations.jl solvers, many Julia numeric types (such as BigFloats, -[ArbFloats](https://github.com/JuliaArbTypes/ArbFloats.jl), or +[ArbNumerics.jl](https://github.com/JeffreySarnoff/ArbNumerics.jl), or [DecFP](https://github.com/JuliaMath/DecFP.jl)) will work. When the equation is defined via the `@ode_def` macro, these will be the most efficient. @@ -960,22 +960,22 @@ using IRKGaussLegendre `IRKGL16(;kwargs...)` has the following arguments: - second_order_ode (boolean): - + + =false (default): for a ODEProblem type + =true: for a second-order differential equation - simd (boolean): - + + =true: SIMD-vectorized implementation only available for Float32 or Float64 computations + =false (default): generic implementation that can use with arbitrary Julia-defined number systems - mstep: output saved at every 'mstep' steps. Default 1. - initial_extrapolation: initialization method for stages. - + + =false: simplest initialization + =true (default): extrapolation from the stage values of previous step - maxtrials: maximum number of attempts to accept adaptive step size - threading - + + =false (default): sequential execution of the numerical integration + =true: computations using threads (shared memory multi-threading) for stage-wise parallelization