<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 6, 2015 at 8:40 AM, Patrick Sanan <span dir="ltr"><<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jul 6, 2015 at 3:02 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Jul 6, 2015 at 4:59 AM, Patrick Sanan <span dir="ltr"><<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div>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?</div><div>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?</div></div></blockquote><div><br></div></span><div>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</div><div>is essentially what petsc4py does. What is limiting in this methodology?</div></div></div></div></blockquote></span><div>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.</div></div></div></div></blockquote><div><br></div><div>The deal.II wrapper is crazy. I have told Wolfgang. It makes the same mistake as FEniCS, which is to provide</div><div>an interface type for each PETSc implementation type. This kind of confusion takes a flexible, runtime configuration</div><div>and makes it an inflexible, compile-time configuration while introducing a load of new types and making the</div><div>closed-world assumption.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> On the other hand, requiring specific types, ala FEniCS,</div><div>is very limiting.</div></div></div></div></blockquote></span><div>What tradeoffs does FEniCS make in this context? Are there other wrappers which make different ones?</div><div>How wrong is it to say "If we have real and complex double types, 99% of the use cases are covered?".</div></div></div></div></blockquote><div><br></div><div>I think this is essentially true, and is what is done by the Purdue guys. You can accomplish it by using dynamic</div><div>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</div><div>type handling from GPUs migrated to handle the real/complex divide.</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> Matt</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 4, 2015 at 11:00 PM, Jared Crean <span dir="ltr"><<a href="mailto:jcrean01@gmail.com" target="_blank">jcrean01@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<big>Hello,<br>
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).<br>
<br>
I read the discussion on Github
[<a href="https://github.com/JuliaLang/julia/issues/2645" 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. 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.<br>
<br>
What do you think, both about using the Petsc.jl file and
the overall approach?<span><font color="#888888"><br>
<br>
Jared Crean</font></span></big><br>
</div>
</blockquote></div><br></div>
</blockquote></span></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>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>
</font></span></div></div>
</blockquote></span></div><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>