October 2018 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Testing for deprecated MKL functions?
by Matthew Knepley 23 Oct '18

23 Oct '18

On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <rtmills(a)anl.gov> wrote: > Barry, Satish, and others, > > In MKL 2018 update 2, the old, non-inspector executor sparse BLAS > interfaces were deprecated in favor of the newer, inspector-executor > versions. To keep lots of warnings from being generated, I put in some > preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y > way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is > defined, since mkl_sparse_sp2m() was introduced in this same update and I > needed a configure test for the presence of this function anyway. > > I now want to change the mkl_sparse_sp2m.py test to not define > PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I > determined that the way I am using mkl_sparse_sp2m() is unsafe prior to > this version. Since this will break my current logic for determining which > MKL routines are deprecated, this seems like a good time to handle the > deprecation in a better way. > > I did some cursory grepping through the BuildSystem packages files, and it > looks (?) like we don't have some examples to follow on how to handle > deprecated library functions. What I'd like to do is compile a test that > calls one of the deprecated functions and then checks for warning messages > from the compiler, but I don't know the variants of all of the warning > messages that compilers might emit, and I think some compilers won't give > any. If there isn't a good way to do such a test, I could > > * Rely on the version information in mkl_version.h, OR > * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This > was introduced when the old sparse BLAS interfaces were deprecated.) > I do not understand this one. You check for a #define, which happens to coincide with the change? > Is there a "best practice" for how we should handle such things in PETSc? > Relying on compiler warnings seems bad unless its something that compilers are guaranteed to emit. Matt > --Richard > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Testing for deprecated MKL functions?
by Mills, Richard Tran 23 Oct '18

23 Oct '18

Barry, Satish, and others, In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces were deprecated in favor of the newer, inspector-executor versions. To keep lots of warnings from being generated, I put in some preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since mkl_sparse_sp2m() was introduced in this same update and I needed a configure test for the presence of this function anyway. I now want to change the mkl_sparse_sp2m.py test to not define PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this version. Since this will break my current logic for determining which MKL routines are deprecated, this seems like a good time to handle the deprecation in a better way. I did some cursory grepping through the BuildSystem packages files, and it looks (?) like we don't have some examples to follow on how to handle deprecated library functions. What I'd like to do is compile a test that calls one of the deprecated functions and then checks for warning messages from the compiler, but I don't know the variants of all of the warning messages that compilers might emit, and I think some compilers won't give any. If there isn't a good way to do such a test, I could * Rely on the version information in mkl_version.h, OR * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.) Is there a "best practice" for how we should handle such things in PETSc? --Richard

1 0

Re: [petsc-dev] Fortran interface problem in v.3.10.2
by Martin Diehl 23 Oct '18

23 Oct '18

Hi, some more information on this topic. First, Adrians code is not wrong. The statement on the IBM homepage regarding type(*) and type-bound procedures is according to my current understanding simply not true. However, type(*) is a feature of Fortran 2018, a standard that is not even published. My information mainly comes from the Intel developer zone, see https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… and I have also informed the GCC/gfortran developers, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87707. I hope to get some more information in the next day and will keep you updated. best regards, Martin On Tue, 2018-10-23 at 17:25 +1300, Adrian Croucher wrote: > hi > > Thanks to you both for looking into this. > > It sounds like if we want type checking in the PETSc Fortran > interfaces, > which I agree is a useful thing, then no compilers are going to > support > passing in these derived types with type-bound procedures via > type(*) > interfaces anytime soon. > > In my case the derived-type objects I'm passing in to > SNESSetConvergenceTest() don't really need to have type-bound > procedures > (the derived type doesn't get subclassed, and there aren't really > any > data-hiding considerations), it's mostly just a style thing so that > they > work similarly to other derived types in the code. So I could fairly > easily just turn the type-bound procedures into ordinary > subroutines, > not bound to any derived type. > > That might be the simplest fix for me. I suppose this issue could > still > affect other people, but maybe not a lot of people are using PETSc > with > F2003. > > - Adrian > > On 23/10/18 2:55 AM, Martin Diehl wrote: > > > I'm sorry, I don't understand. Are you saying that the > > > example > > > code is not correct Fortran? > > > > In the case that your interface has a type(*) argument, it is not > > valid > > Fortran because 'context_type' contains the type-bound procedure > > 'context_init'. That is why the GNU compiler complains when the > > interface exists. Apparently, without the interface it accepts it, > > so > > not having an interface would be a solution in that case. However, > > the > > Intel compiler will fail during linking with or without interface, > > so > > it does not seem to be a general solution. > > At the moment, I believe that one simply has to live with the > > limitations that type(*) imposes on the data that can be passed to > > void*. To clarify this, I opened a thread in the Intel developer > > zone > > and will keep you updated > > > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… > > -- ----------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 ------------------------------------------------- Please consider that invitations and e-mails of our institute are only valid if they end with …(a)mpie.de. If you are not sure of the validity please contact rco(a)mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de ------------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …(a)mpie.de. If you are not sure of the validity please contact rco(a)mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de -------------------------------------------------

