February 2017 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Right-preconditioned GMRES
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 7:48 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > On Feb 9, 2017, at 2:31 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 7:29 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr > > wrote: > >> >> On Feb 9, 2017, at 2:17 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> On Thu, Feb 9, 2017 at 7:06 AM, Pierre Jolivet <pierre.jolivet@enseei >> ht.fr> wrote: >> >>> >>> On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >>> >>> On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet@enseei >>> ht.fr> wrote: >>> >>>> Hello, >>>> I _might_ be doing something wrong when calling >>>> KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of >>>> error? >>>> [0]PETSC ERROR: No support for this operation for this object type >>>> [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT >>>> >>>> If not, I’ll try to send a MWE (it basically depends on where I set the >>>> option -ksp_pc_side right). >>>> >>> >>> I believe its telling you that it cannot display the preconditioned >>> residual with right preconditioning, which is true. >>> Are you requesting both? >>> >>> >>> No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” >>> case, it obviously work. >>> However, the error is triggered if I set -ksp_pc_side right after a >>> first call to KSPSetOperators()/KSPSetUp() without destroying the KSP. >>> Should I destroy my KSP before changing from left- (default) to >>> right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? >>> >> >> Its likely you have to use >> >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpage >> s/KSP/KSPSetNormType.html >> >> or >> >> *-ksp_norm_type unpreconditioned* >> >> >> If I use this after my first call to KSPSetUp, I now end up with: >> [0]PETSC ERROR: KSP gmres does not support UNPRECONDITIONED with LEFT >> > > Yes, you would need to use it at the same time that you change the > preconditioning side. > > > Yes, I’m using PetscOptionsInsert, and whether I let PETSc parse > "-ksp_pc_side right -ksp_norm_type unpreconditioned” or "-ksp_norm_type > unpreconditioned -ksp_pc_side right” I end up with the same error > afterwards. > Can you make an example do it (SNES ex5)? Or can you send a small example that does it? Thanks, Matt > Thanks. > > Thanks, > > Matt > >> since we would not have a chance to change it since its been set already. >> >> Thanks, >> >> Matt >> >> Thanks. >>> >>> Thanks, >>> >>> Matt >>> >>> >>>> Thanks, >>>> Pierre >>> >>> >>> >>> >>> -- >>> 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 >> >> >> > > > -- > 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] Right-preconditioned GMRES
by Pierre Jolivet 09 Feb '17

09 Feb '17

> On Feb 9, 2017, at 2:31 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 7:29 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: > >> On Feb 9, 2017, at 2:17 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >> >> On Thu, Feb 9, 2017 at 7:06 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: >> >>> On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >>> >>> On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: >>> Hello, >>> I _might_ be doing something wrong when calling KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of error? >>> [0]PETSC ERROR: No support for this operation for this object type >>> [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT >>> >>> If not, I’ll try to send a MWE (it basically depends on where I set the option -ksp_pc_side right). >>> >>> I believe its telling you that it cannot display the preconditioned residual with right preconditioning, which is true. >>> Are you requesting both? >> >> No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” case, it obviously work. >> However, the error is triggered if I set -ksp_pc_side right after a first call to KSPSetOperators()/KSPSetUp() without destroying the KSP. >> Should I destroy my KSP before changing from left- (default) to right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? >> >> Its likely you have to use >> >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetNormT… <http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetNormT…> >> >> or >> >> -ksp_norm_type unpreconditioned > > If I use this after my first call to KSPSetUp, I now end up with: > [0]PETSC ERROR: KSP gmres does not support UNPRECONDITIONED with LEFT > > Yes, you would need to use it at the same time that you change the preconditioning side. Yes, I’m using PetscOptionsInsert, and whether I let PETSc parse "-ksp_pc_side right -ksp_norm_type unpreconditioned” or "-ksp_norm_type unpreconditioned -ksp_pc_side right” I end up with the same error afterwards. Thanks. > Thanks, > > Matt >> since we would not have a chance to change it since its been set already. >> >> Thanks, >> >> Matt >> >> Thanks. >> >>> Thanks, >>> >>> Matt >>> >>> Thanks, >>> Pierre >>> >>> >>> >>> -- >>> 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 > > > > > -- > 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] Right-preconditioned GMRES
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 7:29 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > > On Feb 9, 2017, at 2:17 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 7:06 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr > > wrote: > >> >> On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet@ >> enseeiht.fr> wrote: >> >>> Hello, >>> I _might_ be doing something wrong when calling >>> KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of >>> error? >>> [0]PETSC ERROR: No support for this operation for this object type >>> [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT >>> >>> If not, I’ll try to send a MWE (it basically depends on where I set the >>> option -ksp_pc_side right). >>> >> >> I believe its telling you that it cannot display the preconditioned >> residual with right preconditioning, which is true. >> Are you requesting both? >> >> >> No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” >> case, it obviously work. >> However, the error is triggered if I set -ksp_pc_side right after a first >> call to KSPSetOperators()/KSPSetUp() without destroying the KSP. >> Should I destroy my KSP before changing from left- (default) to >> right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? >> > > Its likely you have to use > > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/ > KSPSetNormType.html > > or > > *-ksp_norm_type unpreconditioned* > > > If I use this after my first call to KSPSetUp, I now end up with: > [0]PETSC ERROR: KSP gmres does not support UNPRECONDITIONED with LEFT > Yes, you would need to use it at the same time that you change the preconditioning side. Thanks, Matt > since we would not have a chance to change it since its been set already. > > Thanks, > > Matt > > Thanks. >> >> Thanks, >> >> Matt >> >> >>> Thanks, >>> Pierre >> >> >> >> >> -- >> 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 > > > -- 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] Right-preconditioned GMRES
by Pierre Jolivet 09 Feb '17

