Alright gents, I'm finally getting back to this task.  We kinda need this now since we are running large jobs quite regularly and reading the mesh on every processor is not making our I/O system happy.  I know that Derek had just stopped using "boundary names" so that we could just revert back to the parallel element broadcast routines, but we'd like to just get this all going for the benefit of our end users.

I thought I'd warm up with just broadcasting a std::vector<std::string> since it doesn't appear that we can even do that at this point.  From there it should be relatively easy to get a std::pair<T1, T2> where T1 or T2 is a string moved across the wire.

I'm trying to wrap my head around how you guys intend for this to work.  Do we implement the pack/unpack routines for std::basic_string<T> and use those in conjunction with the broadcast or do we just create additional specializations for certain Parallel routines directly?  I haven't played around at this layer long enough to know what you might be thinking.

Perhaps if you can provide a few lines of sample code on how you see the API working might help me get started as well.


On Wed, Feb 13, 2013 at 2:49 PM, Roy Stogner <> wrote:

On Wed, 13 Feb 2013, Derek Gaston wrote:

> How about just finding the max length for the names and reading all
> the names into fixed length char*s.... and just using the available
> routines to send them across the wire.

That would definitely work.

> We don't need to over think this... we are sending some strings
> across the wire once per simulation......

Once per repartitioning, at most.

But yeah, I'm not overthinking this because infrequently synchronizing
a few strings is still hard; rather because taking time to overthink
Parallel:: stuff has paid off so well for me in the past.  There's a
bunch of code in the ParallelMesh synchronization, in one of our apps,
and even a bit in Parallel:: itself that I think I could greatly
simplify with a little of this refactoring.

Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
Libmesh-devel mailing list