<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391</div></div>

</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2021, at 16:23, Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com" class="">jacob.fai@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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:<div class=""><br class=""></div><div class="">subroutine PetscMatlabEngineDestroy(a,z)                                                      <br class="">       PetscMatlabEngine a ! PetscMatlabEngine<br class="">        PetscErrorCode z<br class="">end subroutine PetscMatlabEngineDestroy</div><div class=""><br class=""></div><div class="">Is compiles completely fine but</div><div class=""><br class=""></div><div class="">subroutine PetscRandomDestroy(a,z)                                                            <br class="">       PetscRandom a ! PetscRandom<br class="">        PetscErrorCode z<br class="">end subroutine PetscRandomDestroy</div><div class=""><br class=""></div><div class="">Requires an “import tPetscRandom”. Previously both of these had “import petscsys” stuck in them.</div><div class=""><br class=""><div class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391</div></div>

</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2021, at 16:13, Satish Balay via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" class="">petsc-dev@mcs.anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">And with this change (alone) - the time to compile the f90 modules went (on pj01 testbox) from:<br class=""><br class="">0m48.676s<br class="">to<br class="">0m15.053s<br class=""><br class="">Satish<br class=""><br class="">On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote:<br class=""><br class=""><blockquote type="cite" class="">Ah - the issue is 'import IS' vs 'import tIS'<br class=""><br class="">Pushed a fix now. [and reverted my earlier source split change]. My build goes through fine now.<br class=""><br class="">Satish<br class=""><br class="">On Tue, 16 Mar 2021, Barry Smith wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">  Satish,<br class=""><br class="">    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?<br class=""><br class="">  Barry<br class=""><br class="">    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?<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 16, 2021, at 2:34 PM, Satish Balay via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" class="">petsc-dev@mcs.anl.gov</a>> wrote:<br class=""><br class="">On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">Tue, 16 Mar 2021, Jacob Faibussowitsch wrote:<br class=""><br class=""><blockquote type="cite" class="">Ok something I have gotten to work, but only doing things by hand in petscvecmod.F90:<br class=""><br class="">diff --git a/src/vec/f90-mod/petscvecmod.F90 b/src/vec/f90-mod/petscvecmod.F90<br class="">index 0c447156b9..ef3e2e2e55 100644<br class="">--- a/src/vec/f90-mod/petscvecmod.F90<br class="">+++ b/src/vec/f90-mod/petscvecmod.F90<br class="">module petscisdef<br class="">use petscisdefdummy<br class="">interface operator(.ne.)<br class="">function isnotequal(A,B)<br class="">-  use petscisdefdummy<br class="">+ import tIS<br class="">  logical isnotequal                                                                     <br class="">  type(tIS), intent(in) :: A,B<br class=""></blockquote><br class="">generatefortranstubs.py has some hakey parsing code. I guess it can be updated to do this.<br class=""><br class="">i.e - look for 'type(tIS)' and add 'import tIS'<br class=""></blockquote><br class="">I pushed changes to generatefortranstubs.py for this (to<br class="">balay/reorg-f90-for-xlf branch). But there are errors. (I don't completely understand this issue yet)<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote></blockquote>         FC arch-linux-c-debug/obj/sys/f90-mod/petscsysmod.o<br class="">/home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:6:19:<br class=""><br class="">   6 |        import PetscRandom<br class="">     |                   1<br class="">Error: Cannot IMPORT ‘type’ from host scoping unit at (1) - does not exist.<br class="">/home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:7:26:<br class=""><br class="">   7 |        PetscRandom a ! PetscRandom<br class="">     |                          1<br class="">Error: Derived type ‘tpetscrandom’ at (1) is being used before it is defined<br class=""><<<<<br class=""><br class=""><br class="">Satish<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">end function isnotequal<br class=""><br class="">This works for everything wrapped in a module which contains an interface block. For dangling functions the following works:<br class=""></blockquote><br class="">Hm - maybe these are only on the custom side [and not ftn-auto side]<br class=""><br class="">Satish<br class=""><blockquote type="cite" class=""><br class="">function isnotequal(A,B)<br class="">-  use petscisdefdummy<br class="">+ use petscisdef, only: tIs<br class=""></blockquote><br class=""><br class=""><blockquote type="cite" class="">  logical isnotequal<br class="">  type(tIS), intent(in) :: A,B<br class="">  isnotequal = (A%v .ne. B%v)<br class="">end function isnotequal<br class=""><br class="">Do our fortran stub generators have any notion of types? Specifically types that originate from petsc?<br class=""><br class="">Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391<br class=""><br class=""><blockquote type="cite" class="">On Mar 16, 2021, at 11:11, Satish Balay <<a href="mailto:balay@mcs.anl.gov" class="">balay@mcs.anl.gov</a>> wrote:<br class=""><br class="">On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">My [partial] change is in branch balay/reorg-f90-for-xlf<br class=""></blockquote><br class="">Satish is this branch pushed? I’d like to send it to the ibm folks to see if it works for them as well.<br class=""></blockquote><br class="">Sorry - pushed now. From what I remember - it didn't work.<br class=""><br class="">Satish<br class=""><br class=""><br class=""><blockquote type="cite" class="">They also added this extra follow up:<br class=""><br class="">The change we did in the source files is to replace all the "use pet*" statements in all the Interface blocks with IMPORT statement.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Best regards,<br class=""><br class="">Jacob Faibussowitsch<br class="">(Jacob Fai - booss - oh - vitch)<br class="">Cell: (312) 694-3391<br class=""><br class=""><blockquote type="cite" class="">On Mar 3, 2021, at 13:43, Satish Balay via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" class="">petsc-dev@mcs.anl.gov</a>> wrote:<br class=""><br class="">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..<br class=""><br class="">My [partial] change is in branch balay/reorg-f90-for-xlf<br class=""><br class="">Satish<br class=""><br class="">On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote:<br class=""><br class=""><blockquote type="cite" class="">On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote:<br class=""><br class=""><blockquote type="cite" class="">Sure - once any change works locally [for gcc and xlf]<br class=""><br class="">When I try - I get a bunch of errors.. [yet to digest them.]<br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Can you please give the following source code workaround a try?<br class="">Since there is already "use petscvecdefdummy" at the module scope, one workaround might be to remove the unnecessary "use petscvecdefdummy" in vecnotequal and vecequals <br class="">and all similar procedures.<br class=""><br class="">For example, the test case has:<br class="">    module petscvecdef<br class="">    use petscvecdefdummy<br class="">...<br class="">    function vecnotequal(A,B)<br class="">      use petscvecdefdummy<br class="">      logical vecnotequal<br class="">      type(tVec), intent(in) :: A,B<br class="">      vecnotequal = (A%v .ne. B%v)<br class="">    end function<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><br class=""><br class="">Ok - try this suggestion:<br class=""><br class="">diff --git a/src/vec/f90-mod/petscvecmod.F90 b/src/vec/f90-mod/petscvecmod.F90<br class="">index 0c447156b9..81968c7ca1 100644<br class="">--- a/src/vec/f90-mod/petscvecmod.F90<br class="">+++ b/src/vec/f90-mod/petscvecmod.F90<br class="">@@ -77,7 +77,6 @@<br class="">      use petscvecdefdummy<br class="">      interface operator(.ne.)<br class="">        function vecnotequal(A,B)<br class="">-            use petscvecdefdummy<br class="">          logical vecnotequal<br class="">          type(tVec), intent(in) :: A,B<br class="">        end function<br class=""><br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote>       FC arch-linux-c-debug/obj/vec/f90-mod/petscvecmod.o<br class="">/home/balay/petsc/src/vec/f90-mod/petscvecmod.F90:81:22:<br class=""><br class="">81 |             type(tVec), intent(in) :: A,B<br class="">   |                      1<br class="">Error: Derived type ‘tvec’ at (1) is being used before it is defined<br class="">/home/balay/petsc/include/../src/vec/f90-mod/ftn-auto-interfaces/petscis.h90:2:10:<br class=""><br class=""> 2 |       use petscvecdef<br class="">   |          1<br class="">Fatal Error: Cannot open module file ‘petscvecdef.mod’ for reading at (1): No such file or directory<br class=""><<<<<<<br class=""><br class="">Satish<br class=""></blockquote></blockquote><br class=""><br class=""></blockquote></blockquote><br class=""><br class=""></blockquote></blockquote></blockquote><br class=""></blockquote></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>