> > No? That's no fun, then. haha. Well, I've witnessed couple of such heated debates and for some reason, they don't always end pretty ;) but if that will create more meaningful conversation, then bring in the opinions !
> deal.II has quite a few features libMesh doesn't; hp in good shape, > geometric multigrid, and vector-valued elements are the big ones that > come to mind. Their big limitation last time I checked was geometric > element type; no support for anything but hexes, quads, and edges. I didn't realize they had intrinsic geometric multigrid support in deal.II. It would have been a great addition to my work, if libMesh had an easy mechanism to do this but the couple of times I went down that path, I didn't quite succeed. Mostly because my Physics inherits EquationSystems and I was trying variations on creating a new physics object that is a coarsened version of the refined mesh and computing the solution of it to accelerate convergence. This path however got a little complicated quick since I had to maintain coarse-fine mesh associations but provides the advantage of not having to re-allocate the required matrices and vectors over and over (which would be necessary if using a single EquationSystems for a mesh). Anyway, this might require a new thread and more time if you want to talk about it in detail. And yes. The fact that they do not support Triangles, Tets and Prisms is a problem when modeling arbitrary geometry. And is one of the main reasons I chose libMesh ! But I believe they have also created optimizations based on that precise fact. I have talked to Guido Kanschat, one of the developers before, and he suggested that since in most cases the FE calculations are represented as tensor products, several template based optimizations are in place which increases efficiency at element level. Of course, I have not seen the internals of the library and cannot comment on what these are. May be, when libmesh has evolved some more, a new configure option to use only hex, quads, edges can be provided along with such added optimizations ? AMR-wise, I'm a newbie and have barely scratched the surface. I have only used some basic estimators (uniform, kelley) before and I hope to learn quite a few useful techniques at the workshop this week. If I witness something intriguing at the hands-on sessions with deal.II, I'll be happy to start a discussion here. I met Derek at a conference last week but didn't get enough time to talk about anything really. So if any of you guys are here for the workshop, it'll be a great time to discuss issues/ideas in person. Vijay On Sat, May 16, 2009 at 11:19 PM, Roy Stogner <[email protected]> wrote: > > On Sat, 16 May 2009, Vijay S. Mahadevan wrote: > >> It might be tad late to register for the conference now but if you are >> attending, I would be interested in hearing your comments about the >> usefulness of deal.II and libmesh in your work. Of course, my >> intention is not to instigate any kind of heated debate > > No? That's no fun, then. > >> but just to expand my horizons in understanding the >> limitations/features of each package in AMR methods. > > deal.II has quite a few features libMesh doesn't; hp in good shape, > geometric multigrid, and vector-valued elements are the big ones that > come to mind. Their big limitation last time I checked was geometric > element type; no support for anything but hexes, quads, and edges. > --- > Roy > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
