Alternatively generatefortranstubs can traipse through src/<mansec>/f90-mod/petsc<mansec>.h90 and look for type t<petscClass> definitions and build a list of petsc types that way, but at that point we’re halfway to writing our own compiler.
Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 16, 2021, at 16:23, Jacob Faibussowitsch <jacob....@gmail.com> wrote: > > So I have hit a bit of a wall. I am able to pull out all of the types for a > subroutine declaration but I cannot determine which types are classes since > those are the ones that need to be imported. For example: > > subroutine PetscMatlabEngineDestroy(a,z) > > PetscMatlabEngine a ! PetscMatlabEngine > PetscErrorCode z > end subroutine PetscMatlabEngineDestroy > > Is compiles completely fine but > > subroutine PetscRandomDestroy(a,z) > > PetscRandom a ! PetscRandom > PetscErrorCode z > end subroutine PetscRandomDestroy > > Requires an “import tPetscRandom”. Previously both of these had “import > petscsys” stuck in them. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >> On Mar 16, 2021, at 16:13, Satish Balay via petsc-dev <petsc-dev@mcs.anl.gov >> <mailto:petsc-dev@mcs.anl.gov>> wrote: >> >> And with this change (alone) - the time to compile the f90 modules went (on >> pj01 testbox) from: >> >> 0m48.676s >> to >> 0m15.053s >> >> Satish >> >> On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote: >> >>> Ah - the issue is 'import IS' vs 'import tIS' >>> >>> Pushed a fix now. [and reverted my earlier source split change]. My build >>> goes through fine now. >>> >>> Satish >>> >>> On Tue, 16 Mar 2021, Barry Smith wrote: >>> >>>> >>>> Satish, >>>> >>>> The import tIS might only work because the IS is already defined in >>>> the same file so the compiler can pull in just part of the use >>>> petscisdefdummy ? If the original module that contains the PetscRandom is >>>> in a different file then I don't see how the compiler can find and import >>>> PetscRandom. Is there a version of import where you also list the module >>>> (file) that the beast is from so the compiler can get it from that module? >>>> >>>> Barry >>>> >>>> Do both the manually generated petsc*mod.F90 and the automatically >>>> generated files need to be switched to not use use everywhere? Or is it >>>> enough just to fix the manual ones for now and not mess with sowing? >>>> >>>> >>>> >>>>> On Mar 16, 2021, at 2:34 PM, Satish Balay via petsc-dev >>>>> <petsc-dev@mcs.anl.gov <mailto:petsc-dev@mcs.anl.gov>> wrote: >>>>> >>>>> On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote: >>>>> >>>>>> >>>>>> >>>>>> Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: >>>>>> >>>>>>> Ok something I have gotten to work, but only doing things by hand in >>>>>>> petscvecmod.F90: >>>>>>> >>>>>>> diff --git a/src/vec/f90-mod/petscvecmod.F90 >>>>>>> b/src/vec/f90-mod/petscvecmod.F90 >>>>>>> index 0c447156b9..ef3e2e2e55 100644 >>>>>>> --- a/src/vec/f90-mod/petscvecmod.F90 >>>>>>> +++ b/src/vec/f90-mod/petscvecmod.F90 >>>>>>> module petscisdef >>>>>>> use petscisdefdummy >>>>>>> interface operator(.ne.) >>>>>>> function isnotequal(A,B) >>>>>>> - use petscisdefdummy >>>>>>> + import tIS >>>>>>> logical isnotequal >>>>>>> >>>>>>> type(tIS), intent(in) :: A,B >>>>>> >>>>>> generatefortranstubs.py has some hakey parsing code. I guess it can be >>>>>> updated to do this. >>>>>> >>>>>> i.e - look for 'type(tIS)' and add 'import tIS' >>>>> >>>>> I pushed changes to generatefortranstubs.py for this (to >>>>> balay/reorg-f90-for-xlf branch). But there are errors. (I don't >>>>> completely understand this issue yet) >>>>> >>>>>>>> >>>>> FC arch-linux-c-debug/obj/sys/f90-mod/petscsysmod.o >>>>> /home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:6:19: >>>>> >>>>> 6 | import PetscRandom >>>>> | 1 >>>>> Error: Cannot IMPORT ‘type’ from host scoping unit at (1) - does not >>>>> exist. >>>>> /home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:7:26: >>>>> >>>>> 7 | PetscRandom a ! PetscRandom >>>>> | 1 >>>>> Error: Derived type ‘tpetscrandom’ at (1) is being used before it is >>>>> defined >>>>> <<<< >>>>> >>>>> >>>>> Satish >>>>> >>>>>> >>>>>>> end function isnotequal >>>>>>> >>>>>>> This works for everything wrapped in a module which contains an >>>>>>> interface block. For dangling functions the following works: >>>>>> >>>>>> Hm - maybe these are only on the custom side [and not ftn-auto side] >>>>>> >>>>>> Satish >>>>>>> >>>>>>> function isnotequal(A,B) >>>>>>> - use petscisdefdummy >>>>>>> + use petscisdef, only: tIs >>>>>> >>>>>> >>>>>>> logical isnotequal >>>>>>> type(tIS), intent(in) :: A,B >>>>>>> isnotequal = (A%v .ne. B%v) >>>>>>> end function isnotequal >>>>>>> >>>>>>> Do our fortran stub generators have any notion of types? Specifically >>>>>>> types that originate from petsc? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Jacob Faibussowitsch >>>>>>> (Jacob Fai - booss - oh - vitch) >>>>>>> Cell: (312) 694-3391 >>>>>>> >>>>>>>> On Mar 16, 2021, at 11:11, Satish Balay <ba...@mcs.anl.gov >>>>>>>> <mailto:ba...@mcs.anl.gov>> wrote: >>>>>>>> >>>>>>>> On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: >>>>>>>> >>>>>>>>>> My [partial] change is in branch balay/reorg-f90-for-xlf >>>>>>>>> >>>>>>>>> Satish is this branch pushed? I’d like to send it to the ibm folks to >>>>>>>>> see if it works for them as well. >>>>>>>> >>>>>>>> Sorry - pushed now. From what I remember - it didn't work. >>>>>>>> >>>>>>>> Satish >>>>>>>> >>>>>>>> >>>>>>>>> They also added this extra follow up: >>>>>>>>> >>>>>>>>> The change we did in the source files is to replace all the "use >>>>>>>>> pet*" statements in all the Interface blocks with IMPORT statement. >>>>>>>>> >>>>>>>>> The nature of this workaround is to reduce the number of symbols that >>>>>>>>> the compiler have to create, which exceeded the limitation and caused >>>>>>>>> ICE. >>>>>>>>> >>>>>>>>> Every USE statement in an interface block opens up the module symbol >>>>>>>>> file and reads all the symbols from it and creates an entity for each >>>>>>>>> symbol in compiler. This is unnecessary when the module already has >>>>>>>>> the same USE statement in the module scope. Instead, users can use >>>>>>>>> IMPORT statement to make the module symbols accessible inside >>>>>>>>> interface face blocks. >>>>>>>>> >>>>>>>>> With the change, the compiler would only read the module symbol file >>>>>>>>> once and create one set of symbols where the old code reads the >>>>>>>>> module symbol files as many times as the number of the USE statements >>>>>>>>> in Interface blocks and create that many sets of duplicate symbols. >>>>>>>>> Replacing those USE statements with IMPORT statements also shortens >>>>>>>>> the compile time significantly. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Jacob Faibussowitsch >>>>>>>>> (Jacob Fai - booss - oh - vitch) >>>>>>>>> Cell: (312) 694-3391 >>>>>>>>> >>>>>>>>>> On Mar 3, 2021, at 13:43, Satish Balay via petsc-dev >>>>>>>>>> <petsc-dev@mcs.anl.gov <mailto:petsc-dev@mcs.anl.gov>> wrote: >>>>>>>>>> >>>>>>>>>> The only change I can get working (i.e avoid compile errors) is to >>>>>>>>>> split petscvecmod.F90 into 2 source files - but I don't know if this >>>>>>>>>> will help with xlf.. >>>>>>>>>> >>>>>>>>>> My [partial] change is in branch balay/reorg-f90-for-xlf >>>>>>>>>> >>>>>>>>>> Satish >>>>>>>>>> >>>>>>>>>> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: >>>>>>>>>>> >>>>>>>>>>>> Sure - once any change works locally [for gcc and xlf] >>>>>>>>>>>> >>>>>>>>>>>> When I try - I get a bunch of errors.. [yet to digest them.] >>>>>>>>>>> >>>>>>>>>>>>>>>> Can you please give the following source code workaround a try? >>>>>>>>>>>>>>>> Since there is already "use petscvecdefdummy" at the module >>>>>>>>>>>>>>>> scope, one workaround might be to remove the unnecessary "use >>>>>>>>>>>>>>>> petscvecdefdummy" in vecnotequal and vecequals >>>>>>>>>>>>>>>> and all similar procedures. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, the test case has: >>>>>>>>>>>>>>>> module petscvecdef >>>>>>>>>>>>>>>> use petscvecdefdummy >>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>> function vecnotequal(A,B) >>>>>>>>>>>>>>>> use petscvecdefdummy >>>>>>>>>>>>>>>> logical vecnotequal >>>>>>>>>>>>>>>> type(tVec), intent(in) :: A,B >>>>>>>>>>>>>>>> vecnotequal = (A%v .ne. B%v) >>>>>>>>>>>>>>>> end function >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok - try this suggestion: >>>>>>>>>>> >>>>>>>>>>> diff --git a/src/vec/f90-mod/petscvecmod.F90 >>>>>>>>>>> b/src/vec/f90-mod/petscvecmod.F90 >>>>>>>>>>> index 0c447156b9..81968c7ca1 100644 >>>>>>>>>>> --- a/src/vec/f90-mod/petscvecmod.F90 >>>>>>>>>>> +++ b/src/vec/f90-mod/petscvecmod.F90 >>>>>>>>>>> @@ -77,7 +77,6 @@ >>>>>>>>>>> use petscvecdefdummy >>>>>>>>>>> interface operator(.ne.) >>>>>>>>>>> function vecnotequal(A,B) >>>>>>>>>>> - use petscvecdefdummy >>>>>>>>>>> logical vecnotequal >>>>>>>>>>> type(tVec), intent(in) :: A,B >>>>>>>>>>> end function >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> FC arch-linux-c-debug/obj/vec/f90-mod/petscvecmod.o >>>>>>>>>>> /home/balay/petsc/src/vec/f90-mod/petscvecmod.F90:81:22: >>>>>>>>>>> >>>>>>>>>>> 81 | type(tVec), intent(in) :: A,B >>>>>>>>>>> | 1 >>>>>>>>>>> Error: Derived type ‘tvec’ at (1) is being used before it is defined >>>>>>>>>>> /home/balay/petsc/include/../src/vec/f90-mod/ftn-auto-interfaces/petscis.h90:2:10: >>>>>>>>>>> >>>>>>>>>>> 2 | use petscvecdef >>>>>>>>>>> | 1 >>>>>>>>>>> Fatal Error: Cannot open module file ‘petscvecdef.mod’ for reading >>>>>>>>>>> at (1): No such file or directory >>>>>>>>>>> <<<<<< >>>>>>>>>>> >>>>>>>>>>> Satish >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>> >
