On Mon, 29 Oct 2012, Roy Stogner wrote:
On Sat, 27 Oct 2012, Roy Stogner wrote:
I'll post again when I've got a patch I can't break.
Here goes.
The attached patch seems to work for me with both SerialMesh and
ParallelMesh, and doesn't break with threading this time.
Interestingly enough,
On Sat, 27 Oct 2012, Roy Stogner wrote:
I'll post again when I've got a patch I can't break.
Not quite "a patch I can't break" yet, so don't waste time doing any
non-automated testing, but here's "a patch I can't break quite as
easily" if anyone else wants to run it through a gauntlet on the
On Sat, Oct 27, 2012 at 10:41 AM, Roy Stogner wrote:
> Sorry for the mess;
>
Meh - it happens. It appears to be compiling today ;-)
Derek
--
WINDOWS 8 is here.
Millions of people. Your app in 30 days.
Visit The Window
On Sat, 27 Oct 2012, Derek Gaston wrote:
Hmmm... I'm still getting this:
src/base/dof_map_constraints.C: In member function ‘void
libMesh::DofMap::scatter_constraints(libMesh::MeshBase&)’:
src/base/dof_map_constraints.C:2871: error: ‘mesh’ was not declared in this
scope
make: *** [src/base/d
On Sat, 27 Oct 2012, Derek Gaston wrote:
We actually don't compute off-processor extra sparsity entries
currently. We do all the work to get all the info on the local
processor that the local processor needs to make decisions about
it's sparsity pattern and then just add the local entries.
R
On Sat, Oct 27, 2012 at 10:09 AM, Roy Stogner wrote:
> src/base/dof_map_constraints.**C:2875: error: ‘mesh’ was not declared in
> this scope
>
>> make: *** [src/base/dof_map_constraints.**x86_64-apple-darwin11.4.2.opt.*
>> *o] Error 1
>>
>
> Should be fixed in r6227, thanks.
>
Hmmm... I'm still g
On Sat, Oct 27, 2012 at 10:09 AM, Roy Stogner wrote:
> 1. User code is responsible for correctly adding all extra entries to
> each processor's sparsity rows on that processor. This should still
> work fine now.
>
> 2. User code can add extra remote sparsity entries to the new
> nonlocal part o
On Sat, 27 Oct 2012, Derek Gaston wrote:
Keep in mind the ability to add extra stuff to the sparsity pattern
(using AugmentSparsityPattern). That is something we rely on.
Hmm... how do you want to handle extra sparsity entries in the
distributed case?
1. User code is responsible for correc
Keep in mind the ability to add extra stuff to the sparsity pattern (using
AugmentSparsityPattern). That is something we rely on.
Also what is the current state of libMesh svn? I just got this compile
error:
Compiling C++ (in optimized mode) src/base/dof_map_constraints.C...
src/base/dof_ma
On Fri, 26 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> You said sparsity patterns, I read constraints... Still, I'll be happy to
> test it.
You might have to wait, sadly - I've already managed to trigger two
bugs with it. One is a plain dumb "I forgot about the MPI+threading
hybrid case" pro
You said sparsity patterns, I read constraints... Still, I'll be happy to test
it.
-Ben
On Oct 26, 2012, at 6:32 PM, "Roy Stogner" wrote:
>
> Right now, we loop over all active elements when computing sparsity
> patterns. But with the attached patch, we loop over only active local
> eleme
I'll be happy to test this next week, but it is definitely the right move -
especially as constraints become more expensive... Thinking about Paul's H1
and whatever else is coming...
-Ben
On Oct 26, 2012, at 6:32 PM, "Roy Stogner" wrote:
>
> Right now, we loop over all active elements whe
Right now, we loop over all active elements when computing sparsity
patterns. But with the attached patch, we loop over only active local
elements, then we do a round robin communication to send relevant
sparsity pattern row contributions to the processors which need them.
Anyone have time to h
13 matches
Mail list logo
