On Mon, 7 Apr 2014, David Knezevic wrote: >>> This does sound nasty... Do you see a good general solution here? >> >> I think it should always be safe to "move" a constraint onto a >> not-yet-constrained dof. The only remaining catch is the interaction >> with PeriodicBoundary constraints, where the constraints can involve >> more than one processor at once. > > OK, that approach doesn't sound too nasty...
What if we get *really* ugly... If we define a constraint involving variables A and B that gets placed on B, then a constraint involving B and C that gets placed on C, then a constraint involving C... then we need to be able to move constraints recursively. But I think we can prove that recursive movement plus a tree search is enough to handle any possible (consistent) scenario... > Do you have a first item on the to-do list here? Maybe getting it to work in > the case where we don't have any "conflicting constraints" first? Definitely! > As I said, I'm happy to work on this (though I'm not too familiar with the > guts of the constraint code...) Thanks. --- Roy ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
