So it actually does not load everything at the call to use but waits until the subroutine definitions and then only loads what you ask to import?
Sorry, this is odd, with C include or python import it immediately loads up everything as soon as it sees the include or import, there is no way later to say "wo hoarsy I didn't really mean you should get everything I asked, for please only load up a subset". But then Fortran was always weird, when I saw presentations of the Fortran standards committee members I always felt like they read every third page of some computer science book but never realized they missed many of the pages. But, ok, if it works, it works. Barry > On Mar 16, 2021, at 6:54 PM, Jacob Faibussowitsch <[email protected]> wrote: > >> I am puzzled by the import tXXX, how it can work? How does it know what >> module file to look in for the import? With use xxx the xxx gets translated >> directly to a file name. But with import tXXX that is impossible. > > Its similar to nested namespace semantics, you “use" the super-namespace at > the module level then import the objects at interface of that module. i.e.: > > Module foo > Use bar <—— module contains bop > Interface > Subroutine baz(x) > Import bop <—— hoists bop out of bar defined in super-scope > Bop x > End subroutine > End interface > End module > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >> On Mar 16, 2021, at 18:25, Barry Smith <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> >>> On Mar 16, 2021, at 5:03 PM, Satish Balay <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Tue, 16 Mar 2021, Barry Smith wrote: >>> >>>> >>>> Jacob, >>>> >>>> You very well may be right, splitting may not be needed or relevant. I >>>> only advocated it since for Mat it did fix a VM gfortran memory issue. How >>>> closely the IBM compiler and gfortran issues are I do not know. >>>> >>>> My MR Mat split is read to to go into main. >>>> >>>> https://gitlab.com/petsc/petsc/-/merge_requests/3715 >>>> <https://gitlab.com/petsc/petsc/-/merge_requests/3715> >>>> <https://gitlab.com/petsc/petsc/-/merge_requests/3715 >>>> <https://gitlab.com/petsc/petsc/-/merge_requests/3715>> The MPI one is >>>> still needing some babysitting, hopefully it can pass the CI and get into >>>> main soon. >>>> >>>> Both should be in main before starting to muck with changing the use stuff >>>> for the IBM compiler. >>>> >>>> Satish, does your Vec file split pass the CI? If so I think we should also >>>> get it into main before messing with the use for the IBM compiler. >>> >>> Barry - if the switch from 'use' to 'import' is sufficient [for VM builds] >>> - should we still split the sources? Right now it changes only the >>> auto-fortran stubs, fixing custom stubs should give further improvements. >> >> If the import solves the VM gfortran problem then I see no reason to split >> the source (it is a little easier to maintain as one file). >> >> So maybe, for now use the import and later if the VM gfortran problem >> continues we split the source. >> >> Barry >> >> I am puzzled by the import tXXX, how it can work? How does it know what >> module file to look in for the import? With use xxx the xxx gets translated >> directly to a file name. But with import tXXX that is impossible. >> >> >> >>> >>> If spliting sources is useful - I'll look into pushing the Vec split into >>> this MR. >>> >>> BTW: Matt - can you test balay/reorg-f90-for-xlf branch against 'gfortran >>> VM'? >>> >>> Satish >>> >>>> >>>> >>>> Who has access to the wonky IBM compiler? Is there any way to have >>>> general access so it can be added to the CI and we can maintain code that >>>> works with it? Or does someone need to fix things one at a time, first >>>> Vec, then Mat, then .... >>>> >>>> >>>> Barry >>>> >>>> >>>>> On Mar 16, 2021, at 2:14 PM, Satish Balay via petsc-dev >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> On Tue, 16 Mar 2021, Matthew Knepley wrote: >>>>> >>>>>> On Tue, Mar 16, 2021 at 2:42 PM Jacob Faibussowitsch >>>>>> <[email protected] <mailto:[email protected]>> >>>>>> wrote: >>>>>> >>>>>>> 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). >>>>>>> >>>>>> >>>>>> If you can get this to work, we should definitely do it. Was there a >>>>>> question about getting it to work? >>>>> >>>>> Likely these additional changes should be done starting with Barry's >>>>> split-up of sources. >>>>> >>>>> Satish >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Jacob Faibussowitsch >>>>>>> (Jacob Fai - booss - oh - vitch) >>>>>>> Cell: (312) 694-3391 >>>>>>> >>>>>>> On Mar 16, 2021, at 12:56, Barry Smith <[email protected] >>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> 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 <[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]>> 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 >
