From: Renato P. <re...@gm...> - 2019-03-15 18:36:51
|
Thanks. Do you see any sense in adding a SCALAR variable and "add_constrain_row" to it instead of using an existing DOF as reference? If that works, it would be nicer from the coding perspective. Would it be numerically more stable? Renato On Thu, Mar 14, 2019 at 6:04 PM Stogner, Roy H <roy...@ic...> wrote: > > On Thu, 14 Mar 2019, Renato Poli wrote: > > > How do I change the dof ordering options? > > "-pc_factor_mat_ordering_type string" with a string from > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatOrderingType.html#MatOrderingType > > > Add a SCALAR variable to use as a Lagrange multiplier? > > > > This sounds like a much cleaner solution. > > I could not understand how to do that in libmesh so far. > > It is probably time to put some more effort here... > > > > I see I must add a Kp_alpha matrix. Do I need the Kalpha_p as well? > > Yes; the Kalpha_p ends up being what looks most like the actual > constraint equation. > > ... > > Except you don't have a constraint *equation* here, you have > constraint *equations*. You wouldn't want a SCALAR lagrange > multiplier, you'd want to add a LAGRANGE variable subdomain-restricted > to boundary elements along the constrained domain boundary... this is > sounding like more trouble than it's worth unless you can't get the > directly constrained solves to converge. > --- > Roy > |