I had an IM conversation with John yesterday that probably ought to be public/archived:
Roy: For the ex0/ex14 errors - is it possible we're not communicating the dof indices data when we're passing elements/nodes from proc to proc? Roy: MeshCommunication::redistribute() seems to pack nodes' and elements' higher-level data but not the dof_indices. John: yeah, does distribute_dofs do this? Roy: Which basically leaves us fubar'ed - distribute_dofs will calculate *different* indices because it'll be indexing based on the new processor ids, and it won't have anything to put in the old_dof_index Roy: Which then breaks the project_vector, even assuming we skip past that DEBUG-mode testing that's catching us now. Roy: I don't think there's any way around it except to communicate the indices. John: argh, I should have tested the new partitioning code with AMR in parallel... John: it seems like a lot of work still needs to be done Roy: I guess we disable repartitioning again for 0.7.1, and then when it's finally working that's a good excuse for calling the result 0.8.0 instead of 0.7.2. Since I'm being a jerk and publishing John's self-deprecation here I should also point out that it's undeserved. His mostly-fixed partitioning code even worked with distributed mesh refinement as long as the refinement was done pre-System-initialization. I'll probably be able to get redistribute() updated in a couple of weeks, but if anyone else wants to take a crack at it before then, just say the word. --- Roy ------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
