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

[Barry Smith]

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 <https://urldefense.us/v3/__http://fortran-lang.org/__;!!G_uCfscf7eWS!ewziLrHj9PbFBj6hTuPTF5QkS9JsrYqgm7k5F1usVchfc8wMFAEvHL8IZhxCe5Z_6L--4Z-3WxqPewkYzHIZkNY$ >

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://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/7517__;!!G_uCfscf7eWS!ewziLrHj9PbFBj6hTuPTF5QkS9JsrYqgm7k5F1usVchfc8wMFAEvHL8IZhxCe5Z_6L--4Z-3WxqPewkYzjhgLq4$ 
>>> 
>>> 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
>>> 
>> 
> 
> 
> -- 
> KU Leuven
> Department of Computer Science
> Department of Materials Engineering
> Celestijnenlaan 200a
> 3001 Leuven, Belgium
> 
> <ideas.md><ideas.pdf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20250314/cd466f00/attachment.html>