09 Feb '17

> On Feb 9, 2017, at 2:17 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 7:06 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: > >> On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >> >> On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: >> Hello, >> I _might_ be doing something wrong when calling KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of error? >> [0]PETSC ERROR: No support for this operation for this object type >> [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT >> >> If not, I’ll try to send a MWE (it basically depends on where I set the option -ksp_pc_side right). >> >> I believe its telling you that it cannot display the preconditioned residual with right preconditioning, which is true. >> Are you requesting both? > > No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” case, it obviously work. > However, the error is triggered if I set -ksp_pc_side right after a first call to KSPSetOperators()/KSPSetUp() without destroying the KSP. > Should I destroy my KSP before changing from left- (default) to right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? > > Its likely you have to use > > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetNormT… <http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetNormT…> > > or > > -ksp_norm_type unpreconditioned If I use this after my first call to KSPSetUp, I now end up with: [0]PETSC ERROR: KSP gmres does not support UNPRECONDITIONED with LEFT > since we would not have a chance to change it since its been set already. > > Thanks, > > Matt > > Thanks. > >> Thanks, >> >> Matt >> >> Thanks, >> Pierre >> >> >> >> -- >> 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] Right-preconditioned GMRES
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 7:06 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > > On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr > > wrote: > >> Hello, >> I _might_ be doing something wrong when calling >> KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of >> error? >> [0]PETSC ERROR: No support for this operation for this object type >> [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT >> >> If not, I’ll try to send a MWE (it basically depends on where I set the >> option -ksp_pc_side right). >> > > I believe its telling you that it cannot display the preconditioned > residual with right preconditioning, which is true. > Are you requesting both? > > > No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” > case, it obviously work. > However, the error is triggered if I set -ksp_pc_side right after a first > call to KSPSetOperators()/KSPSetUp() without destroying the KSP. > Should I destroy my KSP before changing from left- (default) to > right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? > Its likely you have to use http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetNormT… or *-ksp_norm_type unpreconditioned* since we would not have a chance to change it since its been set already. Thanks, Matt Thanks. > > Thanks, > > Matt > > >> Thanks, >> Pierre > > > > > -- > 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] Right-preconditioned GMRES
by Pierre Jolivet 09 Feb '17

09 Feb '17

