Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
Looks good to me. Thanks for taking the initiative. Martin Diehl 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$. ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Looks good to me. Thanks for taking the initiative. Martin Diehl 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 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
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
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 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/bfort/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) *
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
Barry Smith 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Barry Smith 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!YxEvDc1D4VU4lVeRBtAnpLnK6bOtF5usV8GsUXqiSsukaNrK5znZB16c7n5VUgIqFwNTGEkSEppdwFVuJSM$ 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!YxEvDc1D4VU4lVeRBtAnpLnK6bOtF5usV8GsUXqiSsukaNrK5znZB16c7n5VUgIqFwNTGEkSEppdx1pKPgQ$ 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.
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
> On Mar 21, 2024, at 6:35 PM, Jed Brown wrote: > > Barry Smith writes: > >> In my limited understanding of the Fortran iso_c_binding, if we do not >> provide an equivalent Fortran stub (the user calls) that uses the >> iso_c_binding to call PETSc C code, then when the user calls PETSc C code >> directly via the iso_c_binding they have to pass iso_c_binding type >> arguments to the call. This I consider unacceptable. So my conclusion was >> there is the same number of stubs, just in a different language, so there is >> no reason to consider changing since we cannot "delete lots of stubs", but I >> could be wrong. > > I don't want users to deal with iso_c_binding manually. > > 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. > 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.. > I don't know if this change would enable inlining without LTO, though I think > the indirection through our C sourcef.c is rarely a performance factor for > Fortran users.
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
On Thu, 2024-03-21 at 16:35 -0600, Jed Brown wrote: > Barry Smith writes: > > > In my limited understanding of the Fortran iso_c_binding, if we do > > not provide an equivalent Fortran stub (the user calls) that uses > > the iso_c_binding to call PETSc C code, then when the user calls > > PETSc C code directly via the iso_c_binding they have to pass > > iso_c_binding type arguments to the call. This I consider > > unacceptable. So my conclusion was there is the same number of > > stubs, just in a different language, so there is no reason to > > consider changing since we cannot "delete lots of stubs", but I > > could be wrong. > > I don't want users to deal with iso_c_binding manually. > > 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. 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. I think for "easy" functions, interfaces are sufficient. The only change I propose with my current knowledge would be the use of "bind(C)" on the Fortran side to get rid of the preprocessor statements for name mangling. For complicated functions, e.g. those having a string argument, I currently use an interface that tells Fortran how the C function looks like and a function definition that translates the Fortran string to a C string. > > I don't know if this change would enable inlining without LTO, though > I think the indirection through our C sourcef.c is rarely a > performance factor for Fortran users. From the discussion, I conclude that there is general interest in the topic and I would suggest that I go ahead and propose the topic. The first task would then the comparison of different approaches for the automated generation of interfaces -- KU Leuven Department of Computer Science Department of Materials Engineering Celestijnenlaan 200a 3001 Leuven, Belgium signature.asc Description: This is a digitally signed message part
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
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 > > 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 signature.asc Description: This is a digitally signed message part
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
Barry Smith writes: > In my limited understanding of the Fortran iso_c_binding, if we do not provide an equivalent Fortran stub (the user calls) that uses the iso_c_binding to call PETSc C code, then when the user ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Barry Smith writes: > In my limited understanding of the Fortran iso_c_binding, if we do not provide an equivalent Fortran stub (the user calls) that uses the iso_c_binding to call PETSc C code, then when the user calls PETSc C code directly via the iso_c_binding they have to pass iso_c_binding type arguments to the call. This I consider unacceptable. So my conclusion was there is the same number of stubs, just in a different language, so there is no reason to consider changing since we cannot "delete lots of stubs", but I could be wrong. I don't want users to deal with iso_c_binding manually. 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. 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. I don't know if this change would enable inlining without LTO, though I think the indirection through our C sourcef.c is rarely a performance factor for Fortran users.
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
> On Mar 21, 2024, at 5: 19 PM, Jed Brown wrote: > > Barry Smith writes: > >> We've always had some tension between adding new features to bfort vs developing an entirely new ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd > On Mar 21, 2024, at 5:19 PM, Jed Brown wrote: > > Barry Smith writes: > >> 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. > > Note that depending on LLVM (presumably libclang) is a nontrivial dependency if the users don't already have it installed on their systems. I'm all for making it easier to extend the stub generator, but an equally-hacky pybfort wouldn't make much difference. If some better tools have emerged or we have a clear idea for a better design, let's discuss that. > >> 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). > > Mainly that lots of C stubs could be deleted in favor of iso_c_binding. In my limited understanding of the Fortran iso_c_binding, if we do not provide an equivalent Fortran stub (the user calls) that uses the iso_c_binding to call PETSc C code, then when the user calls PETSc C code directly via the iso_c_binding they have to pass iso_c_binding type arguments to the call. This I consider unacceptable. So my conclusion was there is the same number of stubs, just in a different language, so there is no reason to consider changing since we cannot "delete lots of stubs", but I could be wrong.
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
Barry Smith writes: > 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Barry Smith writes: > 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. Note that depending on LLVM (presumably libclang) is a nontrivial dependency if the users don't already have it installed on their systems. I'm all for making it easier to extend the stub generator, but an equally-hacky pybfort wouldn't make much difference. If some better tools have emerged or we have a clear idea for a better design, let's discuss that. > 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). Mainly that lots of C stubs could be deleted in favor of iso_c_binding.
Re: [petsc-users] Fortran interfaces: Google Summer of Code project?
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 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
[petsc-users] Fortran interfaces: Google Summer of Code project?
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 signature.asc Description: This is a digitally signed message part
