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
