[petsc-dev] PETSc future starting as a new design layer that runs on top of PETSc 3?

[Jeremy L Thompson]

I feel like someone has to mention the possibility of Rust.

In libCEED, we've found the FFI to C fairly painless. We made some 
improvements on the core C code of libCEED to facilitate Rust error 
handling and data ownership.

 From various prototyping we've done in Jed's group, I think the more 
complex data ownership used in PETSc (as compared to libCEED) is one of 
the more complex issues that would need to be planned out for a Rust 
focused interface.

On 7/25/22 15:34, Barry Smith wrote:
>
>    A  major problem with writing a completely new version of a large 
> code base is that one has to start with nothing and slowly build up to 
> everything, which can take years. Years in which you need to continue 
> to maintain the old version, people want to continue to add 
> functionality to the old version, and people want to continue to use 
> the old version because the new version doesn't have "the 
> functionality the user needs" ready yet.
>
>   Is there an approach where we can have a new PETSc 
> API/language/paradigm but start with a very thin layer on the current 
> API so it just works from day one?
>
>   * to this would seem to require if PETSc future is not in C, there
>     has to be a very, very easy way and low error-prone way to wrap
>     PETSc current to be called from the new language. For example, how
>     petsc4py wraps seems too manual and too error-prone. C++ can
>     easily and low-error prone call C, any other viable candidates?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220726/d103980a/attachment.html>