I'm glad Derek suggested this - it was my preferred approach too!

-Ben



On Aug 21, 2012, at 5:55 AM, "Derek Gaston" <friedmud@gmail.com> wrote:

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 <roystgnr@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