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

Re: [petsc-dev] MatCreateSubmatrices causes invalid memory write access in fortran
by Hong 19 Apr '18

19 Apr '18

Tim: It is in the release branch https://bitbucket.org/petsc/petsc/commits/f79229c73db120b69d05e6d49c19f429e… Thanks for reporting it. Hong Hong, > we are fine with that. Thanks! > Volker > > 2018-04-18 17:32 GMT+02:00 Hong <hzhang(a)mcs.anl.gov>: > > Tim : > >> > >> Hi all, > >> > >> with PETSc v3.9 there seems to be a out of bounds write in the fortran > >> interface of MatCreateSubmatrices. > >> > >> https://bitbucket.org/petsc/petsc/src/59479656cffe26dd9a9d446f6d00df > e5e3168168/src/mat/interface/ftn-custom/zmatrixf.c?at= > maint&fileviewer=file-view-default#zmatrixf.c-609 > >> > >> The reference mentions that in fortran one should pass a preallocated > >> array for submat with at least the size of m (actually it's probably a > >> typo and should be n) > >> > >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/ > MatCreateSubMatrices.html > >> > >> Then n+1 entries are copied into that array, where the last entry > >> seems to be some unneeded dummy (as mentioned). > >> for (i=0; i<=*n; i++) { /* lsmat[*n] might be a dummy matrix for > >> saving data struc */ > >> smat[i] = lsmat[i]; > >> } > >> This leads to some bad errors afterwards, when that array is only of > >> the size of n as recommended. > > > > > > We need this extra space for reuse -- I agree it makes Fortran API odd. > > > > I made following fix to the help manual: > > diff --git a/src/mat/interface/matrix.c b/src/mat/interface/matrix.c > > > > When finished using the submatrices, the user should destroy > > - them with MatDestroyMatrices(). > > + them with MatDestroySubMatrices(). > > > > Fortran Note: > > The Fortran interface is slightly different from that given below; it > > - requires one to pass in as submat a Mat (integer) array of size at > > least m. > > + requires one to pass in as submat a Mat (integer) array of size at > > least n+1. > > > > If you agree, I'll push it to the petsc released version. > > > > Hong > > >

1 0

Re: [petsc-dev] Is mpich/master:a8a2b30fd21 tested with Petsc?
by Min Si 19 Apr '18

19 Apr '18

