Thanks for all your responses, Roy, what you said is true about real elastic contact. My implementation(& my geometry) for elastic-rigid contact problem is still very elementary. If someone wanted to do a real elastic contact with for example "conforming profiles" (e.g. a ball on a curve or something similar) then they needed to use inequality bounds and what not.
Right now I implemented these using a penalty method. It's not pretty nor does any good for my condition number but does the trick for me. On the other hand if I wanted to use the API how would you suggest updating the ID? Should I do a loop over all the elements and then faces and add faces that are in contact zone to an ID? If so can a face have two IDs? And is there a place in the source code you do something similar so I can look and get an idea? Dimtry, on a slightly different subject, Since they removed DMSetFunction/Jacobian from petsc-dev can libMesh DM be built with petsc-dev right now? Best, Ata On Mar 4, 2013, at 4:42 PM, Dmitry Karpeev <karp...@mcs.anl.gov> wrote: > > > On Mon, Mar 4, 2013 at 3:34 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Sun, 3 Mar 2013, Ataollah Mesgarnejad wrote: > > > I need some advice on how to implement an inhomogeneous Dirichlet BC > > for elastic-rigid contact. This BC is a bit weird since it doesn't > > apply to all of the faces of a boundary_id rather it applies to > > faces within the contact range (changes with time) and all the other > > faces should have natural (traction free) BCs. > > > > - can this be done using new Dirichlet API? and how? > > You can add and remove boundary_ids from sides, sides can have > multiple (or no) boundary ids at any given time, and Dirichlet > constraints can be regenerated with a reinit(). So although the > DirichletBoundary API requires an id, you can still control the extent > of a time-varying boundary with that id. > > But what this implementation would do to your time and space orders of > accuracy, I don't know. A selectively applied equality constraint may > not be a decent substitute for the true inequality constraint. > > It wouldn't be impossible to extend the current constraints system to > allow for true inequalities that could then be enforced within the > nonlinear solver rather than the time integration. That's probably > not near the top of any of the main developers' todo lists, though. > > There are plans to extend PETSc VI solvers to allow bounds on constraints > (functionals of the state), in addition to bounds on the state variables > themselves. > However, to add these systematically, Lagrange multipliers living on the > contact services > would need to be introduced into libMesh. > > Another tricky part would be matrix preallocation corresponding to those > nodes (the same, > I believe, as in the case of dynamically added/removed Dirichlet nodes). > > The SNESVI extension plans are a bit on the back burner, but could be moved > up if, > for example, Moose were to use this formulation as one of its options for > doing contact. > That, again, would depend on having surface variables. > > Dmitry. > --- > Roy > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
