Menu
▾
▴
Re: [Libmesh-users] [Libmesh-devel] Sparsity patterns and post-facto matrices
|
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-08-21 17:42:15
|
I'm glad Derek suggested this - it was my preferred approach too! -Ben On Aug 21, 2012, at 5:55 AM, "Derek Gaston" <fri...@gm...<mailto:fri...@gm...>> 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 <roy...@ic...<mailto:roy...@ic...>> 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 Lib...@li...<mailto:Lib...@li...> 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 Lib...@li...<mailto:Lib...@li...> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |