On 6 July 2015 at 16:59, Matthew Knepley <[email protected]> wrote: > 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. >
Below is a link to a solver using BDDC, where the solver code is all PETSc. The user builds a matrix via the wrappers (using the options system to set the PETSc matrix type), and then unwraps the matrix to pass to the PETSc solver: https://bitbucket.org/garth-wells/dolfin-dd/src/42a203e094bf61f7c312604809ec599f15943649/demo/undocumented/div-div/cpp/main.cpp?at=stefano_zampini/bddc-and-ams-examples Garth > 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
