This Message Is From an External Sender
This message came from outside your organization.
Looks good to me. Thanks for taking the initiative.
Martin Diehl <martin.di...@kuleuven.be> writes: > Dear All, > > pls. find attached the proposal for > https://urldefense.us/v3/__https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlg65QIRo$. > > I tried to keep it general such that we keep all options open. > > Let me know if you want to change/add/remove anything and/or if you > want to be listed as mentor. > > Since I've mixed up the deadline, the most urgent task is the finding > of suitable candidates. Once it's online, I'll post on linkedin but > ideally we can motivate someone who is already known. > > best regards, > Martin > > On Thu, 2024-03-21 at 23:13 -0600, Jed Brown wrote: >> Barry Smith <bsm...@petsc.dev> writes: >> >> > > We already have the generated ftn-auto-interfaces/*.h90. The >> > > INTERFACE keyword could be replaced with CONTAINS (making these >> > > definitions instead of just interfaces), and then the bodies >> > > could use iso_c_binding to call the C functions. That would >> > > reduce repetition and be the standards-compliant way to do this. >> > >> > Sure, the interface and the stub go in the same file instead of >> > two files. This is slightly nicer but not significantly simpler, >> > and alone, it is not reason enough to write an entire new stub >> > generator. >> >> I agree, but if one *is* writing a new stub generator for good >> reasons (like better automation/completeness), there's a case for >> doing it this way unless users really need an environment in which >> that feature can't be used. >> >> > > What we do now with detecting the Fortran mangling scheme and >> > > calling conventions "works" but doesn't conform to any standard >> > > and there's nothing stopping Fortran implementations from >> > > creating yet another variant that we have to deal with manually. >> > >> > From practical experience, calling C/Fortran using non-standards >> > has only gotten easier over the last thirty-five years (fewer >> > variants on how char* is handled); it has not gotten more >> > complicated, so I submit the likelihood of "nothing stopping >> > Fortran implementations from creating yet another variant that we >> > have to deal with manually" is (though possible) rather unlikely. >> > As far as I am concerned, much of iso_c_binding stuff just solved a >> > problem that never really existed (except in some people's minds) >> > since calling C/Fortran has always been easy, modulo knowing a tiny >> > bit of information.. >> >> An examples for concreteness: >> >> https://urldefense.us/v3/__https://fortranwiki.org/fortran/show/Generating*C*Interfaces__;Kys!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlsKy54Ps$ >> >> And discussion: >> >> https://urldefense.us/v3/__https://fortran-lang.discourse.group/t/iso-c-binding-looking-for-practical-example-of-how-it-helps-with-mangling/3393/8__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlVTiuUTk$ >> >> With this approach, one could even use method syntax like >> ksp%SetOperators(J, Jpre), as in the nlopt-f project linked in the >> top of this question. I don't know if we want that (it would be a >> huge change for users, albeit it "easy"), but generating stubs in >> Fortran using iso_c_binding opens a variety of possibilities for more >> idiomatic bindings. > > -- > KU Leuven > Department of Computer Science > Department of Materials Engineering > Celestijnenlaan 200a > 3001 Leuven, Belgium > # Improved generation of Fortran interfaces for [PETSc](https://urldefense.us/v3/__https://petsc.org__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTljowbJv0$) > > PETSc, the Portable, Extensible Toolkit for Scientific Computation, pronounced PET-see, is for the scalable (parallel) solution of scientific applications modeled by partial differential equations (PDEs). > It has bindings for C, Fortran, and Python (via petsc4py). PETSc also contains TAO, the Toolkit for Advanced Optimization, software library. It supports MPI, and GPUs through CUDA, HIP, Kokkos, or OpenCL, as well as hybrid MPI-GPU parallelism; it also supports the NEC-SX Tsubasa Vector Engine. > > Currently, only a part of the Fortran interfaces can be generated automatically using [bfort](https://urldefense.us/v3/__http://wgropp.cs.illinois.edu/projects/software/sowing/bfort/bfort.htm__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlvY6s81A$). > Since the manual generation of the remaining interfaces is tedious and error prone, this project is about an improved generation of Fortran interfaces from PETSc's C code. > > The main tasks of this project are > > * Definition of a robust and future-proof structure for the Fortran interfaces > * Selection and/or development of a tool that creates the interfaces automatically > > > More specifically, the first task is about finding a suitable structure of the C-to-Fortran interface that reduces the need of 'stubs' on the C and Fortran side making use of modern Fortran features where appropriate. > This task will involve evaluating different approaches found in other projects taking into account the object-oriented approach of PETSc. > Prototypes will be implemented manually and evaluated with the help of the PETSc community. > The second task is then the automated generation of the Fortran interfaces using the approach selected in the first task. > To this end, it will be evaluated whether an extension of bfort, the use of another existing tool, or the development of a completely new tool (probably in Python) is the most suitable approach. > > **Links**: > > * [PETSc](https://urldefense.us/v3/__https://petsc.org__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTljowbJv0$) > * [bfort](https://urldefense.us/v3/__http://wgropp.cs.illinois.edu/projects/software/sowing/bfort/bfort.htm__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlvY6s81A$) > * [Fortran Wiki: Generating C Interfaces](https://urldefense.us/v3/__https://fortranwiki.org/fortran/show/Generating*C*Interfaces__;Kys!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlsKy54Ps$) > * [Fortran Discourse: ISO_C_binding](https://urldefense.us/v3/__https://fortran-lang.discourse.group/t/iso-c-binding-looking-for-practical-example-of-how-it-helps-with-mangling/3393__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlOb4tzTs$) > > **Expected outcomes**: Stable and robust autogeneration of Fortran interfaces for PETSc that works for almost all routines > > **Skills preferred**: Programming experience in multiple languages, ideally C and/or Fortran > > **Difficulty**: Intermediate, 320 hours > > **Mentors**: Martin Diehl (@MarDiehl)
