July 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Pflotran perf on GPU
by 周文浩 15 Jul '12

15 Jul '12

Hello！ I get the information that you run pflotran on GPU and test it, these days I’m trying to find the GPU version of pflotran, could you send me a copy of your GPU version? I need it very much. Thanks!

1 0

Re: [petsc-dev] threadcomm memory leak
by Satish Balay 14 Jul '12

14 Jul '12

I see this with 32bit linux build - but not 64bit linux build. also 32bit linux build gives errors with -fp_trap in ddot(). Haven't checked why.. Satish On Sat, 14 Jul 2012, Barry Smith wrote: > > Many of them with make test > > Running test examples to verify correct installation > Using PETSC_DIR=/Users/barrysmith/Src/petsc-dev and PETSC_ARCH=arch-float128-opt > Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process > See http://www.mcs.anl.gov/petsc/documentation/faq.html > lid velocity = Qg, prandtl # = Qg, grashof # = Qg > Number of SNES iterations = 2 > [0]Total space allocated 6880 bytes > [ 0]16 bytes PetscThreadCommReductionCreate() line 260 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c > [ 0]16 bytes PetscThreadCommReductionCreate() line 259 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c > [ 0]48 bytes PetscThreadCommReductionCreate() line 258 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]272 bytes PetscThreadCommInitialize() line 692 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]16 bytes PetscThreadCommSetAffinities() line 331 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > Completed test examples > barry-smiths-macbook-pro:petsc-dev barrysmith$ > > > On Jul 14, 2012, at 6:36 PM, Shri wrote: > > > Which example are you running? I don't see any memory leak for the examples i've tested (threadcomm examples sys/threadcomm/examples/tutorials/ and snes/examples/tutorials/ex19.c,ex5.c) > > On Jul 14, 2012, at 4:22 PM, Barry Smith wrote: > > > >> > >> Please always test for memory leaks before pushing > >> > >> [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > >> [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > >> [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c > >> [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > >> [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > >> [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c > >> > >> > >> > > > >

1 0

Re: [petsc-dev] threadcomm memory leak
by Barry Smith 14 Jul '12

14 Jul '12

Many of them with make test Running test examples to verify correct installation Using PETSC_DIR=/Users/barrysmith/Src/petsc-dev and PETSC_ARCH=arch-float128-opt Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html lid velocity = Qg, prandtl # = Qg, grashof # = Qg Number of SNES iterations = 2 [0]Total space allocated 6880 bytes [ 0]16 bytes PetscThreadCommReductionCreate() line 260 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c [ 0]16 bytes PetscThreadCommReductionCreate() line 259 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c [ 0]48 bytes PetscThreadCommReductionCreate() line 258 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcommred.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommInitialize() line 698 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]176 bytes PetscThreadCommInitialize() line 694 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]272 bytes PetscThreadCommInitialize() line 692 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]16 bytes PetscThreadCommSetAffinities() line 331 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c Completed test examples barry-smiths-macbook-pro:petsc-dev barrysmith$ On Jul 14, 2012, at 6:36 PM, Shri wrote: > Which example are you running? I don't see any memory leak for the examples i've tested (threadcomm examples sys/threadcomm/examples/tutorials/ and snes/examples/tutorials/ex19.c,ex5.c) > On Jul 14, 2012, at 4:22 PM, Barry Smith wrote: > >> >> Please always test for memory leaks before pushing >> >> [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c >> [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c >> [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c >> [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c >> [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c >> [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c >> >> >> >

1 0

Re: [petsc-dev] threadcomm memory leak
by Shri 14 Jul '12

14 Jul '12

