Continuing bugs for SecondOrderODE problem solvers

did you ]up?


Did you run ]up to update your registry?

I don’t think that was mentioned in the github entry, but I just did it; it didn’t change any of the error messages.

This is becoming the world’s least fun scavenger hunt.

When you updated your packages, what versions did you get?

Chris, I’ve become fairly certain that there’s a bug in SecondOrderODEProblem (probably some kind of data array mismatch) which makes it fail with all of the “stiff” solvers. (In Windows, at least.)

By changing the problem function to a set of coupled 1st-order equations, I was able to use ODEProblem to complete runs with Rodas5, Rodas4P, RadauIIA5, KenCarp4 and Kvaerno.

But running as coupled 1st-order eqn’s is not optimal, because I’d assume that it would be less “energy-conserving” (not symplectic). Also, that doesn’t let me use AutoVern9.

If you have any success in getting the stiff solvers to run with SecondOrderODEProblem, it would be great to be able to use it.

radau had the same problem the one time I was able to run it at all; though I’m almost giving up on trying to get gfortran properly installed.

  1. This test ( passes with the last 2 releases since it was created. So if you’re using a recent version of OrdinaryDiffEq/DiffEqBase then you’re good.
  2. Your updating issues might be JuliaPro related?
  3. “But running as coupled 1st-order eqn’s is not optimal, because I’d assume that it would be less “energy-conserving” (not symplectic). Also, that doesn’t let me use AutoVern9.”, no. Using a method for first order ODEs doesn’t utilize the properties of the second order ODE in any magical way. It just does the conversion automatically. There are stiff ODE solvers that are specialized to second order ODEs (basically implicit Nystrom methods) but these haven’t been implemented yet.

Then I have no idea what’s going on.

You asked for my package versions, I’m not sure which ones, but here are some that might matter:

 [1dea7af3] OrdinaryDiffEq v5.39.1
 [54ca160b] ODEInterface v0.4.6
 [0c46a032] DifferentialEquations v6.14.0
 [2b5f629d] DiffEqBase v6.36.3

  [c52e3926] Atom v0.12.11 ⚲
  [aae01518] BandedMatrices v0.15.10
  [e66e0078] CompilerSupportLibraries_jll v0.3.3+0
  [864edb3b] DataStructures v0.17.15
  [e2d170a0] DataValueInterfaces v1.0.0
  [bcd4f6db] DelayDiffEq v5.24.1
  [2b5f629d] DiffEqBase v6.36.3
  [459566f4] DiffEqCallbacks v2.13.2
  [5a0ffddc] DiffEqFinancial v2.3.0
  [c894b116] DiffEqJump v6.7.7
  [77a26b50] DiffEqNoiseProcess v4.1.6
  [055956cb] DiffEqPhysics v3.2.0
  [163ba53b] DiffResults v1.0.2
  [b552c78f] DiffRules v1.0.1
  [0c46a032] DifferentialEquations v6.14.0
  [c619ae07] DimensionalPlotRecipes v1.2.0
  [6a86dc24] FiniteDiff v2.3.2
  [26cc04aa] FiniteDifferences v0.10.2
  [f6369f11] ForwardDiff v0.10.10

So on a standard (non-JuliaPro) installation, you did:

]add DiffEqBase@6.38.4

and then you closed everything, opened a new REPL, and you still didn’t have the latest package versions?

I have to run in JuliaPro; when I first installed julia without it, I wasn’t able to load any packages at all.

Also, I tried ] up (from JuliaPro), and it apparently trashed my installation (I couldn’t run after that), and had to uninstall Julia 1.0 completely. So I installed Julia 1.4 now. Not sure if JuliaPro will freeze again if I try ] up again.

Pinging @avik who might be able to help

Thanks, any advice from Avik would be great.

BTW, I succeeded in installing gfortran,
and finally added ODEInterface without an error.
But surprisingly I still get an error in trying to use radau
(even after shutting down JuliaPro & re-starting):

UndefVarError: radau not defined
in top-level scope at base\util.jl:175


  [54ca160b] ODEInterface v0.4.6
  [2b5f629d] DiffEqBase v6.36.3
  [0c46a032] DifferentialEquations v6.14.0
  [1dea7af3] OrdinaryDiffEq v5.39.1


My student found an error! We realized that I had to install ODEInterfaceDiffEq in addition to ODEInterface. (I was confused by the Julia Packages website, they way it’s listed I didn’t see that they were two different names; it is confusingly displayed.)

Now radau is recognized, but I get a new error:
**Cannot find method(s) for radau! I've tried to loadODESolvers(), but it didn't work. Please check ODEInterface.help_solversupport() and call loadODESolvers and check also this output. For further information see also ODEInterface.help_install.**

Interestingly, you answered this issue already in “”, but I don’t see what the solution is, since I’ve already installed both packages now:

  [54ca160b] ODEInterface v0.4.6
  [09606e27] ODEInterfaceDiffEq v3.7.0

Adding this call still doesn’t fix the problem:


Just do using ODEInterface, ODEInterfaceDiffEq and it should work. That’s what we have to do for our benchmarks for examples. It’s because ODEInterface doesn’t use the standard Julia system for handling its binaries, and it should really be changed… but in general we don’t use the Fortran methods very often anymore so this rarely shows up. Not a reason to not get it fixed though.

I’ve done all that, radau still doesn’t work. ODEInterface simply isn’t reliable. I have to move on with my calculations and use what I’ve got working: Vern9 with SecondOrderODEProblem and Rodas5/RadauIIA5 with ODEProblem. That’ll have to do, I guess.

Thanks for all of your time & messages, I can move forward with this. I’m sure I’ll be posting again in the future after using these algorithms.