On Mon, Jul 6, 2015 at 8:40 AM, Patrick Sanan <[email protected]> wrote: > > On Mon, Jul 6, 2015 at 3:02 PM, Matthew Knepley <[email protected]> wrote: > >> On Mon, Jul 6, 2015 at 4:59 AM, Patrick Sanan <[email protected]> >> wrote: >> >>> I had a couple of brief discussions about this at Juliacon as well. I >>> think it would be useful, but there are a couple of things to think about >>> from the start of any new attempt to do this: >>> 1. As Jack pointed out, one issue is that the PETSc library must be >>> compiled for a particular precision. This raises some questions - should >>> several versions of the library be built to allow for flexibility? >>> 2. An issue with wrapping PETSc is always that the flexibility of using >>> the PETSc options paradigm is reduced - how can this be addressed? >>> Could/should an expert user be able to access the options database >>> directly, or would this be too much violence to the wrapper abstraction? >>> >> >> I have never understood why this is an issue. Can't you just wrap our >> interface level, and use the options just as we do? That >> is essentially what petsc4py does. What is limiting in this methodology? >> > I don't see any fundamental problems with this, either, but in practice > people tend to want to hardcode things (like the deal.ii interface does, in > my limited experience with it). Hopefully this is just a suboptimal design > choice which can be avoided with an interface to the options database > included in the wrapper. >
The deal.II wrapper is crazy. I have told Wolfgang. It makes the same mistake as FEniCS, which is to provide an interface type for each PETSc implementation type. This kind of confusion takes a flexible, runtime configuration and makes it an inflexible, compile-time configuration while introducing a load of new types and making the closed-world assumption. On the other hand, requiring specific types, ala FEniCS, >> is very limiting. >> > What tradeoffs does FEniCS make in this context? Are there other wrappers > which make different ones? > How wrong is it to say "If we have real and complex double types, 99% of > the use cases are covered?". > I think this is essentially true, and is what is done by the Purdue guys. You can accomplish it by using dynamic libraries and a fair bit of hacking. C still does not have a great way to do this, but I am hopeful for the Karl-style type handling from GPUs migrated to handle the real/complex divide. Matt > > >> >> Matt >> >> >>> On Sat, Jul 4, 2015 at 11:00 PM, Jared Crean <[email protected]> wrote: >>> >>>> Hello, >>>> I am a graduate student working on a CFD code written in Julia, >>>> and I am interested in using Petsc as a linear solver (and possibly for the >>>> non-linear solves as well) for the code. I discovered the Julia wrapper >>>> file Petsc.jl in Petsc and have updated it to work with the current version >>>> of Julia and the MPI.jl package, using only MPI for communication (I don't >>>> think Julia's internal parallelism will scale well enough, at least not in >>>> the near future). >>>> >>>> I read the discussion on Github [ >>>> https://github.com/JuliaLang/julia/issues/2645], and it looks like >>>> there currently is not a complete package to access Petsc from Julia. >>>> With your permission, I would like to use the Petsc.jl file as the basis >>>> for developing a package. My plan is create a lower level interface that >>>> exactly wraps Petsc functions, and then construct a higher level interface, >>>> probably an object that is a subtype of Julia's AbstractArray, that allows >>>> users to store values into Petsc vectors and matrices. I am less >>>> interested in integrating tightly with Julia's existing linear algebra >>>> capabilities than ensuring good scalability. The purpose of the high level >>>> interface it simple to populate the vector or matrix. >>>> >>>> What do you think, both about using the Petsc.jl file and the >>>> overall approach? >>>> >>>> Jared Crean >>>> >>> >>> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which their >> experiments lead. >> -- Norbert Wiener >> > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
