On Wed, 15 Sep 2010, Jed Brown wrote: > On Wed, 15 Sep 2010 17:34:14 +0200 (CEST), Tim Kroeger > <[email protected]> wrote: > >> Assume further that the matrix is tridiagonal. If I then do what you >> suggested, four matrix entries are lost (that is, (9,10), (10,9), >> (19,20), (20,19)), aren't they? That's why I thought the IS for the >> columns should be larger than that for the rows. If the user provided >> dof indices are only those already owned by the processor, it seems to >> be necessary to communicate those across the processors in order to do >> the correct column selection. Is this right? > > No, the local part of the column IS denotes the column indices that will > belong to that "diagonal block". To put it differently, it defines the > ownership of a vector that the matrix can be multiplied by. Suppose we > want the equation > > y = A x > > to make sense. The "row IS" specifies the distribution of y, the > "column IS" specifies the distribution of x. The diagonal block of A is > the tensor product of the local part of the row and column ISs.
Ah, great! Thank you very much! Another question comes to my mind in this context: Does the whole thing also work for a shell matrix? It seems to me that for a (black-box) shell matrix, the only method to extract some submatrix is to provide a wrapper shell matrix function which extends the input vector by zeros, calls the original shell matrix, and then removes the unwanted components of the result. The question is whether PETSc does this whenever MatGetSubMatrix() is called on a shell matrix or whether I will have to do this myself. >> I don't find this weird. Well, we could let the user decide between >> several modes here, that is KEEP_SOLUTION, CLEAR, TAKE_RHS (or >> whatever names we agree to). Roy, what do you think? > > Usually a (tightly converged) solve is a linear operation from the > right-hand side to a solution, the values in the solution vector > only specify the starting point for the iteration. If tight > tolerances are used, then the starting vector only affects the time > to solution, but not the actual value. Solving on a subdomain > without modifying the solution vector for "inactive" dofs is a > deeply different semantic. I understand what you mean. First of all, we should let the user know what happens with the "inactive" dofs, otherwise the user might assume something which is not true. Then, also, it might be sensible to give the user a choice here since, depending on the application, one or another thing might be useful. Among the possible things to do, the action of just letting the inactive dof values unchanged is, although removing some well-known properties from the whole thing, the fastest thing to do (in particular if the number of active dofs is very small) and also the action which I need in my application. But perhaps you are right in that it should not be the default action because it is confusing. I'll add an ENUM for this and let the default be zeroing the inactive dofs. I'll also add a comment about "my" mode leading to loss of well-known properties. Best Regards, 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 ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
