Great! I created MR with the current changes https://gitlab.com/petsc/petsc/-/merge_requests/3723
Satish On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: > Satish your branch built successfully. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > > On Mar 16, 2021, at 16:37, Satish Balay <[email protected]> wrote: > > > > 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]> > >>>> <mailto:[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]> > >>>>>>> <mailto:[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]> <mailto:[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]> > >>>>>>>>>>>> <mailto:[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 > >
