On Sun, 17 May 2009, Vijay S. Mahadevan wrote: > haha. Well, I've witnessed couple of such heated debates and for some > reason, they don't always end pretty ;)
Software debates get heated because fanboys who use only one system experience cognitive dissonance when hearing advantages of a system they didn't choose. Many of us have used deal.II before, though; we're allowed to admit it's very good. :-) >> 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. Well, I'm not sure what state it's in. The docs appear to still say scary things like "The interface of this class is still very clumsy. In particular, you will have to set up quite a few auxiliary objects before you can use it. Unfortunately, it seems that this can be avoided only be restricting the flexibility of this class in an unacceptable way." and "multigrid on locally refined meshes only works with discontinuous finite elements right now. It is not clear, whether the paradigm of local smoothing we use is applicable to continuous elements with hanging nodes; in fact, most people you meet on conferences seem to deny this." That's still better than the current libMesh multigrid status of "plug a system into BoomerAMG and pray". > 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. That'll kill you. FEMSystem inherits System and gives the same sort of problems - FEMSystem itself should be copyable, but users are supposed to subclass it and if you have a fancy enough subclass then you really don't want it to be copied willy-nilly. > 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. Oh, just one more comment - I think the way to go is to copy the algebra (which is all PETSc et. al. should need) while performing reversible transformations on a single mesh. The former is easy (if we don't have an O(1) NumericVector::swap, etc they would be simple to add) and the latter is at least possible (with a little futzing with "subactive elements"). > 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 ? I'd have to know what the optimizations are. Some tensor-product specific things could be done even on hybrid meshes by simply keeping elements sorted by geometric type and using different code to loop over each chunk. Anyway, right now optimizing FE calculations is not something libMesh does well, even to the extent it can be done with arbitrary elements. I'd bet that just vectorizing the fe_shape* function call API would give us a non-trivial performance boost. > 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. Please, let us know. --- 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
