[petsc-users] Fortran interfaces: Google Summer of Code 2025?

[Martin Diehl]

Hello Barry,

nice. I will work with Tapashree on the proposal and include these
aspects if space permits.

We will also announce it on the Fortran Discourse. I recently also
connected to Ivan Pribec who gave the following talk ad FOSDEM:

https://fosdem.org/2025/schedule/event/fosdem-2025-6509-easier-api-interoperability-writing-a-bindings-generator-to-c-c-with-coccinelle/


best regards,
Martin

On Fri, 2025-03-14 at 12:33 -0400, Barry Smith wrote:
>    
> Martin,
> 
>     Thanks for the email, additional improvements are definitely
> possible and desirable.
> 
>     To me the most powerful would be the automatic generation of
> Fortran stubs for suboutines that return arrays. There are 
> two "styles" of these in the PETSc C API, 
> 
> *  in the first case the length of the array is passed as the
> argument before the pointer to the array
> 
> PETSC_EXTERN void dmplexgettransitiveclosure_(DM *dm, PetscInt *p,
> PetscBool *useCone, PetscInt *N, F90Array1d *ptr, int *ierr
> PETSC_F90_2PTR_PROTO(ptrd))
> {
>   PetscInt *v = NULL;
>   PetscInt  n;
> 
>   CHKFORTRANNULL(N);
>   *ierr = DMPlexGetTransitiveClosure(*dm, *p, *useCone, &n, &v);
>   if (*ierr) return;
>   *ierr = F90Array1dCreate((void *)v, MPIU_INT, 1, n * 2, ptr
> PETSC_F90_2PTR_PARAM(ptrd));
>   if (N) *N = n;
> }
> 
> If we "mark" the source code with, for example,
> 
> PetscErrorCode DMPlexGetTransitiveClosure(DM dm, PetscInt p,
> PetscBool useCone, PeAL PetscInt *numPoints, PetscInt *points[])
> 
> the getAPI() code will know the length of the array is the argument
> numPoints and thus all the information for generating the Fortran
> stub is available and it can be generated automatically.
> 
> * in the second case the length of the array is not directly
> available
> 
> PETSC_EXTERN void vecgetarray_(Vec *x, F90Array1d *ptr, int *ierr
> PETSC_F90_2PTR_PROTO(ptrd))
> {
>   PetscScalar *fa;
>   PetscInt     len;
>   *ierr = VecGetArray(*x, &fa);
>   if (*ierr) return;
>   *ierr = VecGetLocalSize(*x, &len);
>   if (*ierr) return;
>   *ierr = F90Array1dCreate(fa, MPIU_SCALAR, 1, len, ptr
> PETSC_F90_2PTR_PARAM(ptrd));
> }
> 
> The Fortran stub cannot be generated automatically without some hint.
> Is there some way we can mark in the PETSc source a
> hint that indicates how to access the needed length. In this case by
> calling VecGetLocalSize(*x,&len); for example use
> 
> PetscErrorCode VecGetArray(Vec x, PeALE(n,VecGetLocalSize(x,n))
> PetscScalar *a[]) 
> 
> From this the getAPI() parser will have all the information needed to
> generate the Fortran stub. I haven't picked a syntax for providing
> this information; above is just a suggestion that is trivial to parse
> but probably also has downsides.
> 
> So I concur with your suggestion to submit to fortran-lang.org
> 
> Barry
> 
> 
> 
> 
> 
> > On Mar 14, 2025, at 10:41 AM, Martin Diehl
> > <martin.diehl at kuleuven.be> wrote:
> > 
> > Barry,
> > 
> > for other languages, we can't rely on fortran-lang.org but NumFOCUS
> > seems to be an option.
> > After trying out the branch for 7517, I have some ideas for further
> > Fortran work as outlined in the attached document (same for md and
> > pdf). My suggestion would be to apply via fortran-lang.org with
> > Tapashree (in CC). If that results in better Python code, it should
> > also be useful for other languages.
> > 
> > Martin
> > 
> > 
> > On Thu, 2025-01-30 at 09:54 -0500, Barry Smith wrote:
> > > 
> > >    Martin,
> > > 
> > >    I have restarted in the last week on 7517 and plan for it to
> > > be in
> > > the March release. 
> > > 
> > >    As part of the work I have developed new Pythoncode  that
> > > scraps
> > > the code for signatures for all the functions, enums, objects etc
> > > and
> > > from this constructs the Fortran binding. The same scraping could
> > > be
> > > used for other languages so I am hoping automatic bindings can be
> > > done for other languages, for example Rust, even Python. So
> > > perhaps
> > > we should consider a summer of code project for other such
> > > languages?
> > > 
> > >    Barry
> > > 
> > > 
> > > > On Jan 30, 2025, at 6:13 AM, Martin Diehl
> > > > <martin.diehl at kuleuven.be> wrote:
> > > > 
> > > > Dear PETSc team, dear Barry,
> > > > 
> > > > applications for the Google Summer of Code will start again and
> > > > I
> > > > was
> > > > wondering if help for the re-factoring of the Fortran
> > > > interfaces is
> > > > still needed. Whether this makes sense depends on the progress
> > > > of 
> > > > https://gitlab.com/petsc/petsc/-/merge_requests/7517
> > > > 
> > > > In contrast to the failed attempt last year, I have a student
> > > > interested in working on this topic. 
> > > > 
> > > > Martin
> > > > -- 
> > > > KU Leuven
> > > > Department of Computer Science
> > > > Department of Materials Engineering
> > > > Celestijnenlaan 200a
> > > > 3001 Leuven, Belgium
> > > > 
> > > 
> > 
> > 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20250318/e42681a3/attachment.sig>