[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