Hi Junchao, This is a great idea. We will add large tag tests in our test suite ! Min On 2018/04/17 18:17, Junchao Zhang wrote: > Min, > I suggest MPICH add tests to play with the maximal MPI tag (through > attribute MPI_TAG_UB). > PETSc uses tags from the maximal and downwards. I guess MPICH tests > use small tags. That is why the bug only showed up with PETSc. > > --Junchao Zhang > > On Tue, Apr 17, 2018 at 3:58 PM, Min Si <msi(a)anl.gov > <mailto:[email protected]>> wrote: > > Hi all, > > Thanks for narrowing down the problem. I checked the MPICH code > and believe this is a bug in MPICH. I just created a PR to fix it: > https://github.com/pmodels/mpich/pull/3097 > <https://github.com/pmodels/mpich/pull/3097> > > It should be merged into MPICH master branch soon. > > Thanks, > Min > > > On 2018/04/17 14:10, Eric Chamberland wrote: > > Hi, > > are we talking about the "tag" passed to MPI_Isend for example? > > but does that mean there is something to change for any MPI > call which involves tags usage or is it only a PETSc "bad" tag > usage? > > thanks Satish for your finding! > > Eric > > On 16/04/18 11:31 PM, Satish Balay wrote: > > On Tue, 13 Mar 2018, Eric Chamberland wrote: > > Hi, > > each night we are testing mpich/master with our > petsc-based code. I don't > know if PETSc team is doing the same thing with > mpich/master? (Maybe it is a > good idea?) > > Everything was fine (except the issue > https://github.com/pmodels/mpich/issues/2892 > <https://github.com/pmodels/mpich/issues/2892>) up to > commit 7b8d64debd, but > since commit mpich:a8a2b30fd21), I have a segfault on > a any parallel nightly > test. > > > I attempted a bisect of the above range of commits - and > narrowed down to: > > > db11d4c4a70e39a28be88ed32f00542301699e08 is the first bad > commit > <<<<<<< > > > balay@asterix /home/balay/soft/build/mpich > ((db11d4c4a...)|BISECTING) > $ git show db11d4c4a70e39a28be88ed32f00542301699e08 > commit db11d4c4a70e39a28be88ed32f00542301699e08 (HEAD, > refs/bisect/bad) > Author: Ken Raffenetti <raffenet(a)mcs.anl.gov > <mailto:[email protected]>> > Date: Thu Feb 15 11:37:59 2018 -0600 > > init: Fix tag upper limit initialization > The starting point for this value is equivalent > to the usable tag bits > macro. This value should be set before device > initialization, > otherwise devices will assume they have more bits > than are actually > available. > Signed-off-by: Wesley Bland > <wesley.bland(a)intel.com <mailto:[email protected]>> > > diff --git a/src/mpi/init/initthread.c > b/src/mpi/init/initthread.c > index cbc41f4d5..b31ae2f07 100644 > --- a/src/mpi/init/initthread.c > +++ b/src/mpi/init/initthread.c > @@ -403,7 +403,7 @@ int MPIR_Init_thread(int *argc, char > ***argv, int required, int *provided) > MPIR_Process.attrs.host = MPI_PROC_NULL; > MPIR_Process.attrs.io <http://MPIR_Process.attrs.io> = > MPI_PROC_NULL; > MPIR_Process.attrs.lastusedcode = MPI_ERR_LASTCODE; > - MPIR_Process.attrs.tag_ub = 0; > + MPIR_Process.attrs.tag_ub = MPIR_TAG_USABLE_BITS; > MPIR_Process.attrs.universe = > MPIR_UNIVERSE_SIZE_NOT_SET; > MPIR_Process.attrs.wtime_is_global = 0; > @@ -531,13 +531,6 @@ int MPIR_Init_thread(int *argc, > char ***argv, int required, int *provided) > MPIR_Assert(((unsigned) MPIR_Process. > attrs.tag_ub & ((unsigned) > MPIR_Process.attrs.tag_ub + 1)) == 0); > - /* Set aside tag space for tagged collectives and > failure notification */ > -#ifdef HAVE_TAG_ERROR_BITS > - MPIR_Process.attrs.tag_ub >>= 3; > -#else > - MPIR_Process.attrs.tag_ub >>= 1; > -#endif > - > /* Assert: tag_ub is at least the minimum asked for > in the MPI spec */ > MPIR_Assert(MPIR_Process.attrs.tag_ub >= 32767); > <<<<<<<<<<<<<<<<< > > Reverthing this patch gets mpich-3.3b2 working with petsc > > Satish > > >

1 0

Re: [petsc-dev] Figures 20, 21 in Chapter 13.1 of PETSc manual are out of date
by Junchao Zhang 19 Apr '18

19 Apr '18

Hi, Patrick, It is great if you can update it. I am still learning PETSc and the manual. BTW, I found ex10.c contains out-of-date comments, which were there for the profiling manual, but the code diverged from the comments. Maybe you can create a new test for the manual and add comments saying the test is for the manual so that one will not accidentally overwrite it. --Junchao Zhang On Thu, Apr 19, 2018 at 1:01 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > Sorry I didn't catch this when cleaning up the manual recently. If you > don't have time to update it yourself, let me know and I will. > > 2018-04-19 5:23 GMT+02:00 Karl Rupp <rupp(a)iue.tuwien.ac.at>: > >> Hi Junchao, >> >> 1) The manual says the example is src/ksp/ksp/examples/ex10.c, but it >>> actually links to src/ksp/ksp/examples/tutorial/ex10.c. This is a minor >>> issue. >>> 2) One could not use the same command line options (-f0 medium -f1 >>> arco6) as shown in the figures. There are no such matrices so one can't >>> simply copy & paste. >>> 3) It seems ex10.c had gone through large changes and it can not produce >>> a log summary similar to the figures anymore (e.g., no stages like "Event >>> Stage 4: KSPSetUp 1" ). >>> >> >> such things (unfortunately) tend to happen over time. Please feel free to >> fix it :-) >> >> Best regards, >> Karli >> > >

