On Tue, Jul 9, 2013 at 11:53 AM, Roy Stogner wrote:
>
> That's a little tricky, since you'd basically have to clone the whole
> PeriodicBoundaries structure... but I'm still inclined to say you're
> right. Would you guys mind putting together the patch?
>
Unfortunately - we don't have the time r
On Tue, 9 Jul 2013, Derek Gaston wrote:
it turns out that you can still call non-const methods on member
variables of the class from a const method if those member variables
are pointers or references
(see:
http://stackoverflow.com/questions/7390437/c-const-member-functions-are-modifying-membe
Ok - I tracked it down. The issue is that we have a derived class from
PeriodicBoundaryBase that overrides get_corresponding_pos()... and even
though you made that function "const" it turns out that you can still
call non-const methods on member variables of the class from a const method
if th
On Tue, 9 Jul 2013, Derek Gaston wrote:
> Nope - it's not that the PointLocator is NULL... the PointLocator is
> _returning_ NULL (ie it couldn't find an element).
Is it possible that it's using the wrong translation vector somehow?
One thread working on boundary pair A inadvertently pulling the
Nope - it's not that the PointLocator is NULL... the PointLocator is
_returning_ NULL (ie it couldn't find an element).
Look at line 1956 in fe_base.C
Derek
On Mon, Jul 8, 2013 at 9:28 PM, Roy Stogner wrote:
>
> On Mon, 8 Jul 2013, Derek Gaston wrote:
>
> It appears that something is wrong in
Sent from my iPad
On Jul 8, 2013, at 9:41 PM, Cody Permann wrote:
> That's like triple-dog-daring the machine or is that temping the
> sufficiently-talented fool?
Are you referring to me? :-)
Derek
--
See everything
Sent from my iPhone
On Jul 8, 2013, at 9:28 PM, Roy Stogner wrote:
>
> On Mon, 8 Jul 2013, Derek Gaston wrote:
>
>> It appears that something is wrong in there (or we're missing a lock
>> somewhere). Here is what happens in optimized mode:
>> PeriodicBoundaries point locator object returned NUL
On Mon, 8 Jul 2013, Derek Gaston wrote:
It appears that something is wrong in there (or we're missing a lock
somewhere). Here is what happens in optimized mode:
PeriodicBoundaries point locator object returned NULL!
Stack frames: 5
0: 0 libmesh_oprof.0.dylib 0x000102d98390
It appears that something is wrong in there (or we're missing a lock
somewhere). Here is what happens in optimized mode:
PeriodicBoundaries point locator object returned NULL!
Stack frames: 5
0: 0 libmesh_oprof.0.dylib 0x000102d98390
libMesh::print_trace(std::ostream&) + 64
1:
On Mon, 8 Jul 2013, Derek Gaston wrote:
It seems like there is something that still isn't thread safe in there.
Roy: Maybe you could take a look around there and see if anything
rings a bell. I'm betting that the reason we don't see this with
TBB is that our test is so small TBB isn't actuall
The last issue I have left with pthreads is that 2 of our periodic boundary
condition tests are failing _periodically_ (pun! And also true...) when
running in threaded mode. 8 times out of 10 I can run them threaded and
they run fine - but those other 2 times they do this (in debug mode):
Asser
11 matches
Mail list logo
