On Feb 8, 2012, at 10:14 AM, Kirk, Benjamin (JSC-EG311) wrote: > The threading of the sparsity pattern is a bigger deal with amr when it is > done a lot, but in any case we could add a --single-threaded-sparsity or > something as an immediate stopgap.
No need to do that. Just don't call parallel_reduce. Just create the SparsityPattern::Build object and call it's operator() directly by passing in the range. That does the same thing but single threaded. This is how I "fixed" it last night. > And the hilbert indexing is used to derive a globally unique, partition > agnostic node number. But as you say it is not working out well? It is taking quite a while on these bigger jobs. I don't know if it's necessarily not working out or not. > It actually does the same thing with element centroids, which is I think > where you are based on the stack trace. What's the purpose here? > There could be an issue with not enough elements per processor... This one > could be boiled down to a stand-alone test by taking your mesh and calling > find_global_indices directly?? Possibly - but not right now. Just trying to get this stuff to go for now. Derek ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
