> To me the best solution is to first split the files when possible (it is > often not or just too painful) and then adding imports if needed.
I’m not sure I agree. Bear in mind my familiarity with fortran is very limited, but to me the “use” statement is similar to #include <header> in C or using namespace xxx in cpp. Our fortran interface is not optimal code atm, it’s as if we put a "#include <petscvec.h>” before every Vec function in the C source (assuming include guards are not used). Sure you can fix this by splitting the vec src files in two, but at the end of the day that’s a bandaid solution. I think I can get the import stuff to work reasonably well (a lot of the infrastructure to capture types is already present in the current generatefortranstubs). Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 16, 2021, at 12:56, Barry Smith <bsm...@petsc.dev> wrote: > > > Jacob, > > I split the mat definitions in the MR > https://gitlab.com/petsc/petsc/-/merge_requests/3696 > <https://gitlab.com/petsc/petsc/-/merge_requests/3696> and this reduced > memory requirements enough to get builds through on some VM that failed > previously ran out of memory (with gfortran). > > The petsc*mod.F90 files are all handwritten so it is ok to manually > change them with imports if that helps the IBM compiler. To me the best > solution is to first split the files when possible (it is often not or just > too painful) and then adding imports if needed. > > Note also the MR > https://gitlab.com/petsc/petsc/-/merge_requests/3715/diffs > <https://gitlab.com/petsc/petsc/-/merge_requests/3715/diffs> which may help a > great deal with the IBM compiler or not. > > Thanks > > Barry > > > >> On Mar 16, 2021, at 11:47 AM, Jacob Faibussowitsch <jacob....@gmail.com >> <mailto:jacob....@gmail.com>> 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 >> end function isnotequal >> >> This works for everything wrapped in a module which contains an interface >> block. For dangling functions the following works: >> >> 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 >>> <mailto: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 <mailto: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 >>>> >>>> >> >
