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
t
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
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.
We don't need to over think this... we are sending some strings across the
wire once per simulation..
Derek
On Wed,
On Wed, 13 Feb 2013, Roy Stogner wrote:
On Wed, 13 Feb 2013, Kirk, Benjamin (JSC-EG311) wrote:
Communicator::set_union std::map &data) …
at line 1824 of parallel_implementation.h
You can broadcast the parallelized boundary names simply by calling
this guy, and implementing whatever may be n
On Feb 13, 2013, at 3:17 PM, Roy Stogner wrote:
> On Wed, 13 Feb 2013, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Communicator::set_union std::map &data) …
>>
>> at line 1824 of parallel_implementation.h
>>
>> You can broadcast the parallelized boundary names simply by calling
>> this guy, and imp
On Wed, 13 Feb 2013, Kirk, Benjamin (JSC-EG311) wrote:
Communicator::set_union std::map &data) …
at line 1824 of parallel_implementation.h
You can broadcast the parallelized boundary names simply by calling
this guy, and implementing whatever may be needed for your
std::string.
Can this wor
On Feb 13, 2013, at 3:08 PM, Roy Stogner wrote:
> Combine that with a deletion step when
> removing nonsemilocal elements and there's no reason it would have to
> be inefficient to keep the boundary names fully parallelized.
But in the interest of keeping it simple too, you might look at
Comm
On Wed, 13 Feb 2013, Cody Permann wrote:
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
On Wed, Feb 13, 2013 at 1:27 PM, Roy Stogner 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 mi
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.
One of the things (maybe the only thing) that we are missing when
broadcasting the mesh are the boundary/subdomain names which are stored in
boundary_info.
Namely these two guys:
std::map _ss_id_to_name;
std::map _ns_id_to_name;
I have only myself to blame since I originally added these data stru
11 matches
Mail list logo
