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

Re: [petsc-dev] Test harness upgrade
by Barry Smith 10 Feb '17

10 Feb '17

See comments below in text, but I realized I should have brought something up about subtests and loops. Is there any assumption about the order that the subtests (entries) in loop are run? If so, why? Shouldn't each subtest be handed off to gnumake to decide when to run? i.e each subtest becomes its own script and each script its own rule for make to schedule? > On Feb 10, 2017, at 5:41 PM, Scott Kruger <kruger(a)txcorp.com> wrote: > > > > On 2/10/17 4:28 PM, Barry Smith wrote: > >>> To illustrate the point here, I will use examples >>> from ksp/ksp/examples/tutorials/ex10.c >>> >>> Consider this test block: >>> >>> test: >>> suffix: 19 >>> requires: datafilespath >>> args: -f0 ${DATAFILESPATH}/matrices/poisson1 >>> args: -ksp_type cg -pc_type icc -pc_factor_levels 2 >>> test: >>> test: >> >> Why is test listed twice here? > > To invoke mpiexec twice. The first invocation > will have no additional args beyond what the parent > has. But why would I EVER want to run it again with the same arguments as the previous time? Run the same test with the same arguments? > The second invocation adds an arg. > >>> >>> test: >>> requires: datafilespath >>> args: -f0 ${DATAFILESPATH}/matrices/medium >>> args: -ksp_type bicg >>> test: >>> suffix: 4 >>> args: -pc_type lu >>> test: >>> suffix: 5 >>> >>> This will generate runex4.sh and runex5.sh that only >>> differ in the '-pc_type lu' in the arguments and in >>> the output file names. >>> One can quickly see that they are very similar tests, >>> and it's very compact in it's representation. >> >> So the indentation is what indicates it is a subtest versus a completely new test? > > Indentation only: subtest (mpiexec/diff with info inherited from parent) > Indentation+suffix: New test with info inherited from parent > > > >>> Here is an example. The key variable is >>> separate_testvars which says that the loop >>> variable should create separate tests. >>> >>> test: >>> suffix: 19 >>> requires: datafilespath >>> args: -f0 ${DATAFILESPATH}/matrices/poisson1 >>> args: -ksp_type cg -pc_type icc >>> args: -pc_factor_levels {{0 2 4}} >>> separate_testvars: pc_factor_levels >> >> Without the - ? > > Yes. Right now for loops have to be of the form: > -var {{values}} > so it seemed less confusing to just specify var > > >>> test: >>> args: >>> test: >>> args: -mat_type seqsbaij >>> >> >> Instead of having the ugly separate_testvars argument could you somehow indicate it with the loop definition? >> >>> args: -pc_factor_levels {{0 2 4}separate test output files} >> >> and >> >>> args: -pc_factor_levels {{0 2 4}shared test output file} >> > > It's possible. > > What about [[0 2 4]] implying separate test output files? That works, the problem is that people have to remember what {{ means and and what [[ means. I would never be able to keep them straight, better to have a clear word that distinguishes them. I agree what I suggest is wordy, could be "shared/separate output" > > > > Scott > > > -- > Tech-X Corporation kruger(a)txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 > Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Test harness upgrade
by Scott Kruger 10 Feb '17

10 Feb '17

On 2/10/17 4:28 PM, Barry Smith wrote: >> To illustrate the point here, I will use examples >> from ksp/ksp/examples/tutorials/ex10.c >> >> Consider this test block: >> >> test: >> suffix: 19 >> requires: datafilespath >> args: -f0 ${DATAFILESPATH}/matrices/poisson1 >> args: -ksp_type cg -pc_type icc -pc_factor_levels 2 >> test: >> test: > > Why is test listed twice here? To invoke mpiexec twice. The first invocation will have no additional args beyond what the parent has. The second invocation adds an arg. >> >> test: >> requires: datafilespath >> args: -f0 ${DATAFILESPATH}/matrices/medium >> args: -ksp_type bicg >> test: >> suffix: 4 >> args: -pc_type lu >> test: >> suffix: 5 >> >> This will generate runex4.sh and runex5.sh that only >> differ in the '-pc_type lu' in the arguments and in >> the output file names. >> One can quickly see that they are very similar tests, >> and it's very compact in it's representation. > > So the indentation is what indicates it is a subtest versus a completely new test? Indentation only: subtest (mpiexec/diff with info inherited from parent) Indentation+suffix: New test with info inherited from parent >> Here is an example. The key variable is >> separate_testvars which says that the loop >> variable should create separate tests. >> >> test: >> suffix: 19 >> requires: datafilespath >> args: -f0 ${DATAFILESPATH}/matrices/poisson1 >> args: -ksp_type cg -pc_type icc >> args: -pc_factor_levels {{0 2 4}} >> separate_testvars: pc_factor_levels > > Without the - ? Yes. Right now for loops have to be of the form: -var {{values}} so it seemed less confusing to just specify var >> test: >> args: >> test: >> args: -mat_type seqsbaij >> > > Instead of having the ugly separate_testvars argument could you somehow indicate it with the loop definition? > >> args: -pc_factor_levels {{0 2 4}separate test output files} > > and > >> args: -pc_factor_levels {{0 2 4}shared test output file} > It's possible. What about [[0 2 4]] implying separate test output files? Scott -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Diff of numbers for new test framework
by Scott Kruger 10 Feb '17

10 Feb '17

On 2/3/17 6:25 AM, Matthew Knepley wrote: > On Thu, Feb 2, 2017 at 10:36 PM, Barry Smith <bsmith(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > > > On Feb 2, 2017, at 10:24 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: > > > > How do we handle this? > > $PETSC_DIR/bin/petscdiff is used, it considers any floating point > number to equal any other floating point number :-) > > > > My Python stuff parses it and compares numbers > > using tolerances. > > How do you provide the tolerances in your Python stuff? Do you > provide different tolerances for different examples? For different > numbers in the same example? How is that information passed to the > tester? > > We can improve petscdiff, but we need specific suggestions on > how do this. Specific difficulties include when the "correct" answer > is 0 but "good enough answers may be negative or positive and what > is good enough in that case? > > > I right now do the dumbest thing which is to have a fixed relative and > absolute tolerance for every comparison. This works MUCH better > than exact comparison and is not hard. I say we start with that. Matt: If you add a petscdiff.py to bin that has the same arguments as the current shell script plus atol and rtol, then I can hook up atol and rtol keywords in the test harness. Scott > > Matt > > > We could have a single "tolerance" for each test or to get > complicated and have the "gold standard" output file could do stuff > like 3.45+-.03 and petscdiff could be smart enough to parse that > and do the right thing, but is that needed? > > > Barry > > > > > > 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 > > > > > -- > 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 -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Test harness upgrade
by Barry Smith 10 Feb '17

10 Feb '17

> On Feb 10, 2017, at 5:18 PM, Scott Kruger <kruger(a)txcorp.com> wrote: > > > As promised, here is the pull request discussed earlier > (before close-of-business Central time!): > https://bitbucket.org/petsc/petsc/pull-requests/633 > > To illustrate the point here, I will use examples > from ksp/ksp/examples/tutorials/ex10.c > > Consider this test block: > > test: > suffix: 19 > requires: datafilespath > args: -f0 ${DATAFILESPATH}/matrices/poisson1 > args: -ksp_type cg -pc_type icc -pc_factor_levels 2 > test: > test: Why is test listed twice here? > args: -mat_type seqsbaij > > which has two subtests or children tests (feel free to rename). > This will generate a shell script runex19.sh that does something like: > mpiexec -n 1 ex19 ${args} > ex19.temp > petscdiff ex19.out ex19.tmp > mpiexec -n 1 ex19 ${args} -mat_type seqsbaij > ex19.temp > petscdiff ex19.out ex19.tmp > > > This works because the argument '-mat_type seqsbaij' > DOES NOT CHANGE THE OUTPUT enabling the same output_file > to be used. It also makes for a nice compact specification. > > But what if arguments change the output file? > Putting suffix then triggers separate "tests" (defined as > separate shell scripts): > > test: > requires: datafilespath > args: -f0 ${DATAFILESPATH}/matrices/medium > args: -ksp_type bicg > test: > suffix: 4 > args: -pc_type lu > test: > suffix: 5 > > This will generate runex4.sh and runex5.sh that only > differ in the '-pc_type lu' in the arguments and in > the output file names. > One can quickly see that they are very similar tests, > and it's very compact in it's representation. So the indentation is what indicates it is a subtest versus a completely new test? > > > Now consider for loops: > test: > suffix: 7_d > requires: datafilespath > args: -f0 ${DATAFILESPATH}/matrices/medium > args: -viewer_binary_skip_info -mat_type seqbaij > args: -matload_block_size {{2 3 4 5 6 7 8}} > args: -ksp_type preonly -pc_type lu > > This generates: > -------------------------------------- > for matload_block_size in 2 3 4 5 6 7 8; do > > petsc_testrun "${mpiexec} -n 1 ${exec} ${args} -matload_block_siz > e ${matload_block_size}" ex10_7_d.tmp ${testname}.err "${label}_matlo > ad_block_size-${matload_block_size}" > > petsc_testrun "${diff_exe} /Users/kruger/ptsolveall/upstream/petsc > /src/ksp/ksp/examples/tutorials/output/ex10_7_d.out ex10_7_d.tmp" dif > f-${testname}.out diff-${testname}.out diff-${label}_matload_block_si > ze-${matload_block_size} "" > > done > -------------------------------------- > > All 7 diff tests will be against the same file. > Here, I have the reporting being labelled with > the variable name and value to make it easy to > see what is being tested. > > > > What if your for loop creates a different output? > > In most of the petsc legacy tests this seemed to be > handled by appending it to one massive file and diffing > the whole thing. Keeping with the > 1 shell script => 1 file > we want to have it labelled. Tobin proposed one > naming scheme that gives a lot of developer control, > but I moved to a more automated naming scheme (we'll > see if it is sufficient or not). > > Here is an example. The key variable is > separate_testvars which says that the loop > variable should create separate tests. > > test: > suffix: 19 > requires: datafilespath > args: -f0 ${DATAFILESPATH}/matrices/poisson1 > args: -ksp_type cg -pc_type icc > args: -pc_factor_levels {{0 2 4}} > separate_testvars: pc_factor_levels Without the - ? > test: > args: > test: > args: -mat_type seqsbaij > Instead of having the ugly separate_testvars argument could you somehow indicate it with the loop definition? > args: -pc_factor_levels {{0 2 4}separate test output files} and > args: -pc_factor_levels {{0 2 4}shared test output file} > This will generate 3 shell scripts: > runex10_19_pc_factor_levels-0.sh > runex10_19_pc_factor_levels-2.sh > runex10_19_pc_factor_levels-4.sh > > Each with a different output file being > tested against (but each shell script > invoking ex19 twice). > > Between suffixes and separate_testvars, > it's easy to go nuts (even multiple loops > can make it get very verbose). Here is > an example from ex10: > > test: > suffix: 7 > requires: datafilespath > args: -f0 ${DATAFILESPATH}/matrices/medium > args: -viewer_binary_skip_info -mat_type seqbaij > args: -matload_block_size {{2 3 4 5 6 7 8}} > args: -ksp_max_it 100 -ksp_gmres_cgs_refinement_type refine_always > args: -ksp_rtol 1.0e-15 -ksp_monitor_short > separate_testvars: matload_block_size > test: > suffix: a > test: > suffix: b > args: -pc_factor_mat_ordering_type nd > test: > suffix: c > args: -pc_factor_levels 1 > > > This creates 21 shell scripts: > runex10_7_matload_block_size-2_a.sh > runex10_7_matload_block_size-2_b.sh > runex10_7_matload_block_size-2_c.sh > runex10_7_matload_block_size-3_a.sh > ... > > > ex10 is a good example because there were > 63 runex10* targets in the makefile. After > conversion, we have 110 shell scripts being > generated coming from this separation of files > instead of concatenation. > > The mumps examples are also interesting because > they exercise a lot of mumps and petsc options, but they > are all diffed against the same file. This uses > the output_file parameter to enable specification > of this same output_file. > > > Other misc: > testparse.py gives better much better error reporting > although I highly recommend invoking it directly > during development to catch errors. It saved me > a bunch of time while converting ex10.c. > > gmakegentest.py is cleaner. Many thanks to > Tobin for help in this. > > -- > Tech-X Corporation kruger(a)txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 > Boulder, CO 80303 Fax: (303) 448-7756

1 0

Test harness upgrade
by Scott Kruger 10 Feb '17

10 Feb '17

As promised, here is the pull request discussed earlier (before close-of-business Central time!): https://bitbucket.org/petsc/petsc/pull-requests/633 To illustrate the point here, I will use examples from ksp/ksp/examples/tutorials/ex10.c Consider this test block: test: suffix: 19 requires: datafilespath args: -f0 ${DATAFILESPATH}/matrices/poisson1 args: -ksp_type cg -pc_type icc -pc_factor_levels 2 test: test: args: -mat_type seqsbaij which has two subtests or children tests (feel free to rename). This will generate a shell script runex19.sh that does something like: mpiexec -n 1 ex19 ${args} > ex19.temp petscdiff ex19.out ex19.tmp mpiexec -n 1 ex19 ${args} -mat_type seqsbaij > ex19.temp petscdiff ex19.out ex19.tmp This works because the argument '-mat_type seqsbaij' DOES NOT CHANGE THE OUTPUT enabling the same output_file to be used. It also makes for a nice compact specification. But what if arguments change the output file? Putting suffix then triggers separate "tests" (defined as separate shell scripts): test: requires: datafilespath args: -f0 ${DATAFILESPATH}/matrices/medium args: -ksp_type bicg test: suffix: 4 args: -pc_type lu test: suffix: 5 This will generate runex4.sh and runex5.sh that only differ in the '-pc_type lu' in the arguments and in the output file names. One can quickly see that they are very similar tests, and it's very compact in it's representation. Now consider for loops: test: suffix: 7_d requires: datafilespath args: -f0 ${DATAFILESPATH}/matrices/medium args: -viewer_binary_skip_info -mat_type seqbaij args: -matload_block_size {{2 3 4 5 6 7 8}} args: -ksp_type preonly -pc_type lu This generates: -------------------------------------- for matload_block_size in 2 3 4 5 6 7 8; do petsc_testrun "${mpiexec} -n 1 ${exec} ${args} -matload_block_siz e ${matload_block_size}" ex10_7_d.tmp ${testname}.err "${label}_matlo ad_block_size-${matload_block_size}" petsc_testrun "${diff_exe} /Users/kruger/ptsolveall/upstream/petsc /src/ksp/ksp/examples/tutorials/output/ex10_7_d.out ex10_7_d.tmp" dif f-${testname}.out diff-${testname}.out diff-${label}_matload_block_si ze-${matload_block_size} "" done -------------------------------------- All 7 diff tests will be against the same file. Here, I have the reporting being labelled with the variable name and value to make it easy to see what is being tested. What if your for loop creates a different output? In most of the petsc legacy tests this seemed to be handled by appending it to one massive file and diffing the whole thing. Keeping with the 1 shell script => 1 file we want to have it labelled. Tobin proposed one naming scheme that gives a lot of developer control, but I moved to a more automated naming scheme (we'll see if it is sufficient or not). Here is an example. The key variable is separate_testvars which says that the loop variable should create separate tests. test: suffix: 19 requires: datafilespath args: -f0 ${DATAFILESPATH}/matrices/poisson1 args: -ksp_type cg -pc_type icc args: -pc_factor_levels {{0 2 4}} separate_testvars: pc_factor_levels test: args: test: args: -mat_type seqsbaij This will generate 3 shell scripts: runex10_19_pc_factor_levels-0.sh runex10_19_pc_factor_levels-2.sh runex10_19_pc_factor_levels-4.sh Each with a different output file being tested against (but each shell script invoking ex19 twice). Between suffixes and separate_testvars, it's easy to go nuts (even multiple loops can make it get very verbose). Here is an example from ex10: test: suffix: 7 requires: datafilespath args: -f0 ${DATAFILESPATH}/matrices/medium args: -viewer_binary_skip_info -mat_type seqbaij args: -matload_block_size {{2 3 4 5 6 7 8}} args: -ksp_max_it 100 -ksp_gmres_cgs_refinement_type refine_always args: -ksp_rtol 1.0e-15 -ksp_monitor_short separate_testvars: matload_block_size test: suffix: a test: suffix: b args: -pc_factor_mat_ordering_type nd test: suffix: c args: -pc_factor_levels 1 This creates 21 shell scripts: runex10_7_matload_block_size-2_a.sh runex10_7_matload_block_size-2_b.sh runex10_7_matload_block_size-2_c.sh runex10_7_matload_block_size-3_a.sh ... ex10 is a good example because there were 63 runex10* targets in the makefile. After conversion, we have 110 shell scripts being generated coming from this separation of files instead of concatenation. The mumps examples are also interesting because they exercise a lot of mumps and petsc options, but they are all diffed against the same file. This uses the output_file parameter to enable specification of this same output_file. Other misc: testparse.py gives better much better error reporting although I highly recommend invoking it directly during development to catch errors. It saved me a bunch of time while converting ex10.c. gmakegentest.py is cleaner. Many thanks to Tobin for help in this. -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] segfaults with mpich 3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)
by Matthew Knepley 10 Feb '17

10 Feb '17

On Fri, Feb 10, 2017 at 2:33 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > See https://github.com/elemental/Elemental/issues/200. > Excellent find Jeff. Matt > Jeff > > On Fri, Feb 10, 2017 at 12:05 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> I am using MPICH 3.2 with 8.2.1 and typically run the entire PETSc test >> suite. Have not observed problems. Maybe upgrade Xcode first? >> >> >> > On Feb 10, 2017, at 1:59 PM, Brad Aagaard <baagaard(a)usgs.gov> wrote: >> > >> > Are there any known issues with mpich3.2 and clang (Apple LLVM 8.0.0, >> clang 800.0.42.1)? I am getting segfaults in MPI routines within PETSc. >> > The error is: write_line error; fd=-1 buf=:cmd=abort exitcode=59, which >> appears to be similar to the recent DMPlexCreateExodusFromFile() does not >> work on macOS Sierra thread >> > https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2017- >> January/031463.html >> > >> > However, I am not using any Darwin packaging system like homebrew. I am >> building PETSc via the PyLith installer which builds mpich, NetCDF, HDF5, >> etc from scratch using the Apple's clang. If I swap mpich3.2 for >> mpich3.1.3, these segfaults go away, so I am inclined to blame mpich3.2. >> > >> > If this is a unknown or undiagnosed issue, I will try a standalone >> PETSc install to try to reproduce it. >> > >> > Thanks, >> > Brad >> > >> > >> >> > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > -- 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] segfaults with mpich 3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)
by Jeff Hammond 10 Feb '17

10 Feb '17

See https://github.com/elemental/Elemental/issues/200. Jeff On Fri, Feb 10, 2017 at 12:05 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I am using MPICH 3.2 with 8.2.1 and typically run the entire PETSc test > suite. Have not observed problems. Maybe upgrade Xcode first? > > > > On Feb 10, 2017, at 1:59 PM, Brad Aagaard <baagaard(a)usgs.gov> wrote: > > > > Are there any known issues with mpich3.2 and clang (Apple LLVM 8.0.0, > clang 800.0.42.1)? I am getting segfaults in MPI routines within PETSc. > > The error is: write_line error; fd=-1 buf=:cmd=abort exitcode=59, which > appears to be similar to the recent DMPlexCreateExodusFromFile() does not > work on macOS Sierra thread > > https://lists.mcs.anl.gov/mailman/htdig/petsc-users/ > 2017-January/031463.html > > > > However, I am not using any Darwin packaging system like homebrew. I am > building PETSc via the PyLith installer which builds mpich, NetCDF, HDF5, > etc from scratch using the Apple's clang. If I swap mpich3.2 for > mpich3.1.3, these segfaults go away, so I am inclined to blame mpich3.2. > > > > If this is a unknown or undiagnosed issue, I will try a standalone PETSc > install to try to reproduce it. > > > > Thanks, > > Brad > > > > > > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [petsc-dev] segfaults with mpich 3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)
by Barry Smith 10 Feb '17

10 Feb '17

I am using MPICH 3.2 with 8.2.1 and typically run the entire PETSc test suite. Have not observed problems. Maybe upgrade Xcode first? > On Feb 10, 2017, at 1:59 PM, Brad Aagaard <baagaard(a)usgs.gov> wrote: > > Are there any known issues with mpich3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)? I am getting segfaults in MPI routines within PETSc. > The error is: write_line error; fd=-1 buf=:cmd=abort exitcode=59, which appears to be similar to the recent DMPlexCreateExodusFromFile() does not work on macOS Sierra thread > https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2017-January/031463.html > > However, I am not using any Darwin packaging system like homebrew. I am building PETSc via the PyLith installer which builds mpich, NetCDF, HDF5, etc from scratch using the Apple's clang. If I swap mpich3.2 for mpich3.1.3, these segfaults go away, so I am inclined to blame mpich3.2. > > If this is a unknown or undiagnosed issue, I will try a standalone PETSc install to try to reproduce it. > > Thanks, > Brad > >

1 0

segfaults with mpich 3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)
by Brad Aagaard 10 Feb '17

10 Feb '17

Are there any known issues with mpich3.2 and clang (Apple LLVM 8.0.0, clang 800.0.42.1)? I am getting segfaults in MPI routines within PETSc. The error is: write_line error; fd=-1 buf=:cmd=abort exitcode=59, which appears to be similar to the recent DMPlexCreateExodusFromFile() does not work on macOS Sierra thread https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2017-January/031463.html However, I am not using any Darwin packaging system like homebrew. I am building PETSc via the PyLith installer which builds mpich, NetCDF, HDF5, etc from scratch using the Apple's clang. If I swap mpich3.2 for mpich3.1.3, these segfaults go away, so I am inclined to blame mpich3.2. If this is a unknown or undiagnosed issue, I will try a standalone PETSc install to try to reproduce it. Thanks, Brad

1 0

Re: [petsc-dev] Right-preconditioned GMRES
by Pierre Jolivet 10 Feb '17

10 Feb '17

I forgot to mention this, but you just need to run: mpirun -np 1 ./ex1 Can you reproduce the issue? Thanks. > On Feb 9, 2017, at 10:52 PM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > > There, attached. > > Thanks. > > PS: here is the patch also, just in case > diff --git a/src/ksp/ksp/examples/tutorials/ex1.c b/src/ksp/ksp/examples/tutorials/ex1.c > index 6382c09..d9dc69a 100644 > --- a/src/ksp/ksp/examples/tutorials/ex1.c > +++ b/src/ksp/ksp/examples/tutorials/ex1.c > @@ -123,6 +123,11 @@ int main(int argc,char **args) > routines. > */ > ierr = KSPSetFromOptions(ksp);CHKERRQ(ierr); > + ierr = KSPSetUp(ksp);CHKERRQ(ierr); > + char right_options[] = "-ksp_norm_type unpreconditioned -ksp_pc_side right"; > + PetscOptionsInsertString(NULL,right_options); > + ierr = KSPSetFromOptions(ksp);CHKERRQ(ierr); > + ierr = KSPSetUp(ksp);CHKERRQ(ierr); > > if (nonzeroguess) { > PetscScalar p = .5; > > <ex1.c> > >> On Feb 9, 2017, at 2:56 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >> >> On Thu, Feb 9, 2017 at 7:48 AM, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: >>> On Feb 9, 2017, at 2:31 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> 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. >> >> 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