Hi Roy, I am still not able to get it to work. I tried matrix ordering, varied solver and PC types.
I would think the problem is when the constrains are applied... The final matrix is probably not nice. How can I debug this? Renato On Fri, Mar 15, 2019 at 3:36 PM Renato Poli <rebp...@gmail.com> wrote: > 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 <royst...@ices.utexas.edu> > 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 >> > _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
