On Wed, 25 Jun 2008, Benjamin Kirk wrote: > DistributedVector<Real> vec(n_global, n_local, array_of_remote_indices); > > Where "vec" is a vector which stores n_local entries, and also has "ghost > storage" for array_of_remote_indices.size() entries.
We'd also need an "unsigned int first_local_index" argument for the offset of n_local, right? In any case that sounds like an excellent idea. We'll also want to have some higher level APIs where array_of_local_indices is implied to come from the system's send_list, of course, but if we get the lower level stuff right first that'll make it easier to handle the exceptional cases like System::project_vector. > You then go about your business, computing with "vec" and performing > operations which update the local entries, and when you need to get > synchronized copies of the remote values you call something like > > vec.localize(); > > This would effectively eliminate current_local_solution -- everything would > be done in-place from solution. Sounds good. While you're explaining the fundamentals of our parallel vector structures to me, could you explain the VecAssemblyBegin / VecAssemblyEnd pair in PetscVector::close? That's what does all the communication required by VecSetValues, right? What's the reason for the dual API call; does the communication get started asynchronously by Begin() and then End() blocks waiting for completion? --- Roy ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
