On Wed, 15 Sep 2010, Jed Brown wrote: > On Wed, 15 Sep 2010 16:49:53 +0200 (CEST), Tim Kroeger > <[email protected]> wrote: > >>> VecScatter moves entries around, and isn't the issue here. >>> Redistributing indices to satisfy some a-priori size bound is somewhat >>> different (though not hard). >> >> So do I have to do something additional or not? I would think that I >> don't have to, because VecSetSizes() should be able to divide the >> index range {0,...,N-1} into k (almost) equally wide intervals itself. > > The user provides a *different* std::vector on each process (the global > indices that will be owned by that process in the sub-problem).
Ah, that's the point. I was thinking of the situation where *the same* std::vector is used on all processors, and it hence consists of *all* global dofs in the subset. When I now think about this, I seems as if in fact your way is more sensible, in particular also for the reason that setting up the vector becomes much cheaper by this. > You only duplicate the whole matrix everywhere if every process asks > for the global problem (and the resulting matrix is weird, and > almost certainly not what you want). In the easy (static) case, > each process only asks for global indices that it already owns. If > you want to repartition these indices, then you need to do that (it > won't happen automatically). > > That is, suppose the full problem of dimension 30 is partitioned regularly > > all = [0 .. 9 | 10 .. 19 | 20 .. 29] > > Now there is some subdomain > > sub_static = [2 3 | 12 13 14 15 | 25] > > If use this IS, the sub-problem will not be very well balanced, so you > might use > > sub_balanced = [2 3 12 | 13 14 | 15 25] > > But you are responsible for creating sub_balanced, it doesn't just > magically happen. Yes, I understand this now, thank you very much. But now, let's assume all = [ 0 .. 9 | 10 .. 19 | 20 .. 29 ] and sub = [ 8 9 | 10 .. 19 | 20 21 22 ] 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? >>> You probably want to set the rest of solution->vec() to the right side, >>> or zero it out, otherwise a solve is not a linear operation. The reason >>> for the first is that it makes the preconditioner look like the >>> submatrix was extended to operate on the full domain using the identity >>> (instead of zero which would make it very singular). >> >> You're right in that my current implementation makes solve not be a >> linear operation if considered on the complete vector. But what I >> want is some operation that only works on a subset of the dofs, where >> the same subset applies to the rhs and the solution. On this subset, >> solve is a linear operation, and the dofs outside the subset just >> don't take part in the operation at all, that is, they are kept >> constant. At least, in my application that's what I need. > > That makes this thing a weird beast. Are you sure it belongs in the > library? 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? 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