1 0

Re: [petsc-dev] Is mpich/master:a8a2b30fd21 tested with Petsc?
by Eric Chamberland 19 Apr '18

19 Apr '18

Hi, this morning, mpich/master with PETSc is 100% working again for us. Thanks to both commits: https://github.com/pmodels/mpich/commit/c597c8d79deea220a42751fda0f01ce7076… https://github.com/pmodels/mpich/commit/8edabc7373b82dd660019e53d2461317658… and thanks to everybody who helped: Satish Min Wesley Ken Rob Jed :) Eric On 17/04/18 04:58 PM, Min Si wrote: > Hi all, > > Thanks for narrowing down the problem. I checked the MPICH code and > believe this is a bug in MPICH. I just created a PR to fix it: > https://github.com/pmodels/mpich/pull/3097 > > It should be merged into MPICH master branch soon. > > Thanks, > Min > > On 2018/04/17 14:10, Eric Chamberland wrote: >> Hi, >> >> are we talking about the "tag" passed to MPI_Isend for example? >> >> but does that mean there is something to change for any MPI call which >> involves tags usage or is it only a PETSc "bad" tag usage? >> >> thanks Satish for your finding! >> >> Eric >> >> On 16/04/18 11:31 PM, Satish Balay wrote: >>> On Tue, 13 Mar 2018, Eric Chamberland wrote: >>> >>>> Hi, >>>> >>>> each night we are testing mpich/master with our petsc-based code. I >>>> don't >>>> know if PETSc team is doing the same thing with mpich/master? (Maybe >>>> it is a >>>> good idea?) >>>> >>>> Everything was fine (except the issue >>>> https://github.com/pmodels/mpich/issues/2892) up to commit >>>> 7b8d64debd, but >>>> since commit mpich:a8a2b30fd21), I have a segfault on a any parallel >>>> nightly >>>> test. >>> >>> I attempted a bisect of the above range of commits - and narrowed >>> down to: >>> >>>>>>>>>> >>> db11d4c4a70e39a28be88ed32f00542301699e08 is the first bad commit >>> <<<<<<< >>>>>>>>>>> >>> balay@asterix /home/balay/soft/build/mpich ((db11d4c4a...)|BISECTING) >>> $ git show db11d4c4a70e39a28be88ed32f00542301699e08 >>> commit db11d4c4a70e39a28be88ed32f00542301699e08 (HEAD, refs/bisect/bad) >>> Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> >>> Date: Thu Feb 15 11:37:59 2018 -0600 >>> >>> init: Fix tag upper limit initialization >>> The starting point for this value is equivalent to the >>> usable tag bits >>> macro. This value should be set before device initialization, >>> otherwise devices will assume they have more bits than are actually >>> available. >>> Signed-off-by: Wesley Bland <wesley.bland(a)intel.com> >>> >>> diff --git a/src/mpi/init/initthread.c b/src/mpi/init/initthread.c >>> index cbc41f4d5..b31ae2f07 100644 >>> --- a/src/mpi/init/initthread.c >>> +++ b/src/mpi/init/initthread.c >>> @@ -403,7 +403,7 @@ int MPIR_Init_thread(int *argc, char ***argv, int >>> required, int *provided) >>> MPIR_Process.attrs.host = MPI_PROC_NULL; >>> MPIR_Process.attrs.io = MPI_PROC_NULL; >>> MPIR_Process.attrs.lastusedcode = MPI_ERR_LASTCODE; >>> - MPIR_Process.attrs.tag_ub = 0; >>> + MPIR_Process.attrs.tag_ub = MPIR_TAG_USABLE_BITS; >>> MPIR_Process.attrs.universe = MPIR_UNIVERSE_SIZE_NOT_SET; >>> MPIR_Process.attrs.wtime_is_global = 0; >>> @@ -531,13 +531,6 @@ int MPIR_Init_thread(int *argc, char ***argv, >>> int required, int *provided) >>> MPIR_Assert(((unsigned) MPIR_Process. >>> attrs.tag_ub & ((unsigned) >>> MPIR_Process.attrs.tag_ub + 1)) == 0); >>> - /* Set aside tag space for tagged collectives and failure >>> notification */ >>> -#ifdef HAVE_TAG_ERROR_BITS >>> - MPIR_Process.attrs.tag_ub >>= 3; >>> -#else >>> - MPIR_Process.attrs.tag_ub >>= 1; >>> -#endif >>> - >>> /* Assert: tag_ub is at least the minimum asked for in the MPI >>> spec */ >>> MPIR_Assert(MPIR_Process.attrs.tag_ub >= 32767); >>> <<<<<<<<<<<<<<<<< >>> >>> Reverthing this patch gets mpich-3.3b2 working with petsc >>> >>> Satish >>>

