[petsc-dev] error on preallocation business

Jed Brown jedbrown at mcs.anl.gov
Sat Jan 21 15:15:40 CST 2012


On Sat, Jan 21, 2012 at 15:05, Barry Smith <bsmith at mcs.anl.gov> wrote:

>  The disassemble routines (in fact any PETSc library routines that call
> the preallocation routines) should ONLY call them if they are using correct
> values of preallocation otherwise they should not call them. So we should
> fix or remove all those bad uses of preallocation (preferably fix).  If you
> have the list of the ones that call with incorrect preallocation let us
> know.
>

This sounds like a fairly major architectural change to the DisAssemble_*
routines. I'm inclined to leave in the shuttling of the "nonew" option in
these routines.


> >
> > 2. Users call preallocation directly (often through MatCreateMPIAIJ(),
> etc) with PETSC_DECIDE. In my opinion, they should see an error for not
> preallocating correctly. (But if you think they should have to say twice
> that they aren't preallocating correctly---by calling MatSetOption(), I can
> remove that uglyness.)
>
>    I don't understand. With my model if they call MatCreateMPIAIJ() or
> MatMPIAIJSetPreallocation() it WILL set that flag and hence WILL bitch if
> they have used wrong values (even if they use PETSC_DECIDE. So it will do
> the right thing with my little fix; tell me why it won't.  Note if any of
> the preallocation routines are called it will not reset the flag in
> MatSetUpPreallocation().
>

Okay, so if they say that they don't know how to allocate by passing
PETSC_DECIDE, you want it to still error when preallocation is incorrect?
That lets me get rid of the "realalloc" crap I just added, great.

It does mean that lots of calls to MatSetOption() will need to be added.


>
> >
> > 3. I didn't want to overwrite a user setting the option manually
> (perhaps with intent to preallocate).
>
>         I already acknowledged this in my previous email. To me the
> tradeoff is monsterous code that Matt would hate vs this
>
>    In conclusion I think only 3 has any validity and that not enough for
> butt-ugly code.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120121/04c16d1e/attachment.html>


More information about the petsc-dev mailing list