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

[Matthew Knepley]

On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsmith at petsc.dev> 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?
>
> This looked like the most promising thing about Zig. We could develop the
new modules alongside the existing C, and throw them away
if we decide it is not worth it.

   Matt

-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220726/21a3c798/attachment-0001.html>