1 0

Re: [petsc-dev] MatCreateSubmatrices causes invalid memory write access in fortran
by Tim Steinhoff 19 Apr '18

19 Apr '18

Hong, we are fine with that. Thanks! Volker 2018-04-18 17:32 GMT+02:00 Hong <hzhang(a)mcs.anl.gov>: > Tim : >> >> Hi all, >> >> with PETSc v3.9 there seems to be a out of bounds write in the fortran >> interface of MatCreateSubmatrices. >> >> https://bitbucket.org/petsc/petsc/src/59479656cffe26dd9a9d446f6d00dfe5e3168… >> >> The reference mentions that in fortran one should pass a preallocated >> array for submat with at least the size of m (actually it's probably a >> typo and should be n) >> >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateSu… >> >> Then n+1 entries are copied into that array, where the last entry >> seems to be some unneeded dummy (as mentioned). >> for (i=0; i<=*n; i++) { /* lsmat[*n] might be a dummy matrix for >> saving data struc */ >> smat[i] = lsmat[i]; >> } >> This leads to some bad errors afterwards, when that array is only of >> the size of n as recommended. > > > We need this extra space for reuse -- I agree it makes Fortran API odd. > > I made following fix to the help manual: > diff --git a/src/mat/interface/matrix.c b/src/mat/interface/matrix.c > > When finished using the submatrices, the user should destroy > - them with MatDestroyMatrices(). > + them with MatDestroySubMatrices(). > > Fortran Note: > The Fortran interface is slightly different from that given below; it > - requires one to pass in as submat a Mat (integer) array of size at > least m. > + requires one to pass in as submat a Mat (integer) array of size at > least n+1. > > If you agree, I'll push it to the petsc released version. > > Hong >

1 0

Re: [petsc-dev] Figures 20, 21 in Chapter 13.1 of PETSc manual are out of date
by Patrick Sanan 19 Apr '18

19 Apr '18

Sorry I didn't catch this when cleaning up the manual recently. If you don't have time to update it yourself, let me know and I will. 2018-04-19 5:23 GMT+02:00 Karl Rupp <rupp(a)iue.tuwien.ac.at>: > Hi Junchao, > > 1) The manual says the example is src/ksp/ksp/examples/ex10.c, but it >> actually links to src/ksp/ksp/examples/tutorial/ex10.c. This is a minor >> issue. >> 2) One could not use the same command line options (-f0 medium -f1 arco6) >> as shown in the figures. There are no such matrices so one can't simply >> copy & paste. >> 3) It seems ex10.c had gone through large changes and it can not produce >> a log summary similar to the figures anymore (e.g., no stages like "Event >> Stage 4: KSPSetUp 1" ). >> > > such things (unfortunately) tend to happen over time. Please feel free to > fix it :-) > > Best regards, > Karli >

