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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd
   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).

     Adding support for strings is very straightforward, just a little more smarts in bfort. 

     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.

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

    Thoughts?

   Barry



     



> On Mar 21, 2024, at 12:21 PM, Martin Diehl <martin.di...@kuleuven.be> wrote:
> 
> Dear PETSc team,
> 
> I've worked on Fortran interfaces (see
> https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/issues/1540__;!!G_uCfscf7eWS!Z2hB888HeDFnBuJk3ArQd9Lx0RRQuRSNQOAcJo8skOxRMZ5_V4fU8Ss6mn2AEQ-4Jn6tWTEhS-o5TzXOdkf8tNc$) 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://urldefense.us/v3/__https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas__;!!G_uCfscf7eWS!Z2hB888HeDFnBuJk3ArQd9Lx0RRQuRSNQOAcJo8skOxRMZ5_V4fU8Ss6mn2AEQ-4Jn6tWTEhS-o5TzXO0g4xW4w$
> 
> 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

Reply via email to