Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Libmesh-users] Solve on part of domain

 Re: [Libmesh-users] Solve on part of domain From: Tim Kroeger - 2010-11-08 15:07:47 The next difficulty with my solve-on-part-of-domain stuff has now shown up. It is the constrained-dof issue now, which Roy already predicted and I didn't believe. Luckily enough, my application seems to be sufficiently complicated for any potential problem to actually occur. Let's assume the following situation: a - - - b - - - c - - - - - - - d | | | | | A | B | | | | | | e - - - f - - - g E | | | | | | C | D | | | | | | h - - - i - - - j - - - - - - - k | | | | | | | | | | F | G | | | | | | | | | | l - - - - - - - m - - - - - - - n Elements A, B, and C are inside the active subdomain, the others are outside. My application hence imposes Dirichlet boundary conditions for dofs h, i, f, g, and c, where the values equal the current_local_solution values at the respective dofs. However, using the constrainig procedure, the equation for dof i is replaced with the condition that dof i be the mean value of dofs h and j (likewise for dof g). On first sight, this is no problem because these two dofs are fixed as well, and their mean value coincides with the value of dof i. But then, as PetscLinearSolver creates the submatrix, the matrix row and column corresponding to dof j are removed from the matrix, resulting in the equation that dof i be half the value of dof h. This of course results in a completely wrong solution. To resolve this problem, I thought of the following possibilities: Idea #1: Add constraining dofs (in this case, dof j) to the set of active dofs. The problem with this is that I currently don't assemble anything on element D, so that dof j doesn't have an equation. Idea #2: Ensure that refined elements whose neighbors are not refined are either completely contained in the active subdomain or not at all. I don't like this because it restricts the user's choice of the subdomain. Idea #3: Remove row j from the matrix, but not column j. This results in a non-quadratic matrix, namely an underdetermined system. I wonder what PETSc would do then. I don't think it will do what I would like it to do in this situation. (Jed?) Idea #4: Upon removing the columns of the matrix, automatically adjust the right hand side. I think this would actually be quite easy to do by the following procedure: 1. Remove the inactive rows of the matrix. 2. Let B denote the active columns of the matrix and C all the remaining (inactive) columns. 3. Subtract C*x from b (where b is the right hand side and x the solution vector). 4. Then solve with B as before. Idea #5: Follow Jed's prior objection that just leaving the inactive components of the solution vector unchanged makes the whole thing become a weird beast. For instance, this should be able to be achieved by subtracting an appropriate vector before solving and adding it again afterwards. Any thoughts? Well, the more I think about this, the more I find that #4 is the best choice. It can be done in PetscLinearSolver and will work quite generally (if I don't overlook something), so that the user wouldn't have to care about. Best Regars, Tim -- Dr. Tim Kroeger CeVis -- Center of Complex Systems and Visualization University of Bremen tim.kroeger@... Universitaetsallee 29 tim.kroeger@... D-28359 Bremen Phone +49-421-218-7710 Germany Fax +49-421-218-4236