1 0

Re: [petsc-dev] vector inner products
by Oxberry, Geoffrey Malcolm 18 Apr '18

18 Apr '18

> On Apr 18, 2018, at 15:06, Munson, Todd <tmunson(a)mcs.anl.gov> wrote: > > > In the master branch, setting a H0 matrix and the gradient norm appear to be > correct only for the quasi-Newton code. Those notions have not been > propagated anywhere else. Yes, that’s my understanding as well. > > The quasi-Newton approximation, for example, can be used as a preconditioner > in the Newton methods. If the H0 matrix is set and it uses a KSP solver to > apply the "inverse", then do we need to add flexible variants of NASH, > STCG, and GLTR for correctness? Yes, or disallow quasi-Newton preconditioning for non-identity H0 matrices for these methods. > > The H0 also need to be symmetric or act like a symmetric operator for the > quasi-Newton approximation to be reasonable, and certainly when it is > used as a preconditioner in NASH, STCG, and GLTR. Does this restrict > the KSP solvers that can be applied when we need a inv(H0)*vector > product? I don’t see why it would restrict you to methods for symmetric operators. > > At the end go the day, the question becomes how much thought and effort do > we want to spend in order to support the H0 matrix? Or do we want to > leave this as supported only for the TAO quasi-Newton method? I think that’s up to you and the TAO developers. It’s helpful for mesh-independent convergence — it corresponds to a natural preconditioner — but if that feature isn’t critical for you guys in terms of funding or customers, I understand not implementing it. The abstraction also makes sensible the idea of mesh refinement or coarsening during the optimization algorithm because these operations correspond to mapping between different subsets of the same Hilbert space, and should be endowed with the same norms and inner products. These operations don’t really make sense if the decision variables are an n-tuple of reals with no additional structure. Geoff > > Todd. > >> On Apr 13, 2018, at 9:11 PM, Oxberry, Geoffrey Malcolm <oxberry1(a)llnl.gov> wrote: >> >> >> >> On 4/12/18, 15:06, "petsc-dev on behalf of Munson, Todd" <petsc-dev-bounces(a)mcs.anl.gov on behalf of tmunson(a)mcs.anl.gov> wrote: >> >> >> I am not looking at Geoff's pull request right now. >> >> Let me try to be clearer, in the master branch, the TaoGradientNorm() function is only >> used for termination tests inside the optimization methods. It does not change anything >> else that goes on inside of the methods. >> >> Gradients and Hessians also depend on duality pairings, which in turn affects how users write these quantities, and how Hessians are approximated in quasi-Newton methods. Related code for the Hilbert space case was included in PR#347 (h/t Patrick Farrell). >> >> A user-defined convergence test (presuming we >> can get the callbacks right) would suffice. As all norms are equivalent in finite >> dimensions, a user could also scale the standard termination tolerance by >> the correct constant. >> >> This decision makes tolerances discretization-dependent, which is a leaky abstraction, and an unnatural way to encode algorithm convergence criteria. Scaling the $\ell_{2}$-norm in place of using the correct primal and dual norms also ignores the metric geometry of the primal and dual spaces, and will affect algorithm convergence negatively. A callback for a user-defined convergence test would be preferable. >> >> If you need to live in function spaces, which seems to be the argument, then it seems >> that PETSc needs to be changed by more than just a single termination test. >> >> A similar discussion can be found in the discussion of PR#347. >> >> Thanks, >> Todd. >> >>> On Apr 12, 2018, at 3:27 PM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: >>> >>> The gradient norm is the one induced by the mass matrix of the DM associated with the control. >>> In principle, TaoGradientNorm() can be replaced by DMCreateMassMatrix() + solve with the mass matrix. >>> >>> For PDE constrained optimization, the “gradient norm” is crucial, since we consider optimization problems in Banach spaces. >>> We should keep supporting it, maybe differently than as it is now, but keep it. >>> >>>> On Apr 12, 2018, at 11:21 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>> >>>> Are you thinking about this PR again? >>>> >>>> https://bitbucket.org/petsc/petsc/pull-requests/506 >>>> >>>> There's an issue here that Krylov methods operate in the discrete inner >>>> product while some higher level operations are of interest in >>>> (approximations of) continuous inner products (or norms). The object in >>>> PETSc that endows continuous attributes (like a hierarchy, subdomains, >>>> fields) on discrete quantities is DM, so my first inclination is that >>>> any continuous interpretation of vectors, including inner products and >>>> norms, belongs in DM. >>>> >>>> "Munson, Todd" <tmunson(a)mcs.anl.gov> writes: >>>> >>>>> There is a bit of code in TAO that allows the user to change the norm to >>>>> a matrix norm. This was introduced to get some mesh independent >>>>> behavior in one example (tao/examples/tutorials/ex3.c). That >>>>> norm, however, does not propagate down into the KSP methods >>>>> and is only used for testing convergence of the nonlinear >>>>> problem. >>>>> >>>>> A few questions then: Is similar functionality needed in SNES? Are >>>>> TAO and SNES even the right place for this functionality? Should >>>>> it belong to the Vector class so that you can change the inner >>>>> products and have all the KSP methods (hopefully) work >>>>> correctly? >>>>> >>>>> Note: that this discussion brings us to the brink of supporting an >>>>> optimize-then-discretize approach. I am not convinced we should >>>>> go down that rabbit hole. >>>>> >>>>> Thanks, Todd. >>> >> >> >

