Thank you Barry. I made the appropriate changes in my code but it’s good to know about the new behaviour.
Thanks, Pierre > On 25 Nov 2017, at 2:34 PM, Smith, Barry F. <[email protected]> wrote: > > > Pierre, > > https://bitbucket.org/petsc/petsc/pull-requests/809/only-propagate-operators-into-inner-pcs-in/diff > > Sorry for the long delay in responding. > > Barry > > >> On Nov 10, 2017, at 1:36 PM, Jed Brown <[email protected]> wrote: >> >> "Smith, Barry F." <[email protected]> writes: >> >>>> On Nov 9, 2017, at 11:13 PM, Jed Brown <[email protected]> wrote: >>>> >>>> "Smith, Barry F." <[email protected]> writes: >>>> >>>>> Jed, >>>>> >>>>> Please articulate in a bit more detail. From what I can interpolate you >>>>> are saying >>>>> >>>>> 1) that if we only propagate the outer matrices to inner matrices that >>>>> the user has not set we will get a better more intuitive interface for >>>>> users >>>>> >>>>> but >>>>> >>>>> 2) the whole idea of propagating in is probably flawed. >>>> >>>> The idea of having only two matrices, Amat and Pmat, is flawed. >>> >>> Yes >>> >>>> A >>>> composite preconditioner, for example, may need more. Having users >>>> unwrap solvers to manually set matrices is ugly, but in lieu of a better >>>> way (like named auxiliary matrices that can be requested by nested >>>> preconditioners), we should honor the user's manual choices. >>> >>> Yes. >>> >>> But you are not directly answering my question. Should we change >>> the code to not propagate if already set? >> >> Yes, I think so. That is what I meant by "we should honor the user's >> manual choices" above. >
