[petsc-dev] composite vs. shell
Pierre Jolivet
pierre.jolivet at enseeiht.fr
Sat Nov 25 07:55:41 CST 2017
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. <bsmith at mcs.anl.gov> 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 <jed at jedbrown.org> wrote:
>>
>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>
>>>> On Nov 9, 2017, at 11:13 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>
>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> 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.
>
More information about the petsc-dev
mailing list