On Wed, Oct 12, 2016 at 5:04 PM, Roy Stogner <royst...@ices.utexas.edu>

> 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_no
> de_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.

I just tried my real problem with your PR and it's still not working,
unfortunately. I'll have to look into that in more detail. I'll get back to
you when I have more info.

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

Reply via email to