On Mon, Jul 6, 2015 at 10:56 AM, Garth N. Wells <[email protected]> wrote:
> On 6 July 2015 at 14:56, Matthew Knepley <[email protected]> wrote: > > 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. > > > > Your assertion on the FEniCS interface to PETSc is wrong for recent > FEniCS; users can set PETSc object types via the PETSc options system, > and users can access and manipulate directly the PETSc object, if they > wish (or initialise a wrapper with a PETSc object). Excellent! Can you point me toward the doc so I know what i am talking about next time. Thanks, Matt > > Garth > > >>> 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 > -- 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