> On Feb 9, 2017, at 1:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: > Hello, > I _might_ be doing something wrong when calling KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of error? > [0]PETSC ERROR: No support for this operation for this object type > [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT > > If not, I’ll try to send a MWE (it basically depends on where I set the option -ksp_pc_side right). > > I believe its telling you that it cannot display the preconditioned residual with right preconditioning, which is true. > Are you requesting both? No, I’m just using -ksp_view and -ksp_pc_side right. In the “standard” case, it obviously work. However, the error is triggered if I set -ksp_pc_side right after a first call to KSPSetOperators()/KSPSetUp() without destroying the KSP. Should I destroy my KSP before changing from left- (default) to right-preconditioning if KSPSetOperators()/KSPSetUp has already been called? Thanks. > Thanks, > > Matt > > Thanks, > Pierre > > > > -- > 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] Right-preconditioned GMRES
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 4:56 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > Hello, > I _might_ be doing something wrong when calling > KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of > error? > [0]PETSC ERROR: No support for this operation for this object type > [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT > > If not, I’ll try to send a MWE (it basically depends on where I set the > option -ksp_pc_side right). > I believe its telling you that it cannot display the preconditioned residual with right preconditioning, which is true. Are you requesting both? Thanks, Matt > Thanks, > Pierre -- 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

Right-preconditioned GMRES
by Pierre Jolivet 09 Feb '17

09 Feb '17

Hello, I _might_ be doing something wrong when calling KSPSetFromOptions/KSPSetUp, but still, am I supposed to get this kind of error? [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: KSP gmres does not support PRECONDITIONED with RIGHT If not, I’ll try to send a MWE (it basically depends on where I set the option -ksp_pc_side right). Thanks, Pierre

1 0

Re: [petsc-dev] using valgrind with new test harness
by Satish Balay 08 Feb '17

08 Feb '17

Namespacing avoids this issue of conflict. You already have PETSCDIFF for the diff. So I changed MPIEXEC to PETSCMPIEXEC Pushed to scott/test-harness-valgrind-v2 and merged to next. Satish On Wed, 8 Feb 2017, Satish Balay wrote: > The old system was just makefile with runtargets using shell. > > So we had: > - default 'VAR=foo' in petscvariables (i.e make variable) > - and we could change the value on command line: 'make VAR=new' > > We avoided 'make -e' early-on [due to buggy make?] and continued to do > so - to avoid picking up user env that could have conflicting stuff > > With the new system we have 'makefile -> gmakefile -> runex.sh' - and > we can run tests at all 3 leves. I think its best if all 3 modes > behave the same way (or pretty close). > > runex.sh will get default values from petsvariables via > ./config/gmakegentest.py - so this case works fine. > > With the default usage of 'make' [i.e without -e] - things can become > inconsistant between make and the script - when user env variables > exist. For ex: > > $ cat makefile > FOO=default_val_make > all: > @echo makevar: ${FOO} > @echo scriptvar: `./script.sh` > $ cat script.sh > #!/bin/sh > FOO=${FOO:-"default_val_script"} > echo $FOO > > > 1. Env variable FOO is not set [and we see the expected behavior. - we would have default_val_make and default_val_script be the same] > $ ./script.sh > default_val_script > $ make > makevar: default_val_make > scriptvar: default_val_script > $ > > 2. With 'FOO' specified to make (via command line) This is fine aswell. (no equivalent stuff for script) > $ make FOO=cmd_var > makevar: cmd_var > scriptvar: cmd_var > > 3. Use env variable. (env var is ignored by make as expected - but > script_var gets changed to make_var? I don't understand this - however > it won't affect our usage as both should be same). > > But now script.sh is picking up this user env variable - which I don't > think we would want to happen. > > $ export FOO=env_var > $ make > makevar: default_val_make > scriptvar: default_val_make > $ ./script.sh > env_var > > > There is also one more thing to worry about: > > the usage is: 'makefile -> gmakefile -> runex.sh' -> "bin/*.sh" and > the scripts in bin can rely on env variables [PETSC_ARCH/PETSC_DIR] > for defaults. So I fixed petscdiff for defaults but I'm avoiding > petscmpiexec and using petsc_mpiexec_valgrind() in petsc_harness.sh > instead. > > [petscdiff currently lets us override defaults with env variables - > perhaps it will also have the same issue as above - so should be fixed > - or we add petsc_diff() in petsc_harness.sh.] > > Satish > > On Wed, 8 Feb 2017, Scott Kruger wrote: > > > > > > > I have no strong objection, but a couple of comments. > > > > Barry said that the old test system could take env variables from the > > command-line. Didn't the old system pull in petscvariables? If so, > > how could it be overwritten. > > > > I think only documenting (and yes, I will need to update the > > documentation when things have settled down) VALGRIND=1 but > > allow the secret -e method would probably be OK. Users that > > know about make -e should be smart enough (?) to know the danger. > > > > Scott > > > > > > On 2/8/17 3:47 PM, Satish Balay wrote: > > > Scott & Barry, > > > > > > I'd like to remove the 'env' variable change. We don't want this to be > > > overwritten as it can be fragile [as users env can have incompatible > > > stuff here] > > > > > > And petscmpiexec relies on env variables - so I'm not using it in the test > > > harness. > > > > > > So I have a branch scott/test-harness-valgrind-v2 (with commits > > > collapsed/fixed) > > > > > > So the following would be the way to use it. > > > > > > make -f gmakefile test VALGRIND=1 > > > > > > Do you have any objections to this? > > > > > > If we want them to be overwritted - then I guess we'll have to namespace > > > them properly. > > > > > > Satish > > > > > > On Wed, 8 Feb 2017, Scott Kruger wrote: > > > > > > > > > > > > > > > Actually Jed's discussion of using env for DIFF had me consider another > > > > solution than the one I had originally came up with. I have both mpiexec > > > > and > > > > diff using this new method to give what Barry > > > > wants more directly: > > > > https://bitbucket.org/petsc/petsc/pull-requests/631/ > > > > > > > > > > > > Both of these now work at the makefile level: > > > > > > > > make -f gmakefile test VALGRIND=1 > > > > > > > > MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind" make -e -f > > > > gmakefile test > > > > > > > > Note that I am passing the -e flag to make which has > > > > the environment variable override the value in > > > > ${PETSC_ARCH}/lib/conf/petscvariables > > > > This can be dangerous depending on how clean your environment is > > > > because it'll override ALL variables. > > > > > > > > > > > > And from the shell script level: > > > > > > > > runex1.sh -V > > > > > > > > MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind" runex1.sh > > > > > > > > > > > > > > > > On 2/7/17 4:42 PM, Barry Smith wrote: > > > > > > > > > > > On Feb 7, 2017, at 5:34 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > > > > > > > > We cannot override stuff via env variables in the new test harness. > > > > > > For > > > > > > nightlybuilds > > > > > > I added support to check if PETSC_ARCH has 'valgrind' string in it - > > > > > > and > > > > > > if so - use > > > > > > valgrind. > > > > > > > > > > > > 26646c0bcc29652ef239540b066d00d1c8fc99c7 > > > > > > > > > > > > Perhaps we can force this to use valgrind with: > > > > > > > > > > > > ./config/gmakegentest.py --valgrind=1 > > > > > > > > > > I can't decide at the time I run the tests, but need to decide when I > > > > > do > > > > > the gmakegentest.py > > > > > > > > > > > > Ok - perhaps the attached patch. > > > > > > > > > > That is one heck of a patch, talk about code duplication resulting in > > > > > endless bugs. > > > > > > > > > > > But then - sometimes gmakefile runs ./config/gmakegentest.py directly > > > > > > [without valgrind] > > > > > > > > > > Fix it properly somehow; currently it is impossible and that is > > > > > insanely > > > > > horrible. > > > > > > > > > > > > > > > > > Satish > > > > > > > > > > > > ------- > > > > > > > > > > > > > > > > > > On Tue, 7 Feb 2017, Barry Smith wrote: > > > > > > > > > > > > > > > > > > > > Both > > > > > > > > > > > > > > make -f gmakefile test > > > > > > > MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec > > > > > > > -valgrind " > > > > > > > > > > > > > > and > > > > > > > > > > > > > > MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind " make -f > > > > > > > gmakefile test > > > > > > > > > > > > > > do not appear to use valgrind in the test harness (the old system > > > > > > > did). > > > > > > > > > > > > > > How do I run all tests under valgrind automatically? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > not ok dm_impls_plex_tests-ex18_1 > > > > > > > # [0]PETSC ERROR: PetscTrFreeDefault() called from > > > > > > > VecDestroy_MPI() line 18 in /sandbox/bsmith/petsc/src/vec\ > > > > > > > /vec/impls/mpi/pdvec.c > > > > > > > # [0]PETSC ERROR: Block [id=0(32)] at address 0xb54240 is > > > > > > > # corrupted (probably write past end of array) > > > > > > > # [0]PETSC ERROR: Block allocated in VecCreate_MPI_Private() > > > > > > > # line > > > > > > > # 497 in /sandbox/bsmith/petsc/src/vec/vec/i\ > > > > > > > mpls/mpi/pbvec.c > > > > > > > # [0]PETSC ERROR: --------------------- Error Message > > > > > > > ------------------------------------------------------\ > > > > > > > -------- > > > > > > > # [0]PETSC ERROR: Memory corruption: > > > > > > > # http://www.mcs.anl.gov/petsc/documentation/installation.html#valgrind > > > > > > > # [0]PETSC ERROR: Corrupted memory > > > > > > > # [0]PETSC ERROR: See > > > > > > > # http://www.mcs.anl.gov/petsc/documentation/faq.html for > > > > > > > # trouble > > > > > > > # shooting. > > > > > > > # [0]PETSC ERROR: Petsc Development GIT revision: > > > > > > > # v3.7.5-3057-g2d11e0f GIT Date: 2017-02-07 15:39:04 -0600 > > > > > > > # [0]PETSC ERROR: ../ex18 on a arch-single named es by bsmith > > > > > > > # Tue > > > > > > > # Feb 7 15:46:25 2017 > > > > > > > # [0]PETSC ERROR: Configure options --download-ctetgen > > > > > > > # --download-exodusii --download-hdf5 --download-mpich \ > > > > > > > --download-netcdf PETSC_ARCH=arch-single --with-precision=single > > > > > > > # [0]PETSC ERROR: #1 PetscTrFreeDefault() line 287 in > > > > > > > # /sandbox/bsmith/petsc/src/sys/memory/mtr.c > > > > > > > # [0]PETSC ERROR: #2 VecDestroy_MPI() line 18 in > > > > > > > # /sandbox/bsmith/petsc/src/vec/vec/impls/mpi/pdvec.c > > > > > > > # [0]PETSC ERROR: #3 VecDestroy() line 406 in > > > > > > > # /sandbox/bsmith/petsc/src/vec/vec/interface/vector.c > > > > > > > # [0]PETSC ERROR: #4 DMDestroy() line 681 in > > > > > > > # /sandbox/bsmith/petsc/src/dm/interface/dm.c > > > > > > > # [0]PETSC ERROR: #5 main() line 473 in > > > > > > > # /sandbox/bsmith/petsc/src/dm/impls/plex/examples/tests/ex18.c > > > > > > > # [0]PETSC ERROR: PETSc Option Table entries: > > > > > > > # [0]PETSC ERROR: -dm_view ascii::ascii_info_detail > > > > > > > # [0]PETSC ERROR: -interpolate > > > > > > > > > > > > > > > > > > > > > > > > > > > <val.patch> > > > > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] using valgrind with new test harness
by Barry Smith 08 Feb '17

08 Feb '17

> On Feb 8, 2017, at 4:47 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > Scott & Barry, > > I'd like to remove the 'env' variable change. We don't want this to be > overwritten as it can be fragile [as users env can have incompatible > stuff here] > > And petscmpiexec relies on env variables - so I'm not using it in the test harness. > > So I have a branch scott/test-harness-valgrind-v2 (with commits collapsed/fixed) > > So the following would be the way to use it. > > make -f gmakefile test VALGRIND=1 > > Do you have any objections to this? This is ok with me. I only want an easy way to add valgrind, I am not advocating using environmental variables to achieve it. > > If we want them to be overwritted - then I guess we'll have to namespace them properly. > > Satish > > On Wed, 8 Feb 2017, Scott Kruger wrote: > >> >> >> Actually Jed's discussion of using env for DIFF had me consider another >> solution than the one I had originally came up with. I have both mpiexec and >> diff using this new method to give what Barry >> wants more directly: >> https://bitbucket.org/petsc/petsc/pull-requests/631/ >> >> >> Both of these now work at the makefile level: >> >> make -f gmakefile test VALGRIND=1 >> >> MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind" make -e -f >> gmakefile test >> >> Note that I am passing the -e flag to make which has >> the environment variable override the value in >> ${PETSC_ARCH}/lib/conf/petscvariables >> This can be dangerous depending on how clean your environment is >> because it'll override ALL variables. >> >> >> And from the shell script level: >> >> runex1.sh -V >> >> MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind" runex1.sh >> >> >> >> On 2/7/17 4:42 PM, Barry Smith wrote: >>> >>>> On Feb 7, 2017, at 5:34 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: >>>> >>>> We cannot override stuff via env variables in the new test harness. For >>>> nightlybuilds >>>> I added support to check if PETSC_ARCH has 'valgrind' string in it - and >>>> if so - use >>>> valgrind. >>>> >>>> 26646c0bcc29652ef239540b066d00d1c8fc99c7 >>>> >>>> Perhaps we can force this to use valgrind with: >>>> >>>> ./config/gmakegentest.py --valgrind=1 >>> >>> I can't decide at the time I run the tests, but need to decide when I do >>> the gmakegentest.py >>>> >>>> Ok - perhaps the attached patch. >>> >>> That is one heck of a patch, talk about code duplication resulting in >>> endless bugs. >>> >>>> But then - sometimes gmakefile runs ./config/gmakegentest.py directly >>>> [without valgrind] >>> >>> Fix it properly somehow; currently it is impossible and that is insanely >>> horrible. >>> >>>> >>>> Satish >>>> >>>> ------- >>>> >>>> >>>> On Tue, 7 Feb 2017, Barry Smith wrote: >>>> >>>>> >>>>> Both >>>>> >>>>> make -f gmakefile test MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec >>>>> -valgrind " >>>>> >>>>> and >>>>> >>>>> MPIEXEC="/sandbox/bsmith/petsc/bin/petscmpiexec -valgrind " make -f >>>>> gmakefile test >>>>> >>>>> do not appear to use valgrind in the test harness (the old system did). >>>>> >>>>> How do I run all tests under valgrind automatically? >>>>> >>>>> >>>>> >>>>> >>>>> not ok dm_impls_plex_tests-ex18_1 >>>>> # [0]PETSC ERROR: PetscTrFreeDefault() called from >>>>> VecDestroy_MPI() line 18 in /sandbox/bsmith/petsc/src/vec\ >>>>> /vec/impls/mpi/pdvec.c >>>>> # [0]PETSC ERROR: Block [id=0(32)] at address 0xb54240 is >>>>> # corrupted (probably write past end of array) >>>>> # [0]PETSC ERROR: Block allocated in VecCreate_MPI_Private() line >>>>> # 497 in /sandbox/bsmith/petsc/src/vec/vec/i\ >>>>> mpls/mpi/pbvec.c >>>>> # [0]PETSC ERROR: --------------------- Error Message >>>>> ------------------------------------------------------\ >>>>> -------- >>>>> # [0]PETSC ERROR: Memory corruption: >>>>> # http://www.mcs.anl.gov/petsc/documentation/installation.html#valgrind >>>>> # [0]PETSC ERROR: Corrupted memory >>>>> # [0]PETSC ERROR: See >>>>> # http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble >>>>> # shooting. >>>>> # [0]PETSC ERROR: Petsc Development GIT revision: >>>>> # v3.7.5-3057-g2d11e0f GIT Date: 2017-02-07 15:39:04 -0600 >>>>> # [0]PETSC ERROR: ../ex18 on a arch-single named es by bsmith Tue >>>>> # Feb 7 15:46:25 2017 >>>>> # [0]PETSC ERROR: Configure options --download-ctetgen >>>>> # --download-exodusii --download-hdf5 --download-mpich \ >>>>> --download-netcdf PETSC_ARCH=arch-single --with-precision=single >>>>> # [0]PETSC ERROR: #1 PetscTrFreeDefault() line 287 in >>>>> # /sandbox/bsmith/petsc/src/sys/memory/mtr.c >>>>> # [0]PETSC ERROR: #2 VecDestroy_MPI() line 18 in >>>>> # /sandbox/bsmith/petsc/src/vec/vec/impls/mpi/pdvec.c >>>>> # [0]PETSC ERROR: #3 VecDestroy() line 406 in >>>>> # /sandbox/bsmith/petsc/src/vec/vec/interface/vector.c >>>>> # [0]PETSC ERROR: #4 DMDestroy() line 681 in >>>>> # /sandbox/bsmith/petsc/src/dm/interface/dm.c >>>>> # [0]PETSC ERROR: #5 main() line 473 in >>>>> # /sandbox/bsmith/petsc/src/dm/impls/plex/examples/tests/ex18.c >>>>> # [0]PETSC ERROR: PETSc Option Table entries: >>>>> # [0]PETSC ERROR: -dm_view ascii::ascii_info_detail >>>>> # [0]PETSC ERROR: -interpolate >>>>> >>>>> >>>>> >>>> <val.patch> >>> >> >> >

1 0