[petsc-dev] on implementing a new PetscViewer

[Marco Zocca]

Jed, the interface has multiple layers.
At the lowest, I'm using inline-c (e.g.
https://www.fpcomplete.com/blog/2015/05/inline-c ), and
so far got basic functionality up to KSP up and running by wrapping
the individual PETSc calls as "arrows" , and composing in IO for which
there are a number of bracketing constructs also for handling
exceptions. (mapping error codes to these is another daunting task for
later; for now I let the petsc stderr do all the signaling)

Two type signatures as example:
kspCreate :: Comm -> IO KSP, withKSP :: Comm -> (KSP -> IO a) -> IO a
which also require representing Vec, Mat, KSP etc. as opaque datatypes
with abstract Storable instances. (type alignment courtesy of
inline-c)

(so: no need for copying data back to memory, during normal operation
of the library)

I was asking about the Viewer for e.g. Vecs and Mats to hook up e.g.
with plotting functionality on the Hs side, but since this would be
needed "offline", I might just dump to file and load from there.

As you say, the mutating operations are a tough cookie to represent
functionally. There are a number of choices for representing state
propagation though, and I'm presently looking into a few.

Thank you,
Marco

On 17 July 2015 at 19:28, Jed Brown <jed at jedbrown.org> wrote:
> Marco Zocca <zocca.marco at gmail.com> writes:
>
>> Dear PETSc,
>>  in writing the foreign-function wrappers for the library in Haskell,
>> I found the need for an operation that copies the contents of a Mat or
>> Vec,
>
> I think this is actually not great design for an FFI to an object
> library like PETSc.  The interface strategy you seem to be modeling your
> approach after is designed for libraries that operate on raw arrays with
> no encapsulation instead of objects.
>
> A critical question is what to do about mutability.  Haskell likes
> functional data structures which typically have at least a "lazy spine"
> and thus the new objects that you are constantly creating can share the
> heavier parts.  Though some PETSc objects (like IS) are effectively
> immutable, objects like matrices and Krylov solvers are mutated in-place
> (MatSetValues and per-iteration recurrences and diagnostics).
>
> Also, distributed memory systems have famously different failure
> semantics than non-distributed systems.
>
> For these reasons, I think it will be challenging to write a nice
> functional interface to PETSc.  The obvious thing is to put it in a
> monad, but I think that would be a desperately hard sell for other
> Haskell users.