Hello again all, Ive been digging at this problem some more and I have some followup questions / observations. I've noticed that the constraint storage is split up into a number components, and would appreciate some basic info as to what these pieces represent.
The assert I am/was tripping was with the DofConstraintRow being empty, a row which is inserted to the _dof_constraints map which pairs row with a dof id. Now what I notice is that when I try and use print_dof_constraints(), the values actually being printed are obtained through the _primal_constraint_values map and are simply paired with the _dof_constraint ids. This begs the question what is actually being stored (or should be stored) in an individual DofConstraintRow, or is this some kind of intermediate object that at some point gets moved to other constrain maps and then cleared? Ive also noticed a _node_constraints map, as well as a _stashed_constraints, both of which appear to be unused, though judging by their names could potentially apply to my situation. What are the conceptual differences between the _dof, _node, _primal, and _stashed maps? Finally, in terms of the overall constraint implementation process, what does the R^T * K * C constraint matrix thats mentioned in the comments of constrain_element_matrix refer to? Is it related to the constraint formulation of Mark Shephard in his "Linear multipoint constraints applied via transformation as part of a direct stiffness assembly process" paper, or is there another resource which more closely mimics the overall philosophy libMesh is adhering when building up this constraint matrix? Thanks again for your time, Boris On Thu, Aug 25, 2016 at 10:09 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Thu, 25 Aug 2016, Paul T. Bauman wrote: > > On Thu, Aug 25, 2016 at 5:45 PM, John Peterson <jwpeter...@gmail.com> >> wrote: >> >> > On Thu, Aug 25, 2016 at 3:38 PM, Boris Boutkov <boris...@buffalo.edu> >> wrote: >> > > Hm - uniform refinement, yes. Are the boundary nodes on the >> > > outside edges of refined elements not considered to be hanging >> > > nodes? Apologies if I'm misusing the term. >> >> >> > Hanging nodes to me means "must be constrained to be compatible >> > with a coarser neighbor", which isn't possible on the boundary. >> >> > I'm not sure what's causing the assert for you, we'll probably >> > need Roy to comment on the different ways of constraining element >> > matrices, but again, for uniform refinement I would not expect >> > there to be *any* constraints. >> >> For the boundary nodes, any DirichletBoundary constraints would be >> handled through that code path, though, right? >> > > That's correct. > --- > Roy > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > >
------------------------------------------------------------------------------
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
