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

[Martin Diehl]

Dear Barry, all,

pls find my comments below.

On Thu, 2024-03-21 at 13:19 -0400, Barry Smith wrote:
> 
>    Martin,
> 
>     Thanks for the suggestions and offer.
> 
>     The tool we use for automatically generating the Fortran stubs
> and interfaces is bfort. 
> 
>      Its limitations include that it cannot handle string arguments
> automatically and cannot generate more than one interface for a
> function. This is why we need to provide these manually (the use of
> a,b,... is to prevent long lines and the need for continuations in
> the definitions of the interfaces).
This should be fixable: Either tell the compiler to accept long lines
or introduce line breaks if needed.
> 
>      Adding support for strings is very straightforward, just a
> little more smarts in bfort.
perfect. If I remember correctly, a lot of interfaces that I
contributed where needed because of strings.
> 
>      Adding support for multiple interface generation is a bit
> trickier because the code must (based on the C calling sequence)
> automatically determine all the combinations of array vs single value
> the interfaces should generate and then generate a Fortran stub for
> each (all mapping back to the same master stub for that function).
> I've talked to Bill Gropp about having him add such support, but he
> simply does not have time for such work so most recent work on the
> bfort that PETSc uses has been by us.
I don't have the time either, hence the idea to search for someone paid
by google.
> 
>      We've always had some tension between adding new features to
> bfort vs developing an entirely new tool (for example in Python
> (maybe calling a little LLVM to help parse the C function), for maybe
> there is already a tool out there) to replace bfort. Both approaches
> have their advantages and disadvantages instead we've relied on the
> quick and dirty of providing the interfaces as needed). We have not
> needed the Fortran standard C interface stuff and I would prefer not
> to use it unless it offers some huge advantage).
both approaches (improving bfort or writing something new) are fine
with me. Regarding the Fortran standard interfacing: Are your main
concern the use of ISO_Fortran_binding.h on the C side? (see
https://fortran-lang.discourse.group/t/examples-iso-c-binding-calling-fortran-from-c/4149/3
). Other language features (like the '*' to indicate 'any type') on the
Fortran side are already used as far as I know.

> 
>     Thoughts?
> 
>    Barry
> 
> 
> 
>      
> 
> 
> 
> > On Mar 21, 2024, at 12:21 PM, Martin Diehl
> > <martin.diehl at kuleuven.be> wrote:
> > 
> > Dear PETSc team,
> > 
> > I've worked on Fortran interfaces (see
> > https://gitlab.com/petsc/petsc/-/issues/1540) but could not get far
> > in
> > the time I could afford.
> > 
> > In discussion with Javier (in CC) the idea came up to propose to
> > offer
> > the work on Fortran interfaces for PETSc as a Google Summer of Code
> > project.
> > 
> > fortran-lang has been accepted as organization and the current
> > projects
> > are on:
> > https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas
> > 
> > The main work would be the automatization of interfaces that are
> > currently manually created via Python. This includes an improved
> > user
> > experience, because correct variable names (not a, b, c) can be
> > used.
> > It should be also possible to automatically create descriptions of
> > the
> > enumerators.
> > 
> > As outlook tasks, I would propose:
> > - check whether a unified automatization script can also replace
> > the
> > current tool for creation of interfaces.
> > - investigate improved handling of strings (there are ways in newer
> > standards).
> > 
> > I can offer to do the supervision, but would certainly need
> > guidance
> > and the ok from the PETSc core team.
> > 
> > best regards,
> > 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

-------------- 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/20240321/e8d06f30/attachment-0001.sig>