On Thu, Oct 6, 2016 at 10:34 PM, Roy Stogner <royst...@ices.utexas.edu>
wrote:
>
>
> On Thu, 6 Oct 2016, David Knezevic wrote:
>
> I'm using GhostingFunctor for a contact solve, in which I consider a 1/4
>> domain with partial Dirichlet boundary conditions that impose a symmetry
>> condition (i.e. displacement normal to the symmetry boundary is clamped
>> to zero, and tangential displacement is unconstrained). This means that I
>> have Dirichlet constraints that affect the dofs on the contact surface.
>> What I find is that the solve works fine in serial, but in parallel the
>> nonlinear convergence fails, presumably because of an incorrect Jacobian.
>> I have actually run into this exact issue before (when I was augmenting
>> the sparsity pattern "manually", prior to GhostingFunctor) and I found
>> that the issue was that the dof constraints on the contact surface were
>> not being communicated in parallel, which caused the incorrect Jacobian
>> in parallel. I fixed it by adding artificial Edge2 elements into the mesh
>> (like in systems_of_equations_ex8) to ensure that the dof constraints
>> are communicated properly in parallel.
>>
>> So, my question is, is there a way to achieve the necessary dof
>> constraint communication with the new GhostingFunctor API? I had hoped that
>> using
>> "add_algebraic_ghosting_functor" would do the job, but it apparently
>> doesn't.
>>
>
> Hmm... If you only needed algebraic ghosting, then
> add_algebraic_ghosting_functor should have been sufficient -
> processors won't know about all their ghosted dofs' constraints, but
> the ghosted dofs will get properly added to the send_list, and
> enforce_constraints_exactly() will ensure that the dofs, once
> constrained on the processors which own them, will have their
> values updated on all the processors which ghost them.
>
> But you need to augment the sparsity pattern too, so you should be
> using add_coupling_functor instead... and in *that* case, we're
> broken, aren't we? You build a Jacobian connecting the remotely
> coupled dofs, and you try to hit it with constrain_element_foo() or
> heterogeneously_constrain_element_foo(), but the processor isn't aware
> of all the ghosted dofs' constraints, so the element constraint matrix
> is wrong and so is your final answer.
>
Yep, that's exactly my understanding of the issue.
> I think the proper fix is to call the coupling functors in
> scatter_constraints(), then query the processors who own the elements
> which are to be coupled for any constraints on those elements' dofs.
> I can take a crack at that tomorrow or Monday. Any chance you could
> set up a unit test (or even just stuff an assertion into the misc ex9
> example?) that checks for the problem?
>
That'd be great, thanks! I'll be happy to try it out once it's ready. I'll
also look into making a test case that can be added to libMesh.
Thanks,
David
------------------------------------------------------------------------------
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
