On Sat, Jan 21, 2012 at 8:44 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Sat, Jan 21, 2012 at 20:37, Barry Smith <bsmith at mcs.anl.gov> wrote: > >> We cannot have MatPreallocated() inside MatSetValues() because >> MatSetValues() is not collective but MatPreallocated() -> >> MatSetUpPreallocation() -> MatMPIAIJSetPreallocation() is collective. >> >> Likely this bug has been around a long time but Jed's changes to >> preallocation business has exposed it. >> > > At has been there since the beginning of time (revision 0). > > >> >> How to fix? >> >> 1) Error out if non preallocated matrix sent to MatSetValues()? >> Yuck? Cause this means user must then always call MatPreallocated() or >> MatSetUp() before ever using it. >> MatCreate() >> MatSetSizes() >> MatSetType() >> MatSetUp() or MatXXXSetPreallocation() or >> MatSetUpPreallocation() >> use >> > > Unfortunately, I think this is the only viable choice. > > >> >> 2) Pray every one always calls MatSetValues() on each process if >> not preallocating and make sure internally we never screw up. Yuck. >> > > I fear that this causes deadlock only when someone strong scales the job > up to where they get an empty process. That is the kind of bug that is hard > to find and can burn too many cycles to risk. > I think we should try to draw out the complete state machine for Mat. This of-the-cuff reasoning obviously does not work when things get complicated. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120122/8b524b5b/attachment.html>
