Update Sundials version

[alyst]

Sundials.jl uses Sundials 2.5.0, the most version is 2.6.2.

I don't know what would be the specific benefits of upgrading the Sundials version, but with #67 merged into master some of the hand-written wrappers are now generated automatically, so this upgrade should be easier.

[ChrisRackauckas]

I think it's only worthwhile if we also make it possible to use the KLU sparse direct solver in the simplified interface. I think a prerequisite for any PR making this change should show that this functionality is wrapped, otherwise it would be possible breaking without gains.

[jgoldfar]

I have a branch somewhere which wraps v2.6.2; the reason why it is not available here AFAIK is that the newest version is not available for direct download (which is how the build.jl script grabs sources to build.)

[jgoldfar]

ARKode is a motivating new feature that may make it worth it to update

[ChrisRackauckas]

I didn't know they added a operator splitting integrator. That would definitely be useful (I am hoping to implement one, so it would be nice to have one to test against).

@alyst mind if we assign this to you?

[jgoldfar]

Found the relevant branch: https://github.com/jgoldfar/Sundials.jl/tree/library-2.6.2 you'll need to provide sources though

[ChrisRackauckas]

That branch doesn't have the #67 changes. I wonder if using the autogenerated wrappers would be easier than rebasing it again.

[jgoldfar]

No; it would require rebase and/or wrapper regeneration. Probably the latter would be best, though wrapper regeneration is not a straightforward task last I did it for this package.

On Sep 2, 2016, at 5:11 PM, Christopher Rackauckas [email protected] wrote:

That branch doesn't have the #67 changes. I wonder if using the autogenerated wrappers would be easier than rebasing it again.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[alyst]

@ChrisRackauckas I think the best would be if somebody else picks up the Sundials version update task and I will provide my assistance:

• wrapper generator will get a substantial review and another person that understands its code
• my projects would not directly benefit from the new Sundials features, so for me it would hard to judge whether the generator is doing a proper job

You or @jgoldfar could just try running wrap_sundials.jl, it should be a little bit easier than before. Here's the link to 2.6.2 sources, seems to work.

[ChrisRackauckas]

That makes sense. I might look into if no one else does in the next month.

[jgoldfar]

I generated wrappers using the old script by accident (thought I had updated!) but with the new wrap_sundials.jl, I'm getting

ERROR: LoadError: type Symbol has no field args
 in (::##5#11)(::Symbol) at /Users/jgoldfar/Documents/misc/julia/Sundials/src/wrap_sundials.jl:166
 in collect_to!(::Array{Tuple{Symbol,Expr,Expr},1}, ::Base.Generator{Base.Drop{Array{Any,1}},##5#11}, ::Int64, ::Int64) at ./array.jl:340
 in collect_to_with_first!(::Array{Tuple{Symbol,Expr,Expr},1}, ::Tuple{Symbol,Expr,Expr}, ::Base.Generator{Base.Drop{Array{Any,1}},##5#11}, ::Int64) at ./array.jl:327
 in collect(::Base.Generator{Base.Drop{Array{Any,1}},##5#11}) at ./array.jl:308
 in typeify_sundials_pointers(::Expr) at /Users/jgoldfar/Documents/misc/julia/Sundials/src/wrap_sundials.jl:159
 in (::##17#18)(::Array{Any,1}) at /Users/jgoldfar/Documents/misc/julia/Sundials/src/wrap_sundials.jl:244
 in run(::Clang.wrap_c.WrapContext) at /Users/jgoldfar/Documents/misc/env/bin/julia/.julia/v0.5/Clang/src/wrap_c.jl:802
 in include_from_node1(::String) at ./loading.jl:488
 in include_from_node1(::String) at /Users/jgoldfar/Public/julia/build-0.5/usr/lib/julia/sys.dylib:?
 in process_options(::Base.JLOptions) at ./client.jl:262
 in _start() at ./client.jl:318
 in _start() at /Users/jgoldfar/Public/julia/build-0.5/usr/lib/julia/sys.dylib:?
while loading /Users/jgoldfar/Documents/misc/julia/Sundials/src/wrap_sundials.jl, in expression starting on line 250

[jgoldfar]

If anyone is interested in a branch with a build.jl modified to pull and build v2.7.0, I can push it somewhere. Any idea on how where to start on the previous?

[alyst]

@jgoldfar My initial guess is that maybe Clang.jl was modified so the returned expression doesn't match the wrapper script expectation. Could you please look up what is top-level expr (line 118) and what is expr.args[1].args?

[alyst]

@jgoldfar If you intend to continue working on 2.7.0 support, it makes total sense to make a PR with what you have at the moment.

[jgoldfar]

BTW wrap_sundials.jl looks like a good place to use https://github.com/MikeInnes/MacroTools.jl (not that I've used it, but seen it being used...)

[alyst]

@jgoldfar Thanks for the link. Yes, using MacroTools should potentially simplify the script.

[tshort]

Conda.jl might be a good option for cross-platform installation of the Sundials libraries. Sundials 2.7.0 is available here:

https://anaconda.org/conda-forge/sundials

That would certainly help on the Windows side, where someone would have to update the binary that @tkelman put together. Having binary libraries for Linux and OSX could also speed up the Travis tests.

[ChrisRackauckas]

That's a very good idea. I am much more comfortable with Conda anyways. I'll see if I can get this going.

[tkelman]

Conda's sundials build is most likely built using msvc, which I would avoid.

[tkelman]

You also don't need an entire python distribution to install a single C library.

[ChrisRackauckas]

Conda's sundials build is most likely built using msvc, which I would avoid.

Yeah, now I remember this is why SymEngine went away from the Windows use of Conda. It caused a lot of problems and was eventually dropped. Scrap this then.

[ChrisRackauckas]

Completed via #149