> Do both the manually generated petsc*mod.F90 and the automatically generated > files need to be switched to not use use everywhere? It seems both might need to be changed. I changed petscvecmod, petscsysmod and petscmatmod, and whilst petscvecmod now compiled petscmatmod still crashed.
Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 16, 2021, at 14:41, Barry Smith <bsm...@petsc.dev> 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> 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> 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> 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 >>>>>> >>>>>> >>>> >>>> >
