> > Now let's see what our friends from the competition have to say ;-)
>
> Competition? Does this mean you've added triangles, tets, prisms and
> pyramids while we weren't looking? ;-)
:-) I guess I could come up with other things instead ;-)
> libMesh does have hooks into matrix-free solvers to avoid that memory
> usage, but they're fairly new;
deal.II can do that as well, but not...
> libMesh also does now have a distributed ParallelMesh, but it's also
> new, SVN head only, and hasn't been tested on huge problems yet.
> Still, if you're solving on a 256-CPU cluster, it will be a nice
> option to have one copy of the mesh (plus a copy or three of each
> "ghost" element and node) stored instead of 256 copies.
...this one.
> libMesh just hooks to PETSc and LASPACK for sparse linear algebra,
> whereas deal.II has its own multithreaded linear solvers (which IIRC
> were more efficient than PETSc?) for shared memory systems.
Yes. Maybe more importantly (because it scales very nicely) we also
assemble linear systems in parallel on multicore systems.
> SerialMesh, one for each process. Can deal.II mix multithreading with
> PETSc?
For assembling yes (which also works on individual cluster nodes, of
course). For solvers we just hand things over to PETSc.
I hear PETSc has some magic flag that lets it run multithreaded but I
don't know how to turn that on.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: [EMAIL PROTECTED]
www: http://www.math.tamu.edu/~bangerth/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
