On Jan 20, 2013, at 5:28 PM, Jed Brown wrote: > On Sun, Jan 20, 2013 at 10:22 AM, Hui Zhang <mike.hui.zhang at hotmail.com> > wrote: > > On Jan 20, 2013, at 5:13 PM, Jed Brown wrote: > > > No, MatMult and MatMatMult require all objects to be on the same > > communicator. > > Thanks for the quick answer! It seems a general rule that all operands and > results must be > on the same communicator. Can I lift an object from a sub-communicator to > the sup-communicator > without changing the parallel layout of the object? > > You can with a Vec (e.g., using VecPlaceArray), but you're responsible for > the sharing so it's fragile. > > In general, I recommend creating the object on the largest communicator > involved and then getting access more locally. In the first pass, just make a > copy to a local subcomm unless a routine exists to do it automatically. If > you profile and see that the copy is significant (remarkably rare in > practice) you can sometimes optimize what is copied versus shared, or change > the parent parallel data structure to make the local access faster.
I think about the method and find it is not as convenient as allowing inter-communicator operations. For example, VecScatter actually allows the two Vec in different communicators (or one must include the other?). I have more questions. (1) Does MatScatter supports MatMatMult? (2) Does MatConvert works on MATNEST? (3) Does MatGetLocalSubMat support localization to a sub-communicator instead of a process? Thanks! > > > > > > > On Sun, Jan 20, 2013 at 10:12 AM, Hui Zhang <mike.hui.zhang at hotmail.com> > > wrote: > > parallel Mat, multiplies a serial Vec or a serial Mat > > > > Is it supported directly? If yes, can the resulting Vec/Mat be serial or > > parallel? > > > > > >
