[petsc-dev] error on preallocation business

[Barry Smith]

  I'm afraid adding this "default to error if preallocate not right" that started this whole thread has lead to an enormous can of worms we've only begun to open. Tons of examples don't work in the tests

  Crap, crap, crap. Ok let's try your "ugly" fix with the realrealloc stuff and see how it goes. So don't revert it.

   Barry



On Jan 21, 2012, at 3:15 PM, Jed Brown wrote:

> 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.
>