Which example are you running? I don't see any memory leak for the examples i've tested (threadcomm examples sys/threadcomm/examples/tutorials/ and snes/examples/tutorials/ex19.c,ex5.c) On Jul 14, 2012, at 4:22 PM, Barry Smith wrote: > > Please always test for memory leaks before pushing > > [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c > [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c > > >

1 0

threadcomm memory leak
by Barry Smith 14 Jul '12

14 Jul '12

Please always test for memory leaks before pushing [ 0]48 bytes PetscThreadCommCreate() line 122 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c [ 0]320 bytes PetscThreadCommCreate() line 118 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [0] PetscThreadCommInitialize() line 685 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/threadcomm.c [0] PetscThreadCommInitializePackage() line 53 in /Users/barrysmith/Src/petsc-dev/src/sys/threadcomm/interface/dlregisthreadcomm.c

1 0

Re: [petsc-dev] Multiprecision solver composition
by Matthew Knepley 14 Jul '12

14 Jul '12

On Sat, Jul 14, 2012 at 2:57 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > It's already there! :-) From petscsys.h > > /*EC > > PetscPrecision - indicates what precision the object is using. This is > currently not used. > > Level: advanced > > .seealso: PetscObjectSetPrecision() > E*/ > typedef enum { PETSC_PRECISION_SINGLE=4,PETSC_PRECISION_DOUBLE=8 } > PetscPrecision; > PETSC_EXTERN const char *PetscPrecisions[]; > > > Matt, > > The biggest stumbling block I've had with doing this in C is not the > part you talk about below but the access like VecSetValues(), VecAXPY() > etc (and all the Mat ones) that > take a scale argument or worse array of scales. How to manage that? You > can pass any precision into any object, or only the precision of the > object? Always double precision for these arguments? but that is too > limiting .... It is hard for me to see how to prevent an explosion of > "templated" interfaces of some kind or another. > I am fine with all the regular functions to take PetscScalar. That keeps the interface simple, and I don't think you can make a single argument against casting around single scalars or small arrays like VecMDot(). > VecGetArray() requesting the precision type may be useful as a starting > point. I think the only ones we need to be careful with are the direct value access, MatSetValues(), VecGetArray(), etc. For this, I recommend what I said, have another function which takes an explicit precision, and have the normal method do automatic conversion. If there are no objections more damaging than that, I think we might as well try it. Matt > > Barry > > > On Jul 14, 2012, at 10:09 AM, Matthew Knepley wrote: > > > I saw a good talk by Chris Baker at SIAM about multiprecision solvers, > and was suitably embarrassed that we cannot do > > this. I still strongly believe that templates are the wrong solution, > and mucking up perfectly good interfaces with a > > bunch of types we do not care about is wrong. I now have a proposal, > outlined below. > > > > We start with the idea of a solver with a certain precision, so that > each solver can report the precision it computes > > in. Let's restrict ourselves to solvers that only do simple vector > operations for the time being. For this then, we > > need a Vec object which stores values and computes with this precision, > which will be discussed below. Upon entering, > > we call VecConvert() on the input vector to get the correct precision, > which just references the object if no conversion > > is necessary. We VecConvert() the output vector as well before filling > it, and the VecConvert() to the output on the way > > out. If not conversion is necessary, we get the ssme pointer for the > first convert, and no-op for the second. All > > internal vectors are created with the solver precision. This all depends > on having Vec objects of different precisions. > > > > I propose we have a different Vec implementation for each precision, > maybe saving code by having configure or make > > generate the different precisions from a single template. Most Vec > operations work by first calling VecGetArray() and > > then some BLAS calls. I would now have VecGetArray() do copy-in/copy-out > if internal storage has a different precision > > than PetscScalar, and add the function VecGetArrayPrecise(Vec v, > PetscDataType precision, void **array) which returns > > the internal storage if it is the correct precision, and fails > otherwise. If we switch implementations to > > VecGetArrayPrecise(), then vectors will work with other vectors of the > same precision and fail otherwise. I think this > > is the correct level of sanity with multi-precision code (demand > explicit conversions of dissimilar types). > > > > I am only really interested in trying this with float+double (Chris > spent all of his time on qd128 which I think has > > no real scientific relevance, but of course we will do this too). The > code changes are relatively minor: > > - Add a precision (PetscDataType) to Vec > > - One new Vec method, VecGetArrayPrecise() > > - Make VecDuplicate() respect precision > > - New Vec implementation for float, built from a template by Python > > If we give a float Vec to Picard, it should compute everything in float > since the Vecs are duplicated. We can add the > > solver convert code later if everything works as expected. I think the > first interesting test would be a nonlinear float > > preconditioner for a double SNES. > > > > I am not interested in being able to use whatever type I want > everywhere. That will never work, and its not clear there is > > any benefit anyway. What I want is just to have solvers of different > precisions work together with explicit conversion at > > the boundary. > > > > Why will this not work? If it will, why will it not be as easy as stated > above? > > > > Matt > > > > -- > > 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 > > -- 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

1 0

Re: [petsc-dev] --with-precision=__float128 tells me to use --download-f-blas-lapack, but I really need --download-f2cblaslapack
by Barry Smith 14 Jul '12

14 Jul '12

Damn PETSc users never know to send the configure.log :-) It is odd that error message has a question mark in it. I have fixed that. The thing is this is during the generic test of the blas/lapack library so I am not sure specific messages about f2cblaslapack belong here. Rather blaslapack.py should be smart enough to know that if quad precision is used f2cblaslapack is the only acceptable blas and not let it get to this point of testing other blases. Barry On Jul 13, 2012, at 11:37 PM, Jed Brown wrote: > ******************************************************************************* > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): > ------------------------------------------------------------------------------- > Could not use downloaded f-blas-lapack? > ******************************************************************************* > > > > What is the intent here? Make f-blas-lapack work or tell the user about f2cblaslapack?