1 0

Re: [petsc-dev] Code of Conduct [ACTION REQUIRED]
by Patrick Sanan 23 Oct '18

23 Oct '18

In the first paragraph, with the list of characteristics that should not trigger harassment, suggest to add "native language" or similar, to underscore the point that, while the working language is English, the important things are the ideas, not the particulars of usage. Am Di., 23. Okt. 2018 um 12:52 Uhr schrieb Karl Rupp <rupp(a)iue.tuwien.ac.at >: > Dear PETSc folks, > > I ask all members of the PETSc team to review the following proposal for > adopting a code of conduct: > > > https://bitbucket.org/petsc/petsc/pull-requests/1196/code-of-conduct-adopt-… > > If you have questions, concerns, etc., please reply to this email thread. > > ACTION REQUIRED: If you agree with adopting the proposed Code of > Conduct, please click on "Approve" on the pull request webpage. This > signals that the whole team agrees to and respects the code of conduct. > > Thanks and best regards, > Karli >

1 0

Code of Conduct [ACTION REQUIRED]
by Karl Rupp 23 Oct '18

23 Oct '18

Dear PETSc folks, I ask all members of the PETSc team to review the following proposal for adopting a code of conduct: https://bitbucket.org/petsc/petsc/pull-requests/1196/code-of-conduct-adopt-… If you have questions, concerns, etc., please reply to this email thread. ACTION REQUIRED: If you agree with adopting the proposed Code of Conduct, please click on "Approve" on the pull request webpage. This signals that the whole team agrees to and respects the code of conduct. Thanks and best regards, Karli

1 0

Re: [petsc-dev] Fortran interface problem in v.3.10.2
by Adrian Croucher 22 Oct '18

22 Oct '18

hi Thanks to you both for looking into this. It sounds like if we want type checking in the PETSc Fortran interfaces, which I agree is a useful thing, then no compilers are going to support passing in these derived types with type-bound procedures via type(*) interfaces anytime soon. In my case the derived-type objects I'm passing in to SNESSetConvergenceTest() don't really need to have type-bound procedures (the derived type doesn't get subclassed, and there aren't really any data-hiding considerations), it's mostly just a style thing so that they work similarly to other derived types in the code. So I could fairly easily just turn the type-bound procedures into ordinary subroutines, not bound to any derived type. That might be the simplest fix for me. I suppose this issue could still affect other people, but maybe not a lot of people are using PETSc with F2003. - Adrian On 23/10/18 2:55 AM, Martin Diehl wrote: >> I'm sorry, I don't understand. Are you saying that the example >> code is not correct Fortran? > In the case that your interface has a type(*) argument, it is not valid > Fortran because 'context_type' contains the type-bound procedure > 'context_init'. That is why the GNU compiler complains when the > interface exists. Apparently, without the interface it accepts it, so > not having an interface would be a solution in that case. However, the > Intel compiler will fail during linking with or without interface, so > it does not seem to be a general solution. > At the moment, I believe that one simply has to live with the > limitations that type(*) imposes on the data that can be passed to > void*. To clarify this, I opened a thread in the Intel developer zone > and will keep you updated > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… > -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.croucher(a)auckland.ac.nz tel: +64 (0)9 923 4611

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Smith, Barry F. 22 Oct '18

22 Oct '18

> On Oct 22, 2018, at 12:17 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > >> Jed, >> >> Why are the modules always built last? >> >> ..... >> FC arch-basic/obj/sys/objects/f2003-src/fsrc/optionenum.o >> FC arch-basic/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o >> FC arch-basic/obj/mat/f90-mod/petscmatmod.o >> FC arch-basic/obj/dm/f90-mod/petscdmmod.o >> FC arch-basic/obj/dm/f90-mod/petscdmplexmod.o >> FC arch-basic/obj/ksp/f90-mod/petsckspmod.o >> FC arch-basic/obj/snes/f90-mod/petscsnesmod.o >> FC arch-basic/obj/ts/f90-mod/petsctsmod.o >> FC arch-basic/obj/tao/f90-mod/petsctaomod.o >> >> I don't think they have any dependency on the compiled C code so couldn't each module (still build sequentially within the list of modules) run in parallel with a bunch of C compilers? Why are they always scheduled last, forcing sequential? > > The Fortran modules depend on each other so build sequentially. Look > way up in your compilation history and you'll see lines for > petscsysmod.o and later petscvecmod.o. Compiling those modules is just > that slow compared to the hundreds of C compilations that run in > parallel. Ok.

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Balay, Satish 22 Oct '18

22 Oct '18

