On Fri, 15 Jan 2010 20:03:12 +0100, Joa Ljungvall wrote:
> Hi again,
>
> thanks for all the answers, some swoshing by over my head. But, I think I got
> the essiential:
>
> 1) If I go for threads, I will have to write the assembly part myself (no
> problems threads I know)
> 2) Threads only wi
Hi again,
thanks for all the answers, some swoshing by over my head. But, I think I got
the essiential:
1) If I go for threads, I will have to write the assembly part myself (no
problems threads I know)
2) Threads only will not use all my cores for the matrix inversion, error
estimates etc. So
On Thu, 14 Jan 2010 14:28:30 -0700, Derek Gaston wrote:
> BTW we do everything using JFNK (Jacobian Free Newton Krylov)... and
> heavily use threads... and see some good gains (as you say you
> should). And of course we're using libMesh for everything.
Cool. Dana told me a little about this MOO
On Jan 14, 2010, at 1:40 PM, Jed Brown wrote:
> Yeah, I try to avoid assembly in these cases, by lagging the
> preconditioner and doing more things matrix-free (the matrix-free
> operations can certainly benefit from threading, you'll probably realize
> a greater speedup this way since you can par
On Thu, 14 Jan 2010 14:11:04 -0600, "Kirk, Benjamin (JSC-EG311)"
wrote:
> From a PETSc point of view that is certainly true, but for libMesh
> applications we allocate the sparsity exactly, so there is no allocation
> inside the MatSetValues. Eventhough MatSetValues is not thread-safe, when
> th
>> Besides, Ben's code (with an expensive assembly combined with
>> experimenting with a matrix-free solve) isn't typical. Jed was right
>> that, for most users, threading the assembly isn't going to help much
>> when you've got an un-threaded solve going on in the background.
>
> Even just inser
On Thu, 14 Jan 2010 13:40:35 -0600 (CST), Roy Stogner
wrote:
> Besides, Ben's code (with an expensive assembly combined with
> experimenting with a matrix-free solve) isn't typical. Jed was right
> that, for most users, threading the assembly isn't going to help much
> when you've got an un-thre
On Thu, 14 Jan 2010, John Peterson wrote:
On Thu, Jan 14, 2010 at 10:32 AM, Roy Stogner wrote:
On Thu, 14 Jan 2010, Joa Ljungvall wrote:
However, some threading would be nice... I tried to compile libmesh
with --enable-tbb and then running example 14, but no threads
around? Any ideas?
I'
On Thu, Jan 14, 2010 at 10:32 AM, Roy Stogner wrote:
>
> On Thu, 14 Jan 2010, Joa Ljungvall wrote:
>
>> However, some threading would be nice... I tried to compile libmesh
>> with --enable-tbb and then running example 14, but no threads
>> around? Any ideas?
>
> I'm afraid that some of the best th
> We currently don't try to autodetect the number of cores you have
> available. (if you have 4 cores there's often good reason to run 4
> MPI processes on them, and you don't want those processes to spawn an
> extra three threads each). So you need to specify --n_threads=4 (or
> whatever) on the
On Thu, 14 Jan 2010, Joa Ljungvall wrote:
> However, some threading would be nice... I tried to compile libmesh
> with --enable-tbb and then running example 14, but no threads
> around? Any ideas?
Ben can correct me if I'm wrong and if he's not too busy, but I think
there's two issues here:
We
On Thu, 14 Jan 2010 13:48:35 +0100, Joa Ljungvall wrote:
> Hi all,
>
> I have a small question... In a program of mine I'm using libmesh to solve a
> PDE. This by having turned example 14 into
> a class that inherits from a base class I've written to interface different
> FEM packges to my code
Hi all,
I have a small question... In a program of mine I'm using libmesh to solve a
PDE. This by having turned example 14 into
a class that inherits from a base class I've written to interface different FEM
packges to my code
(I've solved the same problem using dealii). So I link to libmesh.s
13 matches
Mail list logo
