For now I'll vote for #2. One thing that you could add to #2 is a method
that we could call to clear/delete the sparsity pattern in the case where
we _know_ we won't need it again and we really do need the memory...
Derek
On Tue, Aug 21, 2012 at 9:49 AM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> We currently have a bug in the interaction between post-initialization
> sparse matrix creation (as used by our reduced_basis code and
> triggered by that ex5) and sparse matrix subclasses that need a full
> sparsity pattern to examine (i.e. Laspack and Trilinos). Currently,
> the DofMap creates a sparsity pattern upon initialization, hands it to
> all currently attached matrices to examine, examines the sparsity
> pattern itself, then discards it.
>
> So when new matrices are attached post-initialization, a full sparsity
> pattern is unavailable. This results in segfaults from LaspackMatrix.
>
> Possible solutions each have bad tradeoffs.
>
> 1. We could recompute the full sparsity pattern each time a new
> matrix requiring it is attached to an already-initialized DofMap.
> This would add redundant CPU cost to those cases, and it would require
> either a backwards-incompatible API change (DofMap::attach_matrix()
> would require a MeshBase reference so as to be able to compute a
> sparsity pattern on it if necessary) or a weakening of modularity
> (DofMap would have to "hang on" to an old MeshBase reference).
>
> 2. If our system matrix requires full sparsity pattern support, we
> could save the full sparsity pattern object after initialization, and
> supply it to any future matrices attached. This would add superfluous
> memory usage to most Laspack/Trilinos based user codes (those in which
> no matrices are attached post-initialization), and it would fail in
> any user codes which try to mix matrices from multiple solver packages
> in the same system.
>
> I'm leaning towards #2, on the theory that people who need
> reduced_basis-using codes to be as CPU-efficient as possible are more
> common than people who need Laspack/Trilinos-using codes to be
> memory-efficient.
>
> Does anyone else have preferences, or any other ideas?
> ---
> Roy
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
