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

Re: [petsc-dev] Error checking on input only vectors
by Jed Brown 16 Jul '13

16 Jul '13

Matthew Knepley <knepley(a)gmail.com> writes: > I think Barry is only suggesting we save the state integer. That's okay, but if we add that, it should only be a warning for a while. Fortran (77) can't enforce this constness and none of the examples use VecGetArrayReadF90 yet. Plenty of users may have internal interfaces that are reused between const and non-const usage, so requiring VecGetArrayRead could cascade into lots of their internal interfaces.

1 0

Re: [petsc-dev] Error checking on input only vectors
by Barry Smith 16 Jul '13

16 Jul '13

On Jul 16, 2013, at 9:34 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Jul 16, 2013 at 9:15 AM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hey, > > As an extra error checking on user code we could save the Vec state of read only input Vecs and check it on exit of the routine to insure the user has not changed the Vec. This could be done in PCApply_Shell(), functions provided to SNES and TS etc. > > we could do that, but I think this would slow the debug build down by quite a substantial amount (VecGetArrayRead() is used quite a lot internally as well), resulting in users to go with optimized builds during the development phase more often. Also, since VecGetArrayRead() returns a pointer to const, a user needs to cast away the const in order to manipulate entries, which already serves as an indication of doing something evil. > > I think Barry is only suggesting we save the state integer. Yes, extremely fast. Barry > > Matt > > What about a second debug level instead, something like 'PETSC_DEBUG_EXTRA', which enables additional, more expensive checks like the one you suggested? We could do similar valgrind-like checks for matrices, etc. there. > > Best regards, > Karli > > > > On Jul 16, 2013, at 8:08 AM, Rémi Lacroix <remi.lacroix(a)inria.fr> wrote: > > Hello, > > I'm currently developing a preconditioner using PETSc. I have a small question about the PCApply function. > > Is it safe to destroy the content of the input vector x while applying the preconditioner or should I make a copy of it and work on that? > > Best regards, > > -- > Rémi Lacroix > Équipe ALPINES > Inria Paris-Rocquencourt / Laboratoire Jacques Louis Lions, UPMC > > > > > > > -- > 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] Error checking on input only vectors
by Matthew Knepley 16 Jul '13

16 Jul '13

On Tue, Jul 16, 2013 at 9:15 AM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hey, > > As an extra error checking on user code we could save the Vec state >> of read only input Vecs and check it on exit of the routine to insure the >> user has not changed the Vec. This could be done in PCApply_Shell(), >> functions provided to SNES and TS etc. >> > > we could do that, but I think this would slow the debug build down by > quite a substantial amount (VecGetArrayRead() is used quite a lot > internally as well), resulting in users to go with optimized builds during > the development phase more often. Also, since VecGetArrayRead() returns a > pointer to const, a user needs to cast away the const in order to > manipulate entries, which already serves as an indication of doing > something evil. > I think Barry is only suggesting we save the state integer. Matt > What about a second debug level instead, something like > 'PETSC_DEBUG_EXTRA', which enables additional, more expensive checks like > the one you suggested? We could do similar valgrind-like checks for > matrices, etc. there. > > Best regards, > Karli > > > >> On Jul 16, 2013, at 8:08 AM, Rémi Lacroix <remi.lacroix(a)inria.fr> wrote: >> >> Hello, >>> >>> I'm currently developing a preconditioner using PETSc. I have a small >>> question about the PCApply function. >>> >>> Is it safe to destroy the content of the input vector x while applying >>> the preconditioner or should I make a copy of it and work on that? >>> >>> Best regards, >>> >>> -- >>> Rémi Lacroix >>> Équipe ALPINES >>> Inria Paris-Rocquencourt / Laboratoire Jacques Louis Lions, UPMC >>> >>> >> > -- 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] Error checking on input only vectors
by Karl Rupp 16 Jul '13

16 Jul '13

Hey, > As an extra error checking on user code we could save the Vec state of read only input Vecs and check it on exit of the routine to insure the user has not changed the Vec. This could be done in PCApply_Shell(), functions provided to SNES and TS etc. we could do that, but I think this would slow the debug build down by quite a substantial amount (VecGetArrayRead() is used quite a lot internally as well), resulting in users to go with optimized builds during the development phase more often. Also, since VecGetArrayRead() returns a pointer to const, a user needs to cast away the const in order to manipulate entries, which already serves as an indication of doing something evil. What about a second debug level instead, something like 'PETSC_DEBUG_EXTRA', which enables additional, more expensive checks like the one you suggested? We could do similar valgrind-like checks for matrices, etc. there. Best regards, Karli > > On Jul 16, 2013, at 8:08 AM, Rï¿½mi Lacroix <remi.lacroix(a)inria.fr> wrote: > >> Hello, >> >> I'm currently developing a preconditioner using PETSc. I have a small question about the PCApply function. >> >> Is it safe to destroy the content of the input vector x while applying the preconditioner or should I make a copy of it and work on that? >> >> Best regards, >> >> -- >> Rï¿½mi Lacroix >> ï¿½quipe ALPINES >> Inria Paris-Rocquencourt / Laboratoire Jacques Louis Lions, UPMC >> >

1 0

Error checking on input only vectors
by Barry Smith 16 Jul '13

16 Jul '13

As an extra error checking on user code we could save the Vec state of read only input Vecs and check it on exit of the routine to insure the user has not changed the Vec. This could be done in PCApply_Shell(), functions provided to SNES and TS etc. Barry On Jul 16, 2013, at 8:08 AM, Rémi Lacroix <remi.lacroix(a)inria.fr> wrote: > Hello, > > I'm currently developing a preconditioner using PETSc. I have a small question about the PCApply function. > > Is it safe to destroy the content of the input vector x while applying the preconditioner or should I make a copy of it and work on that? > > Best regards, > > -- > Rémi Lacroix > Équipe ALPINES > Inria Paris-Rocquencourt / Laboratoire Jacques Louis Lions, UPMC >