I'm not sure if one can give priority to mod compilation in gmake - but I think the first module is scheduled quickly - but then that takes some time to compile. CC arch-linux2-c-debug/obj/sys/objects/gcomm.o Use "/usr/bin/gmake V=1" to see verbose compile lines, "/usr/bin/gmake V=0" to suppress. FC arch-linux2-c-debug/obj/sys/f90-mod/petscsysmod.o But due to dependencies - I think the second one gets placed further back in the queue CC arch-linux2-c-debug/obj/vec/is/sf/interface/dlregissf.o FC arch-linux2-c-debug/obj/vec/f90-mod/petscvecmod.o etc.. And by the time all sources without dependencies get compiled [i.e all c code] - the module sources are left at the end of the build. Satish On Mon, 22 Oct 2018, Smith, Barry F. wrote: > > Jed, > > Why are the modules always built last? > > ..... > FC arch-basic/obj/sys/objects/f2003-src/fsrc/optionenum.o > FC arch-basic/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o > FC arch-basic/obj/mat/f90-mod/petscmatmod.o > FC arch-basic/obj/dm/f90-mod/petscdmmod.o > FC arch-basic/obj/dm/f90-mod/petscdmplexmod.o > FC arch-basic/obj/ksp/f90-mod/petsckspmod.o > FC arch-basic/obj/snes/f90-mod/petscsnesmod.o > FC arch-basic/obj/ts/f90-mod/petsctsmod.o > FC arch-basic/obj/tao/f90-mod/petsctaomod.o > > I don't think they have any dependency on the compiled C code so couldn't each module (still build sequentially within the list of modules) run in parallel with a bunch of C compilers? Why are they always scheduled last, forcing sequential? > > Barry > > > > On Oct 22, 2018, at 11:00 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > > > "Balay, Satish" <balay(a)mcs.anl.gov> writes: > > > >> Currently fortran modules are built sequentially [due to dependencies] > >> > >> Perhaps there is a way to split them up - and introduce some parallelism.. > > > > I think we would have to follow a pattern similar to the petsc*types.h > > headers where we would have a module that only defines types (needed by > > higher level PETSc packages) and a separate module that uses the types > > module and provides all the interfaces. There would still be > > dependencies between the types modules, but not between the interfaces > > (because the Fortran interface modules don't call other interfaces). > > > > For incremental builds when using ccache, rebuilding the modules can > > easily dominate execution time. >

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Jed Brown 22 Oct '18

22 Oct '18

"Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > Jed, > > Why are the modules always built last? > > ..... > FC arch-basic/obj/sys/objects/f2003-src/fsrc/optionenum.o > FC arch-basic/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o > FC arch-basic/obj/mat/f90-mod/petscmatmod.o > FC arch-basic/obj/dm/f90-mod/petscdmmod.o > FC arch-basic/obj/dm/f90-mod/petscdmplexmod.o > FC arch-basic/obj/ksp/f90-mod/petsckspmod.o > FC arch-basic/obj/snes/f90-mod/petscsnesmod.o > FC arch-basic/obj/ts/f90-mod/petsctsmod.o > FC arch-basic/obj/tao/f90-mod/petsctaomod.o > > I don't think they have any dependency on the compiled C code so couldn't each module (still build sequentially within the list of modules) run in parallel with a bunch of C compilers? Why are they always scheduled last, forcing sequential? The Fortran modules depend on each other so build sequentially. Look way up in your compilation history and you'll see lines for petscsysmod.o and later petscvecmod.o. Compiling those modules is just that slow compared to the hundreds of C compilations that run in parallel.

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Smith, Barry F. 22 Oct '18

22 Oct '18

Jed, Why are the modules always built last? ..... FC arch-basic/obj/sys/objects/f2003-src/fsrc/optionenum.o FC arch-basic/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o FC arch-basic/obj/mat/f90-mod/petscmatmod.o FC arch-basic/obj/dm/f90-mod/petscdmmod.o FC arch-basic/obj/dm/f90-mod/petscdmplexmod.o FC arch-basic/obj/ksp/f90-mod/petsckspmod.o FC arch-basic/obj/snes/f90-mod/petscsnesmod.o FC arch-basic/obj/ts/f90-mod/petsctsmod.o FC arch-basic/obj/tao/f90-mod/petsctaomod.o I don't think they have any dependency on the compiled C code so couldn't each module (still build sequentially within the list of modules) run in parallel with a bunch of C compilers? Why are they always scheduled last, forcing sequential? Barry > On Oct 22, 2018, at 11:00 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > "Balay, Satish" <balay(a)mcs.anl.gov> writes: > >> Currently fortran modules are built sequentially [due to dependencies] >> >> Perhaps there is a way to split them up - and introduce some parallelism.. > > I think we would have to follow a pattern similar to the petsc*types.h > headers where we would have a module that only defines types (needed by > higher level PETSc packages) and a separate module that uses the types > module and provides all the interfaces. There would still be > dependencies between the types modules, but not between the interfaces > (because the Fortran interface modules don't call other interfaces). > > For incremental builds when using ccache, rebuilding the modules can > easily dominate execution time.

1 0