Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: David Knezevic <dknezevic@se...>  20120206 22:25:00

Hi all, I'd like to use a DG version of the Lagrange shape functions. This is pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" by Hesthaven and Warburton. Is there interest in this FE type being available in the library? It seems like the only change from the standard Lagrange code may be to just change get_continuity() to return DISCONTINUOUS? Thanks, Dave 
From: Roy Stogner <roystgnr@ic...>  20120206 22:28:31

On Mon, 6 Feb 2012, David Knezevic wrote: > I'd like to use a DG version of the Lagrange shape functions. This is > pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" > by Hesthaven and Warburton. > > Is there interest in this FE type being available in the library? I'd think so. > It seems like the only change from the standard Lagrange code may be > to just change get_continuity() to return DISCONTINUOUS? No; that'll just give you a buggy version of continuous Lagrange FE. ;) Off the top of my head, you'll also need to move the shape functions to the Elem off the nodes, and change the n_dofs_on* function specializations accordingly.  Roy 
From: Derek Gaston <friedmud@gm...>  20120206 23:05:38

We would definitely be interested in using this. Derek On Feb 6, 2012, at 3:24 PM, David Knezevic wrote: > Hi all, > > I'd like to use a DG version of the Lagrange shape functions. This is > pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" > by Hesthaven and Warburton. > > Is there interest in this FE type being available in the library? It > seems like the only change from the standard Lagrange code may be to > just change get_continuity() to return DISCONTINUOUS? > > Thanks, > Dave > >  > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL  plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnowdev2 > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: John Peterson <jwpeterson@gm...>  20120206 23:10:04

On Mon, Feb 6, 2012 at 3:24 PM, David Knezevic <dknezevic@...> wrote: > Hi all, > > I'd like to use a DG version of the Lagrange shape functions. This is > pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" > by Hesthaven and Warburton. What's the main motivation for using the Lagrange basis? Better conditioning than monomials?  John 
From: David Knezevic <dknezevic@se...>  20120206 23:11:43