1 0

Re: [petsc-dev] Multiprecision solver composition
by Barry Smith 14 Jul '12

14 Jul '12

It's already there! :-) From petscsys.h /*EC PetscPrecision - indicates what precision the object is using. This is currently not used. Level: advanced .seealso: PetscObjectSetPrecision() E*/ typedef enum { PETSC_PRECISION_SINGLE=4,PETSC_PRECISION_DOUBLE=8 } PetscPrecision; PETSC_EXTERN const char *PetscPrecisions[]; Matt, The biggest stumbling block I've had with doing this in C is not the part you talk about below but the access like VecSetValues(), VecAXPY() etc (and all the Mat ones) that take a scale argument or worse array of scales. How to manage that? You can pass any precision into any object, or only the precision of the object? Always double precision for these arguments? but that is too limiting .... It is hard for me to see how to prevent an explosion of "templated" interfaces of some kind or another. VecGetArray() requesting the precision type may be useful as a starting point. Barry On Jul 14, 2012, at 10:09 AM, Matthew Knepley wrote: > I saw a good talk by Chris Baker at SIAM about multiprecision solvers, and was suitably embarrassed that we cannot do > this. I still strongly believe that templates are the wrong solution, and mucking up perfectly good interfaces with a > bunch of types we do not care about is wrong. I now have a proposal, outlined below. > > We start with the idea of a solver with a certain precision, so that each solver can report the precision it computes > in. Let's restrict ourselves to solvers that only do simple vector operations for the time being. For this then, we > need a Vec object which stores values and computes with this precision, which will be discussed below. Upon entering, > we call VecConvert() on the input vector to get the correct precision, which just references the object if no conversion > is necessary. We VecConvert() the output vector as well before filling it, and the VecConvert() to the output on the way > out. If not conversion is necessary, we get the ssme pointer for the first convert, and no-op for the second. All > internal vectors are created with the solver precision. This all depends on having Vec objects of different precisions. > > I propose we have a different Vec implementation for each precision, maybe saving code by having configure or make > generate the different precisions from a single template. Most Vec operations work by first calling VecGetArray() and > then some BLAS calls. I would now have VecGetArray() do copy-in/copy-out if internal storage has a different precision > than PetscScalar, and add the function VecGetArrayPrecise(Vec v, PetscDataType precision, void **array) which returns > the internal storage if it is the correct precision, and fails otherwise. If we switch implementations to > VecGetArrayPrecise(), then vectors will work with other vectors of the same precision and fail otherwise. I think this > is the correct level of sanity with multi-precision code (demand explicit conversions of dissimilar types). > > I am only really interested in trying this with float+double (Chris spent all of his time on qd128 which I think has > no real scientific relevance, but of course we will do this too). The code changes are relatively minor: > - Add a precision (PetscDataType) to Vec > - One new Vec method, VecGetArrayPrecise() > - Make VecDuplicate() respect precision > - New Vec implementation for float, built from a template by Python > If we give a float Vec to Picard, it should compute everything in float since the Vecs are duplicated. We can add the > solver convert code later if everything works as expected. I think the first interesting test would be a nonlinear float > preconditioner for a double SNES. > > I am not interested in being able to use whatever type I want everywhere. That will never work, and its not clear there is > any benefit anyway. What I want is just to have solvers of different precisions work together with explicit conversion at > the boundary. > > Why will this not work? If it will, why will it not be as easy as stated above? > > Matt > > -- > 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

