On Mon, Nov 14, 2011 at 06:32, David Knezevic <[email protected]>wrote:
> Would I have to use the raw PETSc MatCopy() though? I don't see a > libMesh wrapper for it, and using SparseMatrix's operator= gives a > memory leak... > It seems to me that this should be fixed. But in any case, it does not call MatCopy(), so it's not a complete solution (and I find it easy to get confused when overloading = to produce a new object or to copy into an existing object; they have very different semantics if anyone holds a reference to the original). > this is why I was doing the "zero" then "add" (which is > presumably horribly inefficient, but at least it's not PETSc-specific...) > Well, the problem has everything to do with preallocation and not marking new matrices "assembled". We _could_ make MatZeroEntries() mark the matrix as assembled, but that would be confusing for users who forget to assemble (e.g. accidentally assemble into the wrong matrix, or when trying to run the code before everything is implemented). We could add another special state to be reached after MatZeroEntries(), but that makes the implementation more complicated and offers more chance of bugs. Could you add a copy method to SparseMatrix or otherwise find a way to get the matrix assembled? (If necessary, you could just call matrix_B->close(). When I add that line, the example makes it further and errors that the eigensolver did not converge.) ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
