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.di...@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.di...@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 > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
