Awesome Ben - that's what I was thinking. I appreciate you taking a look...
Detek
On Friday, January 24, 2014, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Jan 24, 2014, at 4:32 PM, Derek Gaston <fried...@gmail.com<javascript:;>>
> wrote:
>
> > We utilize this in the output system when we're trying to output a
> ParallelMesh using a serial format (like Exodus). In that case we really
> don't need the mesh on _every_ processor.... only on processor 0.
> >
> > It would be better to use something like
> MeshCommunication::localize_to_one() to bring the mesh down to processor 0
> and output it then get rid of the remote elements again (like what
> MeshSerializer does, but not all-to-all).
> >
> > Does that make sense to you guys?
> >
> > I understand that we shouldn't really be using a serial output format
> with ParallelMesh... but there are times when it's going to happen so no
> reason to be so wasteful ;-)
>
> I'd say then we need a MeshCommunication::gather(proc_id root_id) or
> something, which can gather to any rank. I'll have a look at all gather
> and see if it could be generalized - perhaps it would be easy to have one
> implementation where the default value is an invalid proc_id and the
> behavior is allgather, but an optional input could control the rank that
> gathers?
>
> -Ben
>
>
--
Sent from my iPhone
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