1 0

Re: [petsc-dev] Figures 20, 21 in Chapter 13.1 of PETSc manual are out of date
by Karl Rupp 18 Apr '18

18 Apr '18

Hi Junchao, > 1) The manual says the example is src/ksp/ksp/examples/ex10.c, but it > actually links to src/ksp/ksp/examples/tutorial/ex10.c. This is a minor > issue. > 2) One could not use the same command line options (-f0 medium -f1 > arco6) as shown in the figures. There are no such matrices so one can't > simply copy & paste. > 3) It seems ex10.c had gone through large changes and it can not produce > a log summary similar to the figures anymore (e.g., no stages like > "Event Stage 4: KSPSetUp 1" ). such things (unfortunately) tend to happen over time. Please feel free to fix it :-) Best regards, Karli

1 0

Re: [petsc-dev] vector inner products
by Munson, Todd 18 Apr '18

18 Apr '18

In the master branch, setting a H0 matrix and the gradient norm appear to be correct only for the quasi-Newton code. Those notions have not been propagated anywhere else. The quasi-Newton approximation, for example, can be used as a preconditioner in the Newton methods. If the H0 matrix is set and it uses a KSP solver to apply the "inverse", then do we need to add flexible variants of NASH, STCG, and GLTR for correctness? The H0 also need to be symmetric or act like a symmetric operator for the quasi-Newton approximation to be reasonable, and certainly when it is used as a preconditioner in NASH, STCG, and GLTR. Does this restrict the KSP solvers that can be applied when we need a inv(H0)*vector product? At the end go the day, the question becomes how much thought and effort do we want to spend in order to support the H0 matrix? Or do we want to leave this as supported only for the TAO quasi-Newton method? Todd. > On Apr 13, 2018, at 9:11 PM, Oxberry, Geoffrey Malcolm <oxberry1(a)llnl.gov> wrote: > > > > On 4/12/18, 15:06, "petsc-dev on behalf of Munson, Todd" <petsc-dev-bounces(a)mcs.anl.gov on behalf of tmunson(a)mcs.anl.gov> wrote: > > > I am not looking at Geoff's pull request right now. > > Let me try to be clearer, in the master branch, the TaoGradientNorm() function is only > used for termination tests inside the optimization methods. It does not change anything > else that goes on inside of the methods. > > Gradients and Hessians also depend on duality pairings, which in turn affects how users write these quantities, and how Hessians are approximated in quasi-Newton methods. Related code for the Hilbert space case was included in PR#347 (h/t Patrick Farrell). > > A user-defined convergence test (presuming we > can get the callbacks right) would suffice. As all norms are equivalent in finite > dimensions, a user could also scale the standard termination tolerance by > the correct constant. > > This decision makes tolerances discretization-dependent, which is a leaky abstraction, and an unnatural way to encode algorithm convergence criteria. Scaling the $\ell_{2}$-norm in place of using the correct primal and dual norms also ignores the metric geometry of the primal and dual spaces, and will affect algorithm convergence negatively. A callback for a user-defined convergence test would be preferable. > > If you need to live in function spaces, which seems to be the argument, then it seems > that PETSc needs to be changed by more than just a single termination test. > > A similar discussion can be found in the discussion of PR#347. > > Thanks, > Todd. > >> On Apr 12, 2018, at 3:27 PM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: >> >> The gradient norm is the one induced by the mass matrix of the DM associated with the control. >> In principle, TaoGradientNorm() can be replaced by DMCreateMassMatrix() + solve with the mass matrix. >> >> For PDE constrained optimization, the “gradient norm” is crucial, since we consider optimization problems in Banach spaces. >> We should keep supporting it, maybe differently than as it is now, but keep it. >> >>> On Apr 12, 2018, at 11:21 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> >>> Are you thinking about this PR again? >>> >>> https://bitbucket.org/petsc/petsc/pull-requests/506 >>> >>> There's an issue here that Krylov methods operate in the discrete inner >>> product while some higher level operations are of interest in >>> (approximations of) continuous inner products (or norms). The object in >>> PETSc that endows continuous attributes (like a hierarchy, subdomains, >>> fields) on discrete quantities is DM, so my first inclination is that >>> any continuous interpretation of vectors, including inner products and >>> norms, belongs in DM. >>> >>> "Munson, Todd" <tmunson(a)mcs.anl.gov> writes: >>> >>>> There is a bit of code in TAO that allows the user to change the norm to >>>> a matrix norm. This was introduced to get some mesh independent >>>> behavior in one example (tao/examples/tutorials/ex3.c). That >>>> norm, however, does not propagate down into the KSP methods >>>> and is only used for testing convergence of the nonlinear >>>> problem. >>>> >>>> A few questions then: Is similar functionality needed in SNES? Are >>>> TAO and SNES even the right place for this functionality? Should >>>> it belong to the Vector class so that you can change the inner >>>> products and have all the KSP methods (hopefully) work >>>> correctly? >>>> >>>> Note: that this discussion brings us to the brink of supporting an >>>> optimize-then-discretize approach. I am not convinced we should >>>> go down that rabbit hole. >>>> >>>> Thanks, Todd. >> > >

1 0

Figures 20, 21 in Chapter 13.1 of PETSc manual are out of date
by Junchao Zhang 18 Apr '18

18 Apr '18

1) The manual says the example is src/ksp/ksp/examples/ex10.c, but it actually links to src/ksp/ksp/examples/tutorial/ex10.c. This is a minor issue. 2) One could not use the same command line options (-f0 medium -f1 arco6) as shown in the figures. There are no such matrices so one can't simply copy & paste. 3) It seems ex10.c had gone through large changes and it can not produce a log summary similar to the figures anymore (e.g., no stages like "Event Stage 4: KSPSetUp 1" ). --Junchao Zhang

1 0