On Sat, 21 Jul 2012, Cody Permann wrote:

   for (unsigned int l=0; l != n_levels; ++l)
     Parallel::broadcast_packed_range(&mesh,
                                      mesh.level_elements_begin(l),
                                      mesh.level_elements_end(l),
                                      &mesh,
                                      mesh_inserter_iterator<Elem>(mesh));

Oh wow, very nice.  I could actually use something like this in a
couple of classes I recently built.  Except my needs are even more
straightforward.  I just have lists of nodes (std::vector<Node *>)
that I'd like to gather on all processors.  Right now I'm just
passing Ids and extracting them on each processor but it sounds like
with the right function call, I could avoid that with all the fancy
broadcast stuff you've built.  

Well, if the nodes already exist and are up to date on each processor,
then the most efficient way to pass a list of them from processor to
processor is still to pass a list of ids and MeshBase::get_node for
each.

If you don't necessarily have the nodes on each processor (distributed
ParallelMesh situation) then the packed_range code is the way to go.

If you have the nodes on each processor but their information
(locations, associated boundary condition ids) is being updated by
their owning processor, then the packed_range code is probably the
best way to propagate that, but it might need some adjustment - IIRC
I've currently got the unpack code loaded with assertions that
any received data corresponding to an existing node or element is
consistent with the existing data.

Will this work outside of the mesh?   I haven't really looked into
it yet.

Hmmm... with the current design, there's some side effects due to
backwards compatibility: because we don't add boundary conditions (or
in the case of elements, update topology) with MeshBase::add_node/elem
I'm forced to do those things in the Parallel::unpack, and so if you
don't want to modify your Mesh on the receiving end then you'd have to
give the receive function a new "dummy" Mesh to work with.
  
      I left PackedNode and PackedElem around for backwards
      compatibility, but they could be eliminated if/when the Idaho
      folks want to use packed_range based code instead.

I bet we can take a look so that we can do some housekeeping here.
 We don't have this code scattered too far and wide.

No rush; just let me know.
---
Roy
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to