On Wed, Feb 13, 2013 at 1:27 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

On Wed, 13 Feb 2013, Cody Permann wrote:

So I'd be happy to work on this unless someone else wants to
volunteer.  Clearly we'll need a pack this data up since the strings
will be variable length as we send this over the wire.  I might need
a little guidance as to where or how this can be done.  I looked at
the mesh_broadcast routine and can't immediately see where all of
the boundary_info data is sent.  I'm missing something here...

The trick is that boundary info is packed up along with the elements
and nodes it applies to.  See parallel_elem.C and parallel_node.C for
the implementation.  

 
We don't want every processor to know about every
boundary id, only for every id on its own part of the boundary.

I don't think this'll be what we want to do for those maps you added,
though.  

Hmm, so which is it? If you don't want ids everywhere, why would you want strings everywhere?
 
Those ought to be serialized, right?  It would save a little
memory but add a lot of communication if we tried to have each rank
only store labels corresponding to boundary ids that had some support
on that rank's partition.

Ah, so we have to decide on which trade-off we want...

I'd love to add Parallel::pack/unpack/etc. implementations for
std::pair and std::string. 
Then you'd be able to broadcast each whole
map with a single function call.  

std::string for sure, but std::pair?  Why not add an implementation for std::map that just send pairs of vectors?  I'm sure there are lots of trade-offs for all of these designs.    
 
I'm not sure when I'd find time to
get to it, though, so if you definitely want it before March you'll
have to do it mostly yourself; ping me with any questions.

I guess we'll see - I don't know if we need this right now or not.  We have a huge backlog all the time so we just have to decide what gets done and what doesn't, I'm sure you know the feeling.

Cody
 
---
Roy