[Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Derek Gaston
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Derek Gaston
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Kirk, Benjamin (JSC-EG311)
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

Re: [Libmesh-devel] Problem with System::project_solution()

2012-02-08 Thread Roy Stogner
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Derek Gaston
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Kirk, Benjamin (JSC-EG311)
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Derek Gaston
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

Re: [Libmesh-devel] Problem with DofMap::dof_indices()

2012-02-08 Thread Kirk, Benjamin (JSC-EG311)
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