hm - generatefortranstubs is not useful for the custom stubs. >From them - I would: - in the first pass - remove all 'use' statements - iterate: * run a build * add 'import' for types that give build errors
But I think its best to do this after the 2 MRs that change fortran interfaces are (reviewed/)merged in. Sure - its would be better to automate the search for t<Type> declarations in PETSc. bfort reads in lib/petsc/conf/bfort-petsc.txt - so perhaps generatefortranstubs can also use this data.. Satish On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: > 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 <[email protected]> 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 > >> <[email protected] <mailto:[email protected]>> 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 > >>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] > >>>>>>>> <mailto:[email protected]>> 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 > >>>>>>>>>> <[email protected] <mailto:[email protected]>> 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>> > > > >
