Re: [Libmesh-users] ex29 and ex30 run time errors

[David K. <dkn...@se...>]

On 11/14/2011 08:35 AM, Jed Brown wrote:
> On Mon, Nov 14, 2011 at 06:32, David Knezevic 
> <dkn...@se... <mailto:dkn...@se...>> 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.)

OK, I've just checked in the matrix_B->close() change for now. I've also 
changed to -eps_type lapack (as in ex17) to avoid slepc convergence 
issues. Let me know if that works for you?

David