Re: [petsc-dev] Fortran interface problem in v.3.10.2
Hi Adrian, thanks. Please find attached the modified version of the example. Seems to work (at least compiles) Martin On Fri, 2018-11-09 at 13:04 +1300, Adrian Croucher wrote: > hi Martin, > > Sure, here it is. > > - Adrian > > On 9/11/18 12:34 PM, Martin Diehl wrote: > > Dear Adrian, > > > > I looked into the issue of passing in derived types with type bound > > procedures again and it seems that casting to C pointers is a > > suitable > > alternative. > > > > To investigate that, I modified ex5f.F90 from > > src/snes/examples/tutorials in a branch of my PETSc fork: > > > > https://bitbucket.org/m_diehl/petsc/src/5172a911a5cc8a6228f00f2435cc5cfe6ec569d9/?at=m.diehl%2FSNESSetConvergenceTestTypeFortran > > > > > > Could you please send me your original minimal working example > > again? > > I've deleted it and would like to test the new approach there also. > > > > many thanks > > Martin > > -- --- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 - Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de module context_module #include use petsc implicit none private type, public :: context_type private PetscInt :: foo contains procedure, public :: init => context_init end type context_type contains subroutine context_init(self, foo) class(context_type), intent(in out) :: self PetscInt, intent(in) :: foo self%foo = foo end subroutine context_init end module context_module ! program test_snes ! tests SNESSetConvergenceTest() #include use iso_c_binding use petsc use context_module implicit none SNES :: snes type(context_type),target :: context type(c_ptr) :: contextOut PetscErrorCode :: ierr call PetscInitialize(PETSC_NULL_CHARACTER, ierr) call SNESCreate(PETSC_COMM_WORLD, snes, ierr) call context%init(1) contextOut = c_loc(context) ! contextOut is a C pointer on context call SNESSetConvergenceTest(snes, convergence, contextOut, & ! pass in the pointer PETSC_NULL_FUNCTION, ierr) call SNESDestroy(snes, ierr) call PetscFinalize(ierr) contains subroutine convergence(snes, num_iterations, xnorm, pnorm, & fnorm, reason, contextIn, ierr) SNES, intent(in) :: snes PetscInt, intent(in) :: num_iterations PetscReal, intent(in) :: xnorm, pnorm, fnorm SNESConvergedReason, intent(out) :: reason type(c_ptr), intent(in out) :: contextIn type(context_type), pointer :: context PetscErrorCode, intent(out) :: ierr call c_f_pointer(contextIn,context) ! convert the C pointer to a Fortran pointer to use context as in the main program reason = 0 ierr = 0 end subroutine convergence end program test_snes signature.asc Description: This is a digitally signed message part
Re: [petsc-dev] Fortran interface problem in v.3.10.2
hi Martin, Sure, here it is. - Adrian On 9/11/18 12:34 PM, Martin Diehl wrote: Dear Adrian, I looked into the issue of passing in derived types with type bound procedures again and it seems that casting to C pointers is a suitable alternative. To investigate that, I modified ex5f.F90 from src/snes/examples/tutorials in a branch of my PETSc fork: https://bitbucket.org/m_diehl/petsc/src/5172a911a5cc8a6228f00f2435cc5cfe6ec569d9/?at=m.diehl%2FSNESSetConvergenceTestTypeFortran Could you please send me your original minimal working example again? I've deleted it and would like to test the new approach there also. many thanks Martin -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.crouc...@auckland.ac.nz tel: +64 (0)9 923 4611 module context_module #include use petsc implicit none private type, public :: context_type private PetscInt :: foo contains procedure, public :: init => context_init end type context_type contains subroutine context_init(self, foo) class(context_type), intent(in out) :: self PetscInt, intent(in) :: foo self%foo = foo end subroutine context_init end module context_module ! program test_snes ! tests SNESSetConvergenceTest() #include use petsc use context_module implicit none SNES :: snes type(context_type) :: context PetscErrorCode :: ierr call PetscInitialize(PETSC_NULL_CHARACTER, ierr) call SNESCreate(PETSC_COMM_WORLD, snes, ierr) call context%init(1) call SNESSetConvergenceTest(snes, convergence, context, & PETSC_NULL_FUNCTION, ierr) call SNESDestroy(snes, ierr) call PetscFinalize(ierr) contains subroutine convergence(snes, num_iterations, xnorm, pnorm, & fnorm, reason, context, ierr) SNES, intent(in) :: snes PetscInt, intent(in) :: num_iterations PetscReal, intent(in) :: xnorm, pnorm, fnorm SNESConvergedReason, intent(out) :: reason type(context_type), intent(in out) :: context PetscErrorCode, intent(out) :: ierr reason = 0 ierr = 0 end subroutine convergence end program test_snes
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Dear Adrian, I looked into the issue of passing in derived types with type bound procedures again and it seems that casting to C pointers is a suitable alternative. To investigate that, I modified ex5f.F90 from src/snes/examples/tutorials in a branch of my PETSc fork: https://bitbucket.org/m_diehl/petsc/src/5172a911a5cc8a6228f00f2435cc5cfe6ec569d9/?at=m.diehl%2FSNESSetConvergenceTestTypeFortran Could you please send me your original minimal working example again? I've deleted it and would like to test the new approach there also. many thanks Martin -- --- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 - Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de signature.asc Description: This is a digitally signed message part
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Hi, again some news on this topic. First, the Intel Fortran engineer revoked his statement regarding the standard, so derived types with type-bound procedures cannot be passed to type(*) dummy arguments. There is another solution, but that seems to require explicit type casting. I'll have a closer look on it in the next days. Currently, I cannot think of a good solution without any limitations. regards, Martin On Tue, 2018-10-23 at 18:53 +0200, Martin Diehl wrote: > Hi, > > some more information on this topic. > > First, Adrians code is not wrong. The statement on the IBM homepage > regarding type(*) and type-bound procedures is according to my > current > understanding simply not true. > However, type(*) is a feature of Fortran 2018, a standard that is not > even published. > > My information mainly comes from the Intel developer zone, see > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 > and I have also informed the GCC/gfortran developers, > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87707. > I hope to get some more information in the next day and will keep you > updated. > > best regards, > Martin > > > > On Tue, 2018-10-23 at 17:25 +1300, Adrian Croucher wrote: > > hi > > > > Thanks to you both for looking into this. > > > > It sounds like if we want type checking in the PETSc Fortran > > interfaces, > > which I agree is a useful thing, then no compilers are going to > > support > > passing in these derived types with type-bound procedures via > > type(*) > > interfaces anytime soon. > > > > In my case the derived-type objects I'm passing in to > > SNESSetConvergenceTest() don't really need to have type-bound > > procedures > > (the derived type doesn't get subclassed, and there aren't really > > any > > data-hiding considerations), it's mostly just a style thing so that > > they > > work similarly to other derived types in the code. So I could > > fairly > > easily just turn the type-bound procedures into ordinary > > subroutines, > > not bound to any derived type. > > > > That might be the simplest fix for me. I suppose this issue could > > still > > affect other people, but maybe not a lot of people are using PETSc > > with > > F2003. > > > > - Adrian > > > > On 23/10/18 2:55 AM, Martin Diehl wrote: > > > > I'm sorry, I don't understand. Are you saying that the > > > > example > > > > code is not correct Fortran? > > > > > > In the case that your interface has a type(*) argument, it is not > > > valid > > > Fortran because 'context_type' contains the type-bound procedure > > > 'context_init'. That is why the GNU compiler complains when the > > > interface exists. Apparently, without the interface it accepts > > > it, > > > so > > > not having an interface would be a solution in that case. > > > However, > > > the > > > Intel compiler will fail during linking with or without > > > interface, > > > so > > > it does not seem to be a general solution. > > > At the moment, I believe that one simply has to live with the > > > limitations that type(*) imposes on the data that can be passed > > > to > > > void*. To clarify this, I opened a thread in the Intel developer > > > zone > > > and will keep you updated > > > > > > > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 > > > -- --- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 - Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de - Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de -
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Hi, some more information on this topic. First, Adrians code is not wrong. The statement on the IBM homepage regarding type(*) and type-bound procedures is according to my current understanding simply not true. However, type(*) is a feature of Fortran 2018, a standard that is not even published. My information mainly comes from the Intel developer zone, see https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 and I have also informed the GCC/gfortran developers, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87707. I hope to get some more information in the next day and will keep you updated. best regards, Martin On Tue, 2018-10-23 at 17:25 +1300, Adrian Croucher wrote: > hi > > Thanks to you both for looking into this. > > It sounds like if we want type checking in the PETSc Fortran > interfaces, > which I agree is a useful thing, then no compilers are going to > support > passing in these derived types with type-bound procedures via > type(*) > interfaces anytime soon. > > In my case the derived-type objects I'm passing in to > SNESSetConvergenceTest() don't really need to have type-bound > procedures > (the derived type doesn't get subclassed, and there aren't really > any > data-hiding considerations), it's mostly just a style thing so that > they > work similarly to other derived types in the code. So I could fairly > easily just turn the type-bound procedures into ordinary > subroutines, > not bound to any derived type. > > That might be the simplest fix for me. I suppose this issue could > still > affect other people, but maybe not a lot of people are using PETSc > with > F2003. > > - Adrian > > On 23/10/18 2:55 AM, Martin Diehl wrote: > > > I'm sorry, I don't understand. Are you saying that the > > > example > > > code is not correct Fortran? > > > > In the case that your interface has a type(*) argument, it is not > > valid > > Fortran because 'context_type' contains the type-bound procedure > > 'context_init'. That is why the GNU compiler complains when the > > interface exists. Apparently, without the interface it accepts it, > > so > > not having an interface would be a solution in that case. However, > > the > > Intel compiler will fail during linking with or without interface, > > so > > it does not seem to be a general solution. > > At the moment, I believe that one simply has to live with the > > limitations that type(*) imposes on the data that can be passed to > > void*. To clarify this, I opened a thread in the Intel developer > > zone > > and will keep you updated > > > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 > > -- --- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 - Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de - Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact r...@mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de -
Re: [petsc-dev] Fortran interface problem in v.3.10.2
hi Thanks to you both for looking into this. It sounds like if we want type checking in the PETSc Fortran interfaces, which I agree is a useful thing, then no compilers are going to support passing in these derived types with type-bound procedures via type(*) interfaces anytime soon. In my case the derived-type objects I'm passing in to SNESSetConvergenceTest() don't really need to have type-bound procedures (the derived type doesn't get subclassed, and there aren't really any data-hiding considerations), it's mostly just a style thing so that they work similarly to other derived types in the code. So I could fairly easily just turn the type-bound procedures into ordinary subroutines, not bound to any derived type. That might be the simplest fix for me. I suppose this issue could still affect other people, but maybe not a lot of people are using PETSc with F2003. - Adrian On 23/10/18 2:55 AM, Martin Diehl wrote: I'm sorry, I don't understand. Are you saying that the example code is not correct Fortran? In the case that your interface has a type(*) argument, it is not valid Fortran because 'context_type' contains the type-bound procedure 'context_init'. That is why the GNU compiler complains when the interface exists. Apparently, without the interface it accepts it, so not having an interface would be a solution in that case. However, the Intel compiler will fail during linking with or without interface, so it does not seem to be a general solution. At the moment, I believe that one simply has to live with the limitations that type(*) imposes on the data that can be passed to void*. To clarify this, I opened a thread in the Intel developer zone and will keep you updated https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.crouc...@auckland.ac.nz tel: +64 (0)9 923 4611
Re: [petsc-dev] Fortran interface problem in v.3.10.2
On Sat, 2018-10-20 at 17:51 +, Smith, Barry F. wrote: > > On Oct 20, 2018, at 12:43 PM, Martin Diehl wrote: > > > > From: "Smith, Barry F." > > To: Martin Diehl > > Cc: Adrian Croucher , For users of the > > development version of PETSc > > Sent: 10/20/2018 6:22 PM > > Subject: Re: [petsc-dev] Fortran interface problem in v.3.10.2 > > > > > > > > > On Oct 20, 2018, at 6:13 AM, Martin Diehl > > > wrote: > > > > > > Barry, Adrian, > > > > > > I looked into this and found the following on type(*) from IBM > > > > > > https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html > > > > > > > > > To summarize, type(*) is exactly meant for C interfaces with > > > void* > > > dummy arguments (sorry for the Fortran speak, I don't know if > > > dummy > > > argument is a term common in C programming). > > > > > > The last statement is > > > "An assumed-type dummy argument cannot correspond to an actual > > > argument > > > of a derived type that has type parameters, type-bound > > > procedures, or > > > final subroutines." > > > which seems to be the reason why the code does not compile. > > > >I am now concerned that our use of type(*) in PETSc Fortran > > interfaces is just wrong and I see no good solution except to not > > have interface definitions for any Fortran stub routines that have > > void *arguments. > > To my understanding, it is fine. type(*) was meant for interfacing > > *void and that's what you use it for. However, it imposes some > > restrictions on the actual argument. For that reason, Intel Fortran > > does not compile the example code, with or without explicit > > interface. GNU fortran compiles the code without interface, > > presumably because it cannot detect that the code is not standard > > conforming. > >I'm sorry, I don't understand. Are you saying that the example > code is not correct Fortran? In the case that your interface has a type(*) argument, it is not valid Fortran because 'context_type' contains the type-bound procedure 'context_init'. That is why the GNU compiler complains when the interface exists. Apparently, without the interface it accepts it, so not having an interface would be a solution in that case. However, the Intel compiler will fail during linking with or without interface, so it does not seem to be a general solution. At the moment, I believe that one simply has to live with the limitations that type(*) imposes on the data that can be passed to void*. To clarify this, I opened a thread in the Intel developer zone and will keep you updated https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 > > > > I propose to further clarify the situation I'll present the problem > > at the Intel Developer Zone forum. > > > > > > > > > > > Then, I tried the following things: > > > > > > 1) Compiling your code with the current PETSc master and gfortran > > > 8.2 > > > to check whether this issue has been fixed by the GCC > > > developers. > > > > > > It still gives the same error > > > > > > > > > 2) Compiling your code with the Intel Fortran compiler (18.0.1) > > > an the > > > current PETSc master. > > > > > > It gives a very cryptic error > > > /usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference > > > to > > > symbol 'for_set_reentrancy' > > > /opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifco > > > remt.s > > > o.5: error adding symbols: DSO missing from command line > > > See also https://software.intel.com/en-us/node/679295 > > > > > > > > > 3) Compiling your code with the Intel Fortran compiler and either > > > PETSc > > > 3.10.0 or the PETSc master without the Fortran interface for > > > SNESsetConvergenceTest > > > > > > It still gives the same error as for 2) > > > > > > > > > Do you have access to any other compilers to check whether they > > > can > > > compile your application/test_example? > > > > > > best regards > > > Martin > > > > > > > > > > > > > > > On Fri, 2018-10-19 at 19:52 +, Smith, Barry F. wrote: > > > > > > > > Adrian,
Re: [petsc-dev] Fortran interface problem in v.3.10.2
> On Oct 20, 2018, at 12:43 PM, Martin Diehl wrote: > > From: "Smith, Barry F." > To: Martin Diehl > Cc: Adrian Croucher , For users of the development > version of PETSc > Sent: 10/20/2018 6:22 PM > Subject: Re: [petsc-dev] Fortran interface problem in v.3.10.2 > > > > > On Oct 20, 2018, at 6:13 AM, Martin Diehl wrote: > > > > Barry, Adrian, > > > > I looked into this and found the following on type(*) from IBM > > > > https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html > > > > > > To summarize, type(*) is exactly meant for C interfaces with void* > > dummy arguments (sorry for the Fortran speak, I don't know if dummy > > argument is a term common in C programming). > > > > The last statement is > > "An assumed-type dummy argument cannot correspond to an actual argument > > of a derived type that has type parameters, type-bound procedures, or > > final subroutines." > > which seems to be the reason why the code does not compile. > >I am now concerned that our use of type(*) in PETSc Fortran interfaces is > just wrong and I see no good solution except to not have interface > definitions for any Fortran stub routines that have void *arguments. > To my understanding, it is fine. type(*) was meant for interfacing *void and > that's what you use it for. However, it imposes some restrictions on the > actual argument. For that reason, Intel Fortran does not compile the example > code, with or without explicit interface. GNU fortran compiles the code > without interface, presumably because it cannot detect that the code is not > standard conforming. I'm sorry, I don't understand. Are you saying that the example code is not correct Fortran? > > I propose to further clarify the situation I'll present the problem at the > Intel Developer Zone forum. > > > > > > > Then, I tried the following things: > > > > 1) Compiling your code with the current PETSc master and gfortran 8.2 > > to check whether this issue has been fixed by the GCC developers. > > > > It still gives the same error > > > > > > 2) Compiling your code with the Intel Fortran compiler (18.0.1) an the > > current PETSc master. > > > > It gives a very cryptic error > > /usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference to > > symbol 'for_set_reentrancy' > > /opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifcoremt.s > > o.5: error adding symbols: DSO missing from command line > > See also https://software.intel.com/en-us/node/679295 > > > > > > 3) Compiling your code with the Intel Fortran compiler and either PETSc > > 3.10.0 or the PETSc master without the Fortran interface for > > SNESsetConvergenceTest > > > > It still gives the same error as for 2) > > > > > > Do you have access to any other compilers to check whether they can > > compile your application/test_example? > > > > best regards > > Martin > > > > > > > > > > On Fri, 2018-10-19 at 19:52 +, Smith, Barry F. wrote: > >> > >> Adrian, > >> > >> I goggled a bit but couldn't understand anything I found. My guess > >> is that > >> > >> type(*) > >> > >> doesn't work for certain derived types (why not?) perhaps those that > >> contain procedures. If I remove the procedure from the > >> routine it all compiles, thus producing some evidence my theory is > >> correct. > >> > >> So we have a problem. The type checking one user wants is causing > >> another users code to not build. > >> > >> Here is a short term fix you can do. After you run ./configure > >> edit $PETSC_ARCH/include/petscconf.h locate > >> > >> #ifndef PETSC_HAVE_FORTRAN_TYPE_STAR > >> #define PETSC_HAVE_FORTRAN_TYPE_STAR 1 > >> #endif > >> > >> then run make. This will turn off the type checking for all routines > >> that have type(*) arguments which includes SNESSetConvergenceTest > >> > >> I don't have a good long term solution at the moment. Maybe a > >> Fortran expert has some idea. > >> > >> Barry > >> > >> > >> > >> > >> > >> > >> > >>> On Oct 18, 2018, at 10:14 PM, Adrian Croucher < > >> a.crouc...@auckland.ac.nz> wrote
Re: [petsc-dev] Fortran interface problem in v.3.10.2
From: "Smith, Barry F." To: Martin Diehl Cc: Adrian Croucher , For users of the development version of PETSc Sent: 10/20/2018 6:22 PM Subject: Re: [petsc-dev] Fortran interface problem in v.3.10.2 > On Oct 20, 2018, at 6:13 AM, Martin Diehl wrote: > > Barry, Adrian, > > I looked into this and found the following on type(*) from IBM > > https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html > > > To summarize, type(*) is exactly meant for C interfaces with void* > dummy arguments (sorry for the Fortran speak, I don't know if dummy > argument is a term common in C programming). > > The last statement is > "An assumed-type dummy argument cannot correspond to an actual argument > of a derived type that has type parameters, type-bound procedures, or > final subroutines." > which seems to be the reason why the code does not compile. I am now concerned that our use of type(*) in PETSc Fortran interfaces is just wrong and I see no good solution except to not have interface definitions for any Fortran stub routines that have void *arguments. To my understanding, it is fine. type(*) was meant for interfacing *void and that's what you use it for. However, it imposes some restrictions on the actual argument. For that reason, Intel Fortran does not compile the example code, with or without explicit interface. GNU fortran compiles the code without interface, presumably because it cannot detect that the code is not standard conforming. I propose to further clarify the situation I'll present the problem at the Intel Developer Zone forum. > > > Then, I tried the following things: > > 1) Compiling your code with the current PETSc master and gfortran 8.2 > to check whether this issue has been fixed by the GCC developers. > > It still gives the same error > > > 2) Compiling your code with the Intel Fortran compiler (18.0.1) an the > current PETSc master. > > It gives a very cryptic error > /usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference to > symbol 'for_set_reentrancy' > /opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifcoremt.s > o.5: error adding symbols: DSO missing from command line > See also https://software.intel.com/en-us/node/679295 > > > 3) Compiling your code with the Intel Fortran compiler and either PETSc > 3.10.0 or the PETSc master without the Fortran interface for > SNESsetConvergenceTest > > It still gives the same error as for 2) > > > Do you have access to any other compilers to check whether they can > compile your application/test_example? > > best regards > Martin > > > > > On Fri, 2018-10-19 at 19:52 +, Smith, Barry F. wrote: >> >> Adrian, >> >> I goggled a bit but couldn't understand anything I found. My guess >> is that >> >> type(*) >> >> doesn't work for certain derived types (why not?) perhaps those that >> contain procedures. If I remove the procedure from the >> routine it all compiles, thus producing some evidence my theory is >> correct. >> >> So we have a problem. The type checking one user wants is causing >> another users code to not build. >> >> Here is a short term fix you can do. After you run ./configure >> edit $PETSC_ARCH/include/petscconf.h locate >> >> #ifndef PETSC_HAVE_FORTRAN_TYPE_STAR >> #define PETSC_HAVE_FORTRAN_TYPE_STAR 1 >> #endif >> >> then run make. This will turn off the type checking for all routines >> that have type(*) arguments which includes SNESSetConvergenceTest >> >> I don't have a good long term solution at the moment. Maybe a >> Fortran expert has some idea. >> >> Barry >> >> >> >> >> >> >> >>> On Oct 18, 2018, at 10:14 PM, Adrian Croucher < >> a.crouc...@auckland.ac.nz> wrote: >>> >>> hi Barry, >>> >>> On 18/10/18 11:34 AM, Smith, Barry F. wrote: >>>> Sorry about this problem. I think the change was only >> introduced in master and should not affect 3.10.x Please confirm that >> master is where the failed compile is? >>> >>> Yes, it's on master. I have tracked down the commit at which it >> started to fail: 6f222c9d1e, "type checking for Fortran" (Fri Sep >> 28). >>> >>>> Please send us the calling sequence of your routine that won't >> compile (cut and paste). >>> >>> I've attached a min
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Barry, Adrian,
I looked into this and found the following on type(*) from IBM
https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html
To summarize, type(*) is exactly meant for C interfaces with void*
dummy arguments (sorry for the Fortran speak, I don't know if dummy
argument is a term common in C programming).
The last statement is
"An assumed-type dummy argument cannot correspond to an actual argument
of a derived type that has type parameters, type-bound procedures, or
final subroutines."
which seems to be the reason why the code does not compile.
Then, I tried the following things:
1) Compiling your code with the current PETSc master and gfortran 8.2
to check whether this issue has been fixed by the GCC developers.
It still gives the same error
2) Compiling your code with the Intel Fortran compiler (18.0.1) an the
current PETSc master.
It gives a very cryptic error
/usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference to
symbol 'for_set_reentrancy'
/opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifcoremt.s
o.5: error adding symbols: DSO missing from command line
See also https://software.intel.com/en-us/node/679295
3) Compiling your code with the Intel Fortran compiler and either PETSc
3.10.0 or the PETSc master without the Fortran interface for
SNESsetConvergenceTest
It still gives the same error as for 2)
Do you have access to any other compilers to check whether they can
compile your application/test_example?
best regards
Martin
On Fri, 2018-10-19 at 19:52 +, Smith, Barry F. wrote:
>
> Adrian,
>
> I goggled a bit but couldn't understand anything I found. My guess
> is that
>
> type(*)
>
> doesn't work for certain derived types (why not?) perhaps those that
> contain procedures. If I remove the procedure from the
> routine it all compiles, thus producing some evidence my theory is
> correct.
>
> So we have a problem. The type checking one user wants is causing
> another users code to not build.
>
> Here is a short term fix you can do. After you run ./configure
> edit $PETSC_ARCH/include/petscconf.h locate
>
> #ifndef PETSC_HAVE_FORTRAN_TYPE_STAR
> #define PETSC_HAVE_FORTRAN_TYPE_STAR 1
> #endif
>
> then run make. This will turn off the type checking for all routines
> that have type(*) arguments which includes SNESSetConvergenceTest
>
> I don't have a good long term solution at the moment. Maybe a
> Fortran expert has some idea.
>
>Barry
>
>
>
>
>
>
>
> > On Oct 18, 2018, at 10:14 PM, Adrian Croucher <
> a.crouc...@auckland.ac.nz> wrote:
> >
> > hi Barry,
> >
> > On 18/10/18 11:34 AM, Smith, Barry F. wrote:
> >>Sorry about this problem. I think the change was only
> introduced in master and should not affect 3.10.x Please confirm that
> master is where the failed compile is?
> >
> > Yes, it's on master. I have tracked down the commit at which it
> started to fail: 6f222c9d1e, "type checking for Fortran" (Fri Sep
> 28).
> >
> >>Please send us the calling sequence of your routine that won't
> compile (cut and paste).
> >
> > I've attached a minimal example program which fails with the
> following error:
> >
> >call SNESSetConvergenceTest(snes, convergence, context, &
> > 1
> > Error: Actual argument at (1) to assumed-type dummy is of derived
> type with type-bound or FINAL procedures
> >
> > Cheers, Adrian
> >
> >>> On Oct 17, 2018, at 5:21 PM, Adrian Croucher <
> a.crouc...@auckland.ac.nz> wrote:
> >>>
> >>> hi
> >>>
> >>> A colleague has just reported that my code no longer builds with
> PETSc 3.10.2, though it builds OK with 3.10.1.
> >>>
> >>> The problem appears to be the Fortran interface to
> SNESSetConvergenceTest(), which was changed at commit f9a1a4d.
> >>>
> >>> It now complains about the context argument we are passing in to
> this function ('cctx' in the interface, which is declared there as
> type(*)). The error is:
> >>>
> >>> "Error: Actual argument at (1) to assumed-type dummy is of
> derived type with type-bound or FINAL procedures"
> >>>
> >>> This is true, the argument being passed in is of derived type
> with type-bound procedures. Previously this didn't bother it, but it
> looks like it does now.
> >>>
> >>> Is its complaint legitimate? or perhaps a compiler bug? (this is
> using gcc 6.3.0)
> >>>
> >>> - Adrian
> >>>
> > --
> > Dr Adrian Croucher
> > Senior Research Fellow
> > Department of Engineering Science
> > University of Auckland, New Zealand
> > email: a.crouc...@auckland.ac.nz
> > tel: +64 (0)9 923 4611
> >
> >
>
--
---
Max-Planck-Institut für Eisenforschung GmbH
Max-Planck-Straße 1
D-40237 Düsseldorf
Handelsregister B 2533
Amtsgericht Düsseldorf
Geschäftsführung
Prof. Dr. Gerhard Dehm
Prof. Dr. Jörg Neugebauer
Prof. Dr. Dierk Raabe
Dr. Kai de Weldige
Ust.-Id.-Nr.: DE 11 93 58 514
Steuernummer: 105
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Adrian,
I goggled a bit but couldn't understand anything I found. My guess is that
type(*)
doesn't work for certain derived types (why not?) perhaps those that contain
procedures. If I remove the procedure from the
routine it all compiles, thus producing some evidence my theory is correct.
So we have a problem. The type checking one user wants is causing another
users code to not build.
Here is a short term fix you can do. After you run ./configure edit
$PETSC_ARCH/include/petscconf.h locate
#ifndef PETSC_HAVE_FORTRAN_TYPE_STAR
#define PETSC_HAVE_FORTRAN_TYPE_STAR 1
#endif
then run make. This will turn off the type checking for all routines that have
type(*) arguments which includes SNESSetConvergenceTest
I don't have a good long term solution at the moment. Maybe a Fortran expert
has some idea.
Barry
> On Oct 18, 2018, at 10:14 PM, Adrian Croucher
> wrote:
>
> hi Barry,
>
> On 18/10/18 11:34 AM, Smith, Barry F. wrote:
>>Sorry about this problem. I think the change was only introduced in
>> master and should not affect 3.10.x Please confirm that master is where the
>> failed compile is?
>
> Yes, it's on master. I have tracked down the commit at which it started to
> fail: 6f222c9d1e, "type checking for Fortran" (Fri Sep 28).
>
>>Please send us the calling sequence of your routine that won't compile
>> (cut and paste).
>
> I've attached a minimal example program which fails with the following error:
>
>call SNESSetConvergenceTest(snes, convergence, context, &
> 1
> Error: Actual argument at (1) to assumed-type dummy is of derived type with
> type-bound or FINAL procedures
>
> Cheers, Adrian
>
>>> On Oct 17, 2018, at 5:21 PM, Adrian Croucher
>>> wrote:
>>>
>>> hi
>>>
>>> A colleague has just reported that my code no longer builds with PETSc
>>> 3.10.2, though it builds OK with 3.10.1.
>>>
>>> The problem appears to be the Fortran interface to
>>> SNESSetConvergenceTest(), which was changed at commit f9a1a4d.
>>>
>>> It now complains about the context argument we are passing in to this
>>> function ('cctx' in the interface, which is declared there as type(*)). The
>>> error is:
>>>
>>> "Error: Actual argument at (1) to assumed-type dummy is of derived type
>>> with type-bound or FINAL procedures"
>>>
>>> This is true, the argument being passed in is of derived type with
>>> type-bound procedures. Previously this didn't bother it, but it looks like
>>> it does now.
>>>
>>> Is its complaint legitimate? or perhaps a compiler bug? (this is using gcc
>>> 6.3.0)
>>>
>>> - Adrian
>>>
> --
> Dr Adrian Croucher
> Senior Research Fellow
> Department of Engineering Science
> University of Auckland, New Zealand
> email: a.crouc...@auckland.ac.nz
> tel: +64 (0)9 923 4611
>
>
test_snes.F90
Description: test_snes.F90
Re: [petsc-dev] Fortran interface problem in v.3.10.2
hi Barry,
On 18/10/18 11:34 AM, Smith, Barry F. wrote:
Sorry about this problem. I think the change was only introduced in master
and should not affect 3.10.x Please confirm that master is where the failed
compile is?
Yes, it's on master. I have tracked down the commit at which it started
to fail: 6f222c9d1e, "type checking for Fortran" (Fri Sep 28).
Please send us the calling sequence of your routine that won't compile (cut
and paste).
I've attached a minimal example program which fails with the following
error:
call SNESSetConvergenceTest(snes, convergence, context, &
1
Error: Actual argument at (1) to assumed-type dummy is of derived type
with type-bound or FINAL procedures
Cheers, Adrian
On Oct 17, 2018, at 5:21 PM, Adrian Croucher wrote:
hi
A colleague has just reported that my code no longer builds with PETSc 3.10.2,
though it builds OK with 3.10.1.
The problem appears to be the Fortran interface to SNESSetConvergenceTest(),
which was changed at commit f9a1a4d.
It now complains about the context argument we are passing in to this function
('cctx' in the interface, which is declared there as type(*)). The error is:
"Error: Actual argument at (1) to assumed-type dummy is of derived type with
type-bound or FINAL procedures"
This is true, the argument being passed in is of derived type with type-bound
procedures. Previously this didn't bother it, but it looks like it does now.
Is its complaint legitimate? or perhaps a compiler bug? (this is using gcc
6.3.0)
- Adrian
--
Dr Adrian Croucher
Senior Research Fellow
Department of Engineering Science
University of Auckland, New Zealand
email: a.crouc...@auckland.ac.nz
tel: +64 (0)9 923 4611
module context_module
#include
use petsc
implicit none
private
type, public :: context_type
private
PetscInt :: foo
contains
procedure, public :: init => context_init
end type context_type
contains
subroutine context_init(self, foo)
class(context_type), intent(in out) :: self
PetscInt, intent(in) :: foo
self%foo = foo
end subroutine context_init
end module context_module
!
program test_snes
! tests SNESSetConvergenceTest()
#include
use petsc
use context_module
implicit none
SNES :: snes
type(context_type) :: context
PetscErrorCode :: ierr
call PetscInitialize(PETSC_NULL_CHARACTER, ierr)
call SNESCreate(PETSC_COMM_WORLD, snes, ierr)
call context%init(1)
call SNESSetConvergenceTest(snes, convergence, context, &
PETSC_NULL_FUNCTION, ierr)
call SNESDestroy(snes, ierr)
call PetscFinalize(ierr)
contains
subroutine convergence(snes, num_iterations, xnorm, pnorm, &
fnorm, reason, context, ierr)
SNES, intent(in) :: snes
PetscInt, intent(in) :: num_iterations
PetscReal, intent(in) :: xnorm, pnorm, fnorm
SNESConvergedReason, intent(out) :: reason
type(context_type), intent(in out) :: context
PetscErrorCode, intent(out) :: ierr
reason = 0
ierr = 0
end subroutine convergence
end program test_snes
Re: [petsc-dev] Fortran interface problem in v.3.10.2
Sorry about this problem. I think the change was only introduced in master
and should not affect 3.10.x Please confirm that master is where the failed
compile is?
Please send us the calling sequence of your routine that won't compile (cut
and paste).
Barry
> On Oct 17, 2018, at 5:21 PM, Adrian Croucher
> wrote:
>
> hi
>
> A colleague has just reported that my code no longer builds with PETSc
> 3.10.2, though it builds OK with 3.10.1.
>
> The problem appears to be the Fortran interface to SNESSetConvergenceTest(),
> which was changed at commit f9a1a4d.
>
> It now complains about the context argument we are passing in to this
> function ('cctx' in the interface, which is declared there as type(*)). The
> error is:
>
> "Error: Actual argument at (1) to assumed-type dummy is of derived type with
> type-bound or FINAL procedures"
>
> This is true, the argument being passed in is of derived type with type-bound
> procedures. Previously this didn't bother it, but it looks like it does now.
>
> Is its complaint legitimate? or perhaps a compiler bug? (this is using gcc
> 6.3.0)
>
> - Adrian
>
> --
> Dr Adrian Croucher
> Senior Research Fellow
> Department of Engineering Science
> University of Auckland, New Zealand
> email: a.crouc...@auckland.ac.nz
> tel: +64 (0)9 923 4611
>
