On Fri, 2 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I was able to run with a vector of tags, but the vector
> *desctructor* died (in debug mode) trying to dereference an "unused"
> tag. My guess this is because our simple reference counting is
> suffering the same issue as std::auto_ptrs<>
On Nov 2, 2012, at 3:22 PM, Roy Stogner wrote:
>
> On Fri, 2 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> If I do this I don't need a container. But there is a problem, at
>> least in DEBUG mode, there is a collective assertion in
>> get_unique_tag(), preventing me from creating one inside
On Fri, 2 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> If I do this I don't need a container. But there is a problem, at
> least in DEBUG mode, there is a collective assertion in
> get_unique_tag(), preventing me from creating one inside the "if
> (libMesh::processor_id() == 0)" bit
>
> See the
On Nov 1, 2012, at 9:03 PM, Roy Stogner wrote:
>
> On Thu, 1 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Roy - I'd like to have a default constructor for the MessageTag so I
>> can create a vector of them. I have a use case where I need a
>> number of tags, and this is the easiest way to
On Thu, 1 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Roy - I'd like to have a default constructor for the MessageTag so I
> can create a vector of them. I have a use case where I need a
> number of tags, and this is the easiest way to store them so I can
> then loop through the tags and recei
On Nov 1, 2012, at 5:20 PM, Roy Stogner wrote:
>
> On Thu, 1 Nov 2012, Derek Gaston wrote:
>
>> On Thu, Nov 1, 2012 at 3:10 PM, Roy Stogner wrote:
>> I'd like to see the compile error if it's not too much trouble, though.
>>
>> /Users/gastdr/projects/herd_trunk/devel/moose/src/utils/Gath
On Thu, 1 Nov 2012, Derek Gaston wrote:
On Thu, Nov 1, 2012 at 3:10 PM, Roy Stogner wrote:
I'd like to see the compile error if it's not too much trouble, though.
/Users/gastdr/projects/herd_trunk/devel/moose/src/utils/GatherNearbyElements.C:616:
error: no matching function for call to
On Thu, Nov 1, 2012 at 3:10 PM, Roy Stogner wrote:
> I'd like to see the compile error if it's not too much trouble, though.
>
Sure...
/Users/gastdr/projects/herd_trunk/devel/moose/src/utils/GatherNearbyElements.C:616:
error: no matching function for call to ‘receive(const unsigned int&,
std::ve
On Thu, 1 Nov 2012, Derek Gaston wrote:
I've tested the current changes and it did cause one compile error in MOOSE...
but it was in my code for dealing with ghosting extra elements
while using ParallelMesh. I know that that code is bad now anyway (I should
use the new PackedElem stuff and r
On Wed, Oct 31, 2012 at 10:59 AM, Roy Stogner wrote:
>
> I'll wait on you, thanks.
>
Sorry I didn't get to this yesterday... you checked this in this morning,
right?
I've tested the current changes and it did cause one compile error in
MOOSE... but it was in my code for dealing with ghosting ext
On Oct 31, 2012, at 12:30 PM, Roy Stogner wrote:
> On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> redo the embarassing EquationSystems serialized I/O code path. In
>> reading it last night I found some very, very poor algorithmic
>> complexity I want to fix.
>
> If you're messing
On Wed, Oct 31, 2012 at 11:20 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> wrote:
> And also to redo the embarassing EquationSystems serialized I/O code path.
> In reading it last night I found some very, very poor algorithmic
> complexity I want to fix.
>
Awesome Ben! Thanks!
De
On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> redo the embarassing EquationSystems serialized I/O code path. In
> reading it last night I found some very, very poor algorithmic
> complexity I want to fix.
If you're messing around in EquationSystems I/O, any chance you could
excise ou
> On Wed, 31 Oct 2012, Derek Gaston wrote:
>
>> Give me a bit - I'll test it in about an hour or so.
>
> I'll wait on you, thanks.
>
>> CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)?
>
> So far we've got Ben's, my, and Paul's votes for libMesh::CommWorld,
> so I'll add t
On Wed, Oct 31, 2012 at 10:59 AM, Roy Stogner wrote:
>
> On Wed, 31 Oct 2012, Derek Gaston wrote:
>
>> Give me a bit - I'll test it in about an hour or so.
>
>
> I'll wait on you, thanks.
>
>> CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)?
>
>
> So far we've got Ben's, my, a
On Wed, 31 Oct 2012, Derek Gaston wrote:
Give me a bit - I'll test it in about an hour or so.
I'll wait on you, thanks.
CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)?
So far we've got Ben's, my, and Paul's votes for libMesh::CommWorld,
so I'll add that as a referenc
Give me a bit - I'll test it in about an hour or so.
Derek
On Wed, Oct 31, 2012 at 10:25 AM, Roy Stogner wrote:
>
> On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
> > I applied this on libmesh.automake, which imposes strict namespacing,
> and I had to add
> >
> > 'using namepace libMes
On Oct 31, 2012, at 11:25 AM, Roy Stogner wrote:
> CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)?
CommWorld.sum(x);
gets my vote. Comm is too nebulous - easily could conflict with any other
communicator that could exist in a program. The others just aesthetically
off
On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I applied this on libmesh.automake, which imposes strict namespacing, and I
> had to add
>
> 'using namepace libMesh;'
>
> inside your anonymous namespace in parallel_implementation.h so that
> Parallel:: was found properly.
Bah - I forg
I applied this on libmesh.automake, which imposes strict namespacing, and I had
to add
'using namepace libMesh;'
inside your anonymous namespace in parallel_implementation.h so that Parallel::
was found properly.
Then testing with FIN-S showed no issues!
-Ben
---
On Tue, Oct 30, 2012 at 5:04 PM, Roy Stogner wrote:
>
> Extra testing would be appreciated.
>
Applying the patch and running one of the grins examples as is with all mpi
or mpi+threads worked fine for me.
--
Everyone hate
On Wed, 24 Oct 2012, Paul T. Bauman wrote:
On Wed, Oct 24, 2012 at 12:32 PM, Roy Stogner wrote:
This is such an aesthetic improvement over the mess of default
Communicator arguments in parallel.h that I'd be tempted to change to
something like your proposed API regardless of
22 matches
Mail list logo
