On Sun, 9 Oct 2016, David Knezevic wrote: > I've attached a modified version of misc_ex9 that attaches > constraints on one side of the "crack" and checks if the dof > constraints are present during assembly. This passes in serial but > fails in parallel because constraints are not communicated on the > GhostingFunctor-coupled-dofs.
I had to make a couple fixes to the test: switching mesh_1 and mesh_2 to SerialMesh, and using dof_id_type neighbor_node_id = neighbor->node_ref(neighbor_node_index).dof_number(0,0,0); to handle the case where node id isn't node dof id. > The extra constraints I added mean that the problem doesn't make > physical sense anymore unfortunately, but at least it tests for the > constraint issue. Roy: I'm not sure if this is appropriate for a > unit test, but it should at least be helpful for when you want to > check your implementation. It was, thanks! Here's hoping #1120 fixes the real problem too. The modified ex9 is too big for a unit test, and too contrived for an example, and I can't think of any easy way to fix that while maintaining the same level of test coverage. But if you can come up with anything that doesn't have both those problems I'd really love to get this case into continuous integration. If you can't come up with anything either... I suppose I could combine an extra-ghost-layers test case with a Dirichlet boundary and test a wide stencil? That should hit the same code paths. Plus, it's about time libMesh expanded into the cutting edge world of finite difference methods. --- Roy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
