I'm not sure what to do with:

PetscErrorCode  PCMGSetResidual(PC pc,PetscInt l,PetscErrorCode 
(*residual)(Mat,Vec,Vec,Vec),Mat mat) ?

I'm thinking to have this in the code:

  mglevels[l]->A = mat;
  mglevels[l]->residual = residual;

and change the calls from using PCMGResidualDefault to using 
MatResidualDefault.  This will keep from breaking code that uses this to set 
the Mat also.  And should this be called PCMGSetResidualAndMat?

Mark

On Sep 9, 2013, at 9:25 PM, Barry Smith <[email protected]> wrote:

> 
> On Sep 9, 2013, at 8:03 PM, "Mark F. Adams" <[email protected]> wrote:
> 
>> OK, so its ground hog day.  The plan?:
>> 
>> 1) I should add a residual method to Mat, make a MatResidualDefault, and 
>> have all (yuck) SetUp_MatXXX set this default.  I guess there is no base 
>> class SetUp ….  then make a MatResidual_SeqAIJ that just does a dumb 
>> residual for now, with testing logic if Jed's stuff is available.
> 
>   Take a look at MatCreate_SeqAIJ. These fill up all the function points in 
> one swoop with the big function table, this is why there is not "base class 
> setup".
> 
>> 
>> 2) Have PCMGResidualDefault call MatResidual instead MatMult & VecAYPX.  Or 
>> do we want to nuke PCMGResidualDefault?
> 
>   You don't really need PCMGResidualDefault, just make the residual function 
> pointer in PCMG point to MatResidual
> 
>> Jed's defect correction argument might sound like a typical Jed, e.g., what 
>> if a Martian gets hepatitis during mardi gras, but defect correction is 
>> really useful and I would like to see its support supported …
> 
>   Don't need it to support defect correction  but anyways :-)
> 
>> 
>> 3) Add fields in Mat: mat_res_state, vec_res_state, vec_res_id.  I need to 
>> know the types but I can do this in the next phase.
> 
>   Look in _p_PetscObject for the types of state and id, both currently 
> PetscInt.
> 
>> 
> 
>> Mark
>> 
>> On Sep 9, 2013, at 5:35 PM, Barry Smith <[email protected]> wrote:
>> 
>>> 
>>> On Sep 9, 2013, at 4:32 PM, Jed Brown <[email protected]> wrote:
>>> 
>>>> Barry Smith <[email protected]> writes:
>>>>> I don't care if PCMGSetResidual stays around for now but I do not
>>>>> think we should "point to it" as a standard way for people to do
>>>>> things; I think we should improve how the two slots are used with
>>>>> PCMG, it really has never been thought about at all and whenever
>>>>> possible I think using the two slots appropriately is better than
>>>>> PCMGSetResidual and will solve most of the "use" cases.
>>>> 
>>>> Fine, I was just not eager to _delete_ PCMGSetResidual until we had
>>>> established a complete replacement, and even then, it might be enough to
>>>> leave it as "advanced" and suggest the preferred alternative in the man
>>>> page.  It just doesn't seem expensive to support and I don't think it
>>>> causes people to tangle themselves up in bad design.
>>> 
>>> It doesn't have its own object which is kind of limiting.
>>> 
>>> 
>>> 
>> 
> 

Reply via email to