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 [email protected]
Universitaetsallee 29 [email protected]
D-28359 Bremen Phone +49-421-218-7710
Germany Fax +49-421-218-4236
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
