On Tue, 20 Jan 2009, Tim Kroeger wrote: >> I'm not sure how thoroughly the non-default options have been tested; >> let us know if there seem to be any problems. > > Well, there is a problem. That is, it doesn't work. The attached test > application hangs up in the second refinement step. (It runs perfectly if > the edge_level_mismatch_limit() line is removed.)
Ah, yes. Instead of "how thoroughly", I probably should have said "if". IIRC I once had to rewrite face_level_mismatch_limit() to work with ParallelMesh, and I figured I'd throw in an option for edge_level_mismatch_limit() in case anyone ever wanted to use it. You must be the first, because it's been broken from the start. I've just committed a fix to SVN if you want to give it a try. Speaking of broken code, though, could you try ex20 with your PetscVector patch? It seems to be breaking for me on the from-Vec constructor, which appears to assume that all parallel vectors have ghost mappings. While that's the eventual goal for all parallel petsc vectors created by the library, I'd like to keep the current less-efficient vectors working too, to support user-created vectors using the old API and to make testing easier as we switch to the new vectors. I can fix the copy constructor easily enough, but if there's any other places you might have made the same assumption (or if you can't replicate the problem or if you think I've misdiagnosed it), let me know. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