1 0

Re: [petsc-dev] Fixes for ts/examples/tutorials ex16 and ex21
by Matthew Knepley 15 Jul '13

15 Jul '13

On Mon, Jul 15, 2013 at 11:42 AM, Patrick Sanan <psanan(a)cms.caltech.edu>wrote: > When trying to run two of the TS examples, I saw an error about matrices > in the wrong state. Adding MatSetUp as the error messages suggest prevents > the error from being thrown. A patch is attached (or I can push a branch > and submit a pull request if that's a better way to deal with a small > potential fix like this). > The branch and pull-request would be nice. It sounds like the right fix. Thanks, 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

Fixes for ts/examples/tutorials ex16 and ex21
by Patrick Sanan 15 Jul '13

15 Jul '13

When trying to run two of the TS examples, I saw an error about matrices in the wrong state. Adding MatSetUp as the error messages suggest prevents the error from being thrown. A patch is attached (or I can push a branch and submit a pull request if that's a better way to deal with a small potential fix like this).

1 0

Fw:SmartPhones,tablet PCs
by cherickchan 15 Jul '13

15 Jul '13

| Hi there, Attached please find the updated price list of SmartPhones,tablet PCs. We are here awaiting your enquiry. Best regards, Cherick MeiLin Industrial Co.LTD. Tel.: 86-755-82701410 Mob.: 86-136 7020 1700 Fax: 86-755-83451931 E-mail: sales ( at ) meilin-industrial.com Skype: chenhaizhou2005 Web: www (dot ) meilin-industrial (dot ) com | | | | | |

1 0

Uninitialized values with MUMPS
by Stefano Zampini 12 Jul '13

12 Jul '13

Have you ever noticed this from KSP tutorial ex52? I'm wondering whether it could be related with PETSc interface to MUMPS or it is a problem on the MUMPS side. The valgrind error come out once the first time the KSP is solved, then disappear if KSPSolve is repeatedly called. ==31042== Command: ./ex52 -use_mumps_lu ==31042== Parent PID: 31041 ==31042== ==31042== Syscall param writev(vector[...]) points to uninitialised byte(s) ==31042== at 0x70C761B: writev (writev.c:51) ==31042== by 0x8262108: MPIDU_Sock_writev (sock_immed.i:610) ==31042== by 0x824B0DB: MPIDI_CH3_iSendv (ch3_isendv.c:84) ==31042== by 0x823F4F2: MPIDI_CH3_PktHandler_RndvClrToSend (ch3u_rndv.c:249) ==31042== by 0x824C417: MPIDI_CH3I_Progress_handle_sock_event (ch3_progress.c:453) ==31042== by 0x824C4D7: MPIDI_CH3i_Progress_test (ch3_progress.c:95) ==31042== by 0x82A9AAF: MPIR_Test_impl (test.c:50) ==31042== by 0x82A9B88: PMPI_Test (test.c:151) ==31042== by 0x8224829: mpi_test (testf.c:200) ==31042== by 0x61A8805: __dmumps_comm_buffer_MOD_dmumps_4 (dmumps_comm_buffer.F:635) ==31042== by 0x61A8D83: __dmumps_comm_buffer_MOD_dmumps_62 (dmumps_comm_buffer.F:554) ==31042== by 0x6230D6E: dmumps_242_ (dmumps_part2.F:739) ==31042== Address 0x9d0af38 is 8 bytes inside a block of size 336 alloc'd ==31042== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31042== by 0x61AAE8F: __dmumps_comm_buffer_MOD_dmumps_2 (dmumps_comm_buffer.F:175) ==31042== by 0x61AB27C: __dmumps_comm_buffer_MOD_dmumps_55 (dmumps_comm_buffer.F:123) ==31042== by 0x6186B64: dmumps_301_ (dmumps_part8.F:989) ==31042== by 0x61FBA10: dmumps_ (dmumps_part1.F:665) ==31042== by 0x60DE3FB: dmumps_f77_ (dmumps_part3.F:6651) ==31042== by 0x60B7219: dmumps_c (mumps_c.c:422) ==31042== by 0x59AE73F: MatSolve_MUMPS (mumps.c:591) ==31042== by 0x58B1DB7: MatSolve (matrix.c:3178) ==31042== by 0x5CB6A19: PCApply_LU (lu.c:198) ==31042== by 0x5C1E9DE: PCApply (precon.c:442) ==31042== by 0x5E0FE44: KSP_PCApply (kspimpl.h:227) -- Ph. D. Stefano Zampini CINECA SuperComputing Applications and Innovations Department - SCAI Via dei Tizii, 6 00185 Roma - ITALY ------------------------------------------------------------------------------------------------------------------------ Email: s.zampini(a)cineca.it SkypeID: stefano.zampini GoogleTalk: stefano.zampini(a)gmail.com Tel: +39 06.44486.707 ------------------------------------------------------------------------------------------------------------------------

1 0

Re: [petsc-dev] seen on a competitors site
by Aron Ahmadia 09 Jul '13

09 Jul '13

I can get you in contact with the folks at Continuum responsible for testing. I suggest issuing a pull request against the official conda-recipes directory. A On Tue, Jul 9, 2013 at 5:22 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Aron Ahmadia <aron(a)ahmadia.net> writes: > > > http://docs.continuum.io/conda/build.html > > > > Probably most relevant :) > > > > https://github.com/ContinuumIO/conda-recipes/tree/master/trilinos > > Looks easy. Is there some automated testing or are we expected to spin > up Anaconda instances on all supported architectures? >

1 0