On Nov 26, 2010, at 12:29 PM, Jed Brown wrote: > On Fri, Nov 26, 2010 at 01:29, Barry Smith <bsmith at mcs.anl.gov> wrote: > The easiest fix would be to put MatPreallocated() at the beginning of > MatGetSizes() and whatever else doesn't have it. I don't know if there would > be any bad side affects to making this change. > > The problem is that MatGetSize() is not collective. > > Is it really necessary to have preallocation be the same as knowing the sizes?
No, they can be done at different stages. It is just a question of how many "setup" stages we want to have, it looks like we are heading for more and more. > What I didn't notice is that, while there is still ops->setsizes, none of > the implementations use it any more. I thought the idea was that MatCreate_X > would set up the layout if the sizes had been set, otherwise it would drop > its callback into ops->setsizes, and set up the layout when the user > subsequently called MatSetSizes I think this model would work. > (where this dispatch logic still is). But note the code then overwrites the sizes A->rmap->n = m; A->cmap->n = n; A->rmap->N = M; A->cmap->N = N; which is wrong. > I didn't realize/remember that it was actually MatCreate_X that was > registered in the callback. That of course causes trouble because you > MatSetType(A,MATAIJ) and then calls to MATSeqAIJXXX are ignored. > > I know it is some added implementation complexity, but how about calling > MatCreate_X directly in MatSetType, It is currently called at that time. > and have an independent ops->setsizes which will set up the layout? Yes, I had squeezed it into the preallocated check because I was trying to avoid too many stages of "setup" but I think we have no choice but to introduce this one more stage. Barry > > Jed