On 02/06/2012 05:28 PM, Roy Stogner wrote: > > On Mon, 6 Feb 2012, David Knezevic wrote: > >> I'd like to use a DG version of the Lagrange shape functions. This is >> pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" >> by Hesthaven and Warburton. >> >> Is there interest in this FE type being available in the library? > > I'd think so. > >> It seems like the only change from the standard Lagrange code may be >> to just change get_continuity() to return DISCONTINUOUS? > > No; that'll just give you a buggy version of continuous Lagrange FE. > ;) hehe it was worth a shot in the dark > Off the top of my head, you'll also need to move the shape functions > to the Elem off the nodes, and change the n_dofs_on* function > specializations accordingly. OK, that's easy enough. I'll try to make some time for this (unless the INL folks wanna get there first ;). Namingwise, how about DISCONTINUOUS_LAGRANGE (or DISC_LAGRANGE if that's too long)? Dave 
From: John Peterson <jwpeterson@gm...>  20120206 23:15:47

On Mon, Feb 6, 2012 at 4:11 PM, David Knezevic <dknezevic@...> wrote: > > OK, that's easy enough. I'll try to make some time for this (unless the > INL folks wanna get there first ;). Namingwise, how about > DISCONTINUOUS_LAGRANGE (or DISC_LAGRANGE if that's too long)? Either name is fine with me. If you do add a new enum, would you mind fixing the weird indentation on line 37 of enum_fe_family.h too? :)  John 
From: Roy Stogner <roystgnr@ic...>  20120206 23:17:03

On Mon, 6 Feb 2012, David Knezevic wrote: > OK, that's easy enough. I'll try to make some time for this (unless the INL > folks wanna get there first ;). Namingwise, how about DISCONTINUOUS_LAGRANGE > (or DISC_LAGRANGE if that's too long)? We went with L2_HIERARCHIC for the analogous discontinuous version of those elements. (which brings up a point: you might want to check out those sets of svn diffs as well as the differences between the CG and DG versions of those elements, so you won't miss any necessary modifications yourself)  Roy 
From: David Knezevic <dknezevic@se...>  20120206 23:40:23

On 02/06/2012 06:16 PM, Roy Stogner wrote: > > > On Mon, 6 Feb 2012, David Knezevic wrote: > >> OK, that's easy enough. I'll try to make some time for this (unless >> the INL folks wanna get there first ;). Namingwise, how about >> DISCONTINUOUS_LAGRANGE (or DISC_LAGRANGE if that's too long)? > > We went with L2_HIERARCHIC for the analogous discontinuous version of > those elements. OK, L2_LAGRANGE sounds good. > (which brings up a point: you might want to check out those sets of > svn diffs as well as the differences between the CG and DG versions of > those elements, so you won't miss any necessary modifications > yourself) Thanks, I'll have a look. Dave 
From: David Knezevic <dknezevic@se...>  20120206 23:36:40

On 02/06/2012 06:09 PM, John Peterson wrote: > On Mon, Feb 6, 2012 at 3:24 PM, David Knezevic > <dknezevic@...> wrote: >> Hi all, >> >> I'd like to use a DG version of the Lagrange shape functions. This is >> pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" >> by Hesthaven and Warburton. > What's the main motivation for using the Lagrange basis? Better > conditioning than monomials? I'd like to compare to a Matlab DG code which uses (or will use) these L2_LAGRANGE basis functions. These basis functions are important in Matlab because with, say, MONOMIALs, you need to do an L^2 projection to represent f(u_h) in the FE space. The element loop to assemble the righthand side for this projection appears to be a bottleneck in Matlab, especially if you have to do it every timestep. With L2_LAGRANGE you can do interpolation instead of projection. Also, yep, conditioning of L2_LAGRANGE will be better than MONOMIALs for the same order shape functions. But (L2_)LAGRANGE only goes up to cubic and the condition number for cubic MONOMIALs isn't too bad. Dave 
From: John Peterson <jwpeterson@gm...>  20120207 00:46:24

On Mon, Feb 6, 2012 at 4:36 PM, David Knezevic <dknezevic@...> wrote: > On 02/06/2012 06:09 PM, John Peterson wrote: >> >> On Mon, Feb 6, 2012 at 3:24 PM, David Knezevic >> <dknezevic@...> wrote: >>> >>> Hi all, >>> >>> I'd like to use a DG version of the Lagrange shape functions. This is >>> pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" >>> by Hesthaven and Warburton. >> >> What's the main motivation for using the Lagrange basis? Better >> conditioning than monomials? > > > I'd like to compare to a Matlab DG code which uses (or will use) these > L2_LAGRANGE basis functions. These basis functions are important in Matlab > because with, say, MONOMIALs, you need to do an L^2 projection to represent > f(u_h) in the FE space. The element loop to assemble the righthand side for > this projection appears to be a bottleneck in Matlab, especially if you have > to do it every timestep. With L2_LAGRANGE you can do interpolation instead > of projection. Oh, that sounds like a good idea actually... > Also, yep, conditioning of L2_LAGRANGE will be better than MONOMIALs for the > same order shape functions. But (L2_)LAGRANGE only goes up to cubic and the > condition number for cubic MONOMIALs isn't too bad. We could probably add higher orders too if this is determined to be useful... I assume you can directly call the continuous LAGRANGE shape() and shape_deriv() functions for the discontinuous family?  John 
From: David Knezevic <dknezevic@se...>  20120207 00:54:32

On 02/06/2012 07:45 PM, John Peterson wrote: > On Mon, Feb 6, 2012 at 4:36 PM, David Knezevic > <dknezevic@...> wrote: >> On 02/06/2012 06:09 PM, John Peterson wrote: >>> On Mon, Feb 6, 2012 at 3:24 PM, David Knezevic >>> <dknezevic@...> wrote: >>>> Hi all, >>>> >>>> I'd like to use a DG version of the Lagrange shape functions. This is >>>> pursued, for example, in the book "Nodal Discontinuous Galerkin Methods" >>>> by Hesthaven and Warburton. >>> What's the main motivation for using the Lagrange basis? Better >>> conditioning than monomials? >> >> I'd like to compare to a Matlab DG code which uses (or will use) these >> L2_LAGRANGE basis functions. These basis functions are important in Matlab >> because with, say, MONOMIALs, you need to do an L^2 projection to represent >> f(u_h) in the FE space. The element loop to assemble the righthand side for >> this projection appears to be a bottleneck in Matlab, especially if you have >> to do it every timestep. With L2_LAGRANGE you can do interpolation instead >> of projection. > Oh, that sounds like a good idea actually... > >> Also, yep, conditioning of L2_LAGRANGE will be better than MONOMIALs for the >> same order shape functions. But (L2_)LAGRANGE only goes up to cubic and the >> condition number for cubic MONOMIALs isn't too bad. > We could probably add higher orders too if this is determined to be useful... I guess the one thing to be careful about is equispaced points aren't very good for high order (Runge's phenomenon et al.), but as usual they'd be fine for reasonably low order. The book I mentioned earlier discusses how to construct Chebyshevlike nodal locations on simplices, and they go up to 24^th order polynomials or so. > I assume you can directly call the continuous LAGRANGE shape() and > shape_deriv() functions for the discontinuous family? Yep, that should be identical. I guess the only change is in the number of global dofs and the dof numbering, which would be taken care of by Roy's suggestion of associating dofs to elements rather than nodes. Dave 
Sign up for the SourceForge newsletter:
No, thanks