Continuing my "huge run" witch hunt... I have really big runs that are
hanging at mutexes during threaded execution of SparsityPattern::Build().
The main issue seems to stem from DofMap::dof_indices(). Everything is
getting hung around allocating / deallocating std::vector objects
(memory operati
Win. Between fixing the localize() issue I brought up earlier and
de-threading SparsityPattern::Build() my job now ran! Hopefully the others
will continue to run as well.
Derek
On Wed, Feb 8, 2012 at 1:07 AM, Derek Gaston wrote:
> Continuing my "huge run" witch hunt... I have really big runs
Excellent. What was the symptom in te sparsity pattern?
I'll be flying most of the day, hopefully that'll provide me some time to stare
at this
-Ben
On Feb 8, 2012, at 3:16 AM, "Derek Gaston"
mailto:fried...@gmail.com>> wrote:
Win. Between fixing the localize() issue I brought up earlie
On Tue, 7 Feb 2012, Derek Gaston wrote:
The problem is that that version of the function explicitly builds full index
sets forcing complete communication. If we would
have just said "current_local_solution = solution" it would actually do the
correct ghosted assignment.
Interesting. So th
The symptom with the sparsity pattern was that it would hangup forever in
DofMap::dof_indices(). ie all threads would be sitting at either
operator_new or delete for a std::vector inside DofMap::dof_indices().
Then, after taking forever on that if it ever got past it, a few threads
were still hun
The threading of the sparsity pattern is a bigger deal with amr when it is done
a lot, but in any case we could add a --single-threaded-sparsity or something
as an immediate stopgap.
And the hilbert indexing is used to derive a globally unique, partition
agnostic node number. But as you say it
On Feb 8, 2012, at 10:14 AM, Kirk, Benjamin (JSC-EG311) wrote:
> The threading of the sparsity pattern is a bigger deal with amr when it is
> done a lot, but in any case we could add a --single-threaded-sparsity or
> something as an immediate stopgap.
No need to do that. Just don't call paral
The purpose in general is to get a globally unique, partition agnostic element
number. There may be a workaround for partition_unpartitioned_elements that
bypasses it. I'll see what I can do, but I'm a little compromised today...
Halfway to MN waiting on a flight delay
On Feb 8, 2012, at