On Thu, Apr 22, 2010 at 9:22 AM, Jed Brown <jed at 59a2.org> wrote: > On Thu, 22 Apr 2010 15:15:12 +0100, "Parker, Andrew (UK Filton)" < > Andrew.Parker2 at baesystems.com> wrote: > > Well that's a worry, no error from: > > MatSetOption(_storage,MAT_NEW_NONZERO_ALLOCATION_ERR,PETSC_TRUE); > > > > Still slow as hell, same behaviour as before. I'm now using: > > > > MatCreate(PETSC_COMM_SELF,&_storage); > > MatSetType(_storage, MATSEQBAIJ); > > MatSetOption(_storage,MAT_NEW_NONZERO_ALLOCATION_ERR,PETSC_TRUE); > > > > MatSetSizes(_storage,PETSC_DECIDE,PETSC_DECIDE,numVars*numLocs,numVars*n > > umLocs); > > MatSetFromOptions(_storage); > > MatSeqBAIJSetPreallocation(_storage,numVars,PETSC_NULL,sparsityStart); >
Then there is something wrong in your code at large that we cannot see from this small snippet. Can you change a PETSc example into something that exhibits this behavior, like KSP ex2? Also, you can go in with the debugger and see what is happening. I am guessing you switch the matrix you are using (so options do not take effect), or recreate it, etc. Matt > This should work if you call both MatSetSizes and MatSetType before > MatSetOption. There are technical reasons for this, mostly that it's > difficult to cache all the options and get them handled in a consistent > and debuggable manner once the implementation is chosen. > > Unless someone disagrees, I'll make it an error to call MatSetOptions() > before the implementation is available (so you would get a useful error > with the usage above, instead of the option just being ignored). > > Jed > -- 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-users/attachments/20100422/f39cddca/attachment.htm>
