Didn't notice that this had gone off-list; it shouldn't have. On Fri, 27 Apr 2012, Roy Stogner wrote:
> On Thu, 26 Apr 2012, Robert Weidlich wrote: > >> Currently I have just non-overlapping boundary ids, so a combination of >> boundary id and variable would work. > > Try out DofMap::remove_dirichlet_boundary() in r5603? > >> But I would also vote for checking the output of function when >> assembling the constraints. If the function returns NAN or sth simular, >> just leave the current point unconstrained. > > After talking and thinking about it, I like this idea. Although I > approve of protecting stupid users from themselves whenever possible > (particularly when I moonlight as a stupid user), and propagating NaNs > is usually a part of that, I also like the ability to elegantly do > complex things with simple APIs, and this does feel like it could be a > very elegant way to handle certain types of contact problems. > > One concern, though - what should our behavior be for higher-order > elements? There, we do local projections to decide on edge and face > degree of freedom values. If some quadrature point evaluations for > these projections return NaN but others don't, what do we do? Whole > face unconstrained? That won't converge under p refinement... > although one could argue that h refinement is more appropriate in such > cases anyway. > --- > Roy > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
