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]>
> 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]> 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]> 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]> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
