> 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. :-)
I do have to admit that most of those debates were between old timers who wrote a certain code years back and were trying to make a case for people to still use it with all the hidden approximations. But it is always refreshing in terms of ideas to compare and contrast the different options available for solving PDE systems through conversations, in our case libMesh, deal.II and hermes (http://hpfem.org/uniquefeatures.html) and choose the best library for your application. And I got to say, libMesh has made my development cycle much shorter and still provides me the versatility of using several specialized solvers in the backend. And thats a big thumbs up to you guys from me ! > 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. I have to say that I've never really looked at FEMSystem or used it in my application although I think there is a good possibility that I'm replicating what you have in there. I did find out the hard way that creating copies of the Physics object is probably not the way to go but my initial thoughts were that when calculating long transients, maybe the added memory and effort can be offset by gain in performance from the mutigrid solves. I have given up this path for now and been using Hypre with BoomerAMG, hoping it will solve the linear system I throw at it correctly. This makes it lot more of a black-box than I like but guess it is a good start. And I'll hopefully have some more useful comments or suggestions by the end of this week after getting a taste of what deal.II can do ! Cheers, Vijay On Sun, May 17, 2009 at 8:45 AM, Roy Stogner <[email protected]> wrote: > > 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
