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