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 Fri, 2 Nov 2012, Derek Gaston wrote:
> How about clearing the cache when the mesh changes. This is something
> we do a lot in MOOSE now...
The trouble is just how badly that breaks modularity. Right now FE
objects don't know that the Mesh class hierarchy even exists.
---
Roy
--
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
How about clearing the cache when the mesh changes. This is something
we do a lot in MOOSE now...
Derek
Sent from my iPhone
On Nov 2, 2012, at 12:03 PM, Roy Stogner wrote:
>
> On Fri, 2 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Cache based on (this)?
>
> Even that's not necessarily saf
On Fri, 2 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Cache based on (this)?
Even that's not necessarily safe - we delete Elem objects when we
coarsen them, after all, and there's nothing stopping new from placing
a newly created Elem in the same place where an old one just
disappeared.
---
Ro
Cache based on (this)?
-Ben
On Nov 2, 2012, at 11:51 AM, "Roy Stogner" wrote:
>
> I just traced down a "ParallelMesh bug" to an underlying bug in the
> Hermite finite elements: we use the element id to decide whether to
> use certain cached values or not, but it's possible for the id of the
>
I just traced down a "ParallelMesh bug" to an underlying bug in the
Hermite finite elements: we use the element id to decide whether to
use certain cached values or not, but it's possible for the id of the
last element of one assembly pass to match the id of the first element
in the next assembly
