From: Vijay S. M. <vi...@gm...> - 2009-05-17 03:20:03
|
Hi all, I was curious if there are any libmesh users attending the CBMS Conference on "Adaptive Finite Element Methods for Partial Differential Equations" at Texas A&M university this coming week. More information here: http://dealii.org/cbms/. 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 but just to expand my horizons in understanding the limitations/features of each package in AMR methods. Anyway, if you are coming over to A&M, drop me a line and I'll see you there ! Cheers, Vijay |
From: Roy S. <roy...@ic...> - 2009-05-17 04:19:53
|
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 |
From: Vijay S. M. <vi...@gm...> - 2009-05-17 05:18:43
|
> > 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 <roy...@ic...> 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 > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2009-05-17 11:52:13
|
> Hi all, > > I was curious if there are any libmesh users attending the CBMS > Conference on "Adaptive Finite Element Methods for Partial > Differential Equations" at Texas A&M university this coming week. More > information here: http://dealii.org/cbms/. I used deal.ii for a while and really enjoyed it. It is the need for generic meshes with arbitrary element types that surred the development of libMesh. Anyway, my week is pretty unpredictable but I am planning on being in College Station for at least some of the conference & look forward to seeing you there. -Ben |
From: Roy S. <roy...@ic...> - 2009-05-17 13:55:45
|
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 |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2009-05-17 14:21:37
|
On 5/17/09 8:45 AM, "Roy Stogner" <roy...@ic...> wrote: > 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. With a small amount of effort (seriously) I think we could cache all the reference element values such that the underlying shape functions are evaluated only once per (geometric element/finite element/quadrature order) pairing. We do this to some extent now in that data are only reevaluated when the geometric element type changes during iteration, but this could be pretty often. with a little template trickery we could actually build static tables at compile-time. if evaluating shape functions is a bottleneck in your app let me know - it hasn't been a big priority at least for me. -Ben |
From: Vijay S. M. <vi...@gm...> - 2009-05-17 18:39:03
|
Ben, I am looking forward to seeing you at the conference ! Performance wise, my profiling results have shown that dof-indices and shape function evaluations are a significant part of the residual evaluation but it is almost insignificant as compared to the nonlinear solve itself. This might be also because I do try, over-zealously sometimes, to do the solves matrix-free ! I do not think it is a bottle-neck yet but will keep you guys informed if this becomes important. Vijay On Sun, May 17, 2009 at 9:21 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On 5/17/09 8:45 AM, "Roy Stogner" <roy...@ic...> wrote: > >> 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. > > With a small amount of effort (seriously) I think we could cache all the > reference element values such that the underlying shape functions are > evaluated only once per (geometric element/finite element/quadrature order) > pairing. > > We do this to some extent now in that data are only reevaluated when the > geometric element type changes during iteration, but this could be pretty > often. > > with a little template trickery we could actually build static tables at > compile-time. if evaluating shape functions is a bottleneck in your app let > me know - it hasn't been a big priority at least for me. > > -Ben > > |
From: Roy S. <roy...@ic...> - 2009-06-01 16:07:45
|
Digging through old emails... On Sun, 17 May 2009, Kirk, Benjamin (JSC-EG311) wrote: > On 5/17/09 8:45 AM, "Roy Stogner" <roy...@ic...> wrote: > >> 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. > > With a small amount of effort (seriously) I think we could cache all the > reference element values such that the underlying shape functions are > evaluated only once per (geometric element/finite element/quadrature order) > pairing. That isn't possible for the C1 finite elements, and I'm not sure how useful it would be for the C0 elements; you'd still have to recompute all the shape derivatives. In any case, I'm not sure how much time is spent doing the actual calculations vs. how much time is spent in overhead. We're not too inefficient in FLOPS but we might be wasting time in function call setup/teardown or something. > if evaluating shape functions is a bottleneck in your app let me > know - it hasn't been a big priority at least for me. Well, I didn't add the "has_affine_map" stuff for my health - before putting that in, a big chunk of my Cahn-Hilliard apps' time was spent in FE::reinit(). --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-05-17 18:33:44
|
> 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 <roy...@ic...> 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 > |