Revamp using new PETSc_jll binaries #99
Conversation
simonbyrne
force-pushed
the
sb/revamp
branch
3 times, most recently
from
68a826d to
eaffc9f
Compare
|
@stevengj would you have any objection to me merging this? I realise it's not complete (in terms of functionality vs the old code), but it would make it easier for us to do more incremental development. |
|
@JaredCrean2 as well |
|
@simonbyrne This has been a great start! I tried to see how far we can push the specification of solver options. Here is an example using CG plus PETSc's native AMG preconditioner: 2026516 I think there is some issue with nesting options prefixes - or perhaps I am missing something? |
|
That's fine with me. Are you planning to manually translate the Petsc headers rather than using Clang.jl? |
|
I think so: the bigger challenge is keeping track of object lifetimes and figuring out correct return objects, which generated wrappers can't help with. |
|
Yes, that seems reasonable to me. My initial plan was to do manual header translation, but the Petsc guys got upset with that suggestion and felt that we couldn't possibly keep up with their advanced API changes (see JuliaLang/julia#2645). To the extent that we are focused on providing high-level APIs, however, I don't think that is a problem. |
No description provided.