1 0

Multiprecision solver composition
by Matthew Knepley 14 Jul '12

14 Jul '12

I saw a good talk by Chris Baker at SIAM about multiprecision solvers, and was suitably embarrassed that we cannot do this. I still strongly believe that templates are the wrong solution, and mucking up perfectly good interfaces with a bunch of types we do not care about is wrong. I now have a proposal, outlined below. We start with the idea of a solver with a certain precision, so that each solver can report the precision it computes in. Let's restrict ourselves to solvers that only do simple vector operations for the time being. For this then, we need a Vec object which stores values and computes with this precision, which will be discussed below. Upon entering, we call VecConvert() on the input vector to get the correct precision, which just references the object if no conversion is necessary. We VecConvert() the output vector as well before filling it, and the VecConvert() to the output on the way out. If not conversion is necessary, we get the ssme pointer for the first convert, and no-op for the second. All internal vectors are created with the solver precision. This all depends on having Vec objects of different precisions. I propose we have a different Vec implementation for each precision, maybe saving code by having configure or make generate the different precisions from a single template. Most Vec operations work by first calling VecGetArray() and then some BLAS calls. I would now have VecGetArray() do copy-in/copy-out if internal storage has a different precision than PetscScalar, and add the function VecGetArrayPrecise(Vec v, PetscDataType precision, void **array) which returns the internal storage if it is the correct precision, and fails otherwise. If we switch implementations to VecGetArrayPrecise(), then vectors will work with other vectors of the same precision and fail otherwise. I think this is the correct level of sanity with multi-precision code (demand explicit conversions of dissimilar types). I am only really interested in trying this with float+double (Chris spent all of his time on qd128 which I think has no real scientific relevance, but of course we will do this too). The code changes are relatively minor: - Add a precision (PetscDataType) to Vec - One new Vec method, VecGetArrayPrecise() - Make VecDuplicate() respect precision - New Vec implementation for float, built from a template by Python If we give a float Vec to Picard, it should compute everything in float since the Vecs are duplicated. We can add the solver convert code later if everything works as expected. I think the first interesting test would be a nonlinear float preconditioner for a double SNES. I am not interested in being able to use whatever type I want everywhere. That will never work, and its not clear there is any benefit anyway. What I want is just to have solvers of different precisions work together with explicit conversion at the boundary. Why will this not work? If it will, why will it not be as easy as stated above? Matt -- 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

1 0

Re: [petsc-dev] parallel GPU implementation
by Matthew Knepley 14 Jul '12

14 Jul '12

On Sat, Jul 14, 2012 at 2:43 AM, Olga Tramontano <tramontanoolga(a)yahoo.it>wrote: > Hi all > I was trying to study Petsc for GPUs... I don't understand this: in the > sequential implementation there's one process that uses a signle GPU... and > that's ok! > What about the parallel implementation for GPUs? Are there multiple > processes using the same GPU, or each proess uses a separate GPU like its > own...? > The parallelism is managed by MPI, and we reuse the serial code for interacting with GPUs. Right now, We associate process round-robin with GPUs on the machine, but this should be easily configurable if that does not work for you. Matt > Thanks > -- 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

1 0