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

[Martin Diehl]

pls find attached an image for advertising, I hope (mis)using the PETSc
logo is ok. The deadline is already on April 2

On Sat, 2024-03-23 at 21:46 -0600, Jed Brown wrote:
> Looks good to me. Thanks for taking the initiative.
> 
> Martin Diehl <martin.diehl at kuleuven.be> writes:
> 
> > Dear All,
> > 
> > pls. find attached the proposal for
> > https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas
> > .
> > 
> > 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 <bsmith at 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://fortranwiki.org/fortran/show/Generating+C+Interfaces
> > > 
> > > And discussion:
> > > 
> > > https://fortran-lang.discourse.group/t/iso-c-binding-looking-for-practical-example-of-how-it-helps-with-mangling/3393/8
> > > 
> > > 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://petsc.org)
> > 
> > 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](http://wgropp.cs.illinois.edu/projects/software/sowing/bfor
> > t/bfort.htm).
> > 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://petsc.org)
> >  *
> > [bfort](http://wgropp.cs.illinois.edu/projects/software/sowing/bfor
> > t/bfort.htm)
> >  * [Fortran Wiki: Generating C
> > Interfaces](https://fortranwiki.org/fortran/show/Generating+C+Inter
> > faces)
> >  * [Fortran Discourse:
> > ISO_C_binding](https://fortran-lang.discourse.group/t/iso-c-binding
> > -looking-for-practical-example-of-how-it-helps-with-mangling/3393)
> > 
> > **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)

-- 
KU Leuven
Department of Computer Science
Department of Materials Engineering
Celestijnenlaan 200a
3001 Leuven, Belgium

-------------- next part --------------
A non-text attachment was scrubbed...
Name: petsc_loves_fortran.png
Type: image/png
Size: 146740 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240328/86cb4734/attachment-0001.png>
-------------- 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/20240328/86cb4734/attachment-0001.sig>