NodesAndModes.jl is a package to compute “nodes” (interpolation and quadrature points) and “modes” (orthogonal polynomials) on various reference elements for use in high order finite element or discontinuous Galerkin methods.
The codes are partially inspired by the Matlab codes for the book “Nodal Discontinuous Galerkin methods” by Hesthaven and Warburton (2007), but provides support for more types of reference elements. In particular, we provide nodes and modes with a unified interface for
1D lines/intervals
2D triangles
2D quadrilaterals
3D tetrahedra
3D hexahedra
3D wedges/prisms
3D pyramids
I’d welcome any feedback - the CI and documentation may be a little rough, since I learned them on the fly and added them after I wrote most of the package.
Nice work!. I just find a little odd, the use of “using NodesAndModes.Shape” as a way to select different reference elements. It makes a little difficult to use multiple reference elements in the same code.I wonder if would be better to export some reference element structs like Line, Triangle and then you could call: nodes(Line()) or vandermore(Line(), …), vandermore(Triangle(),…), etc.
Hm, that makes sense. The submodule structure is a carry-over from my pre-Julia habits. I was just planning on using submodule namespaces to specialize to an element type since you can pass modules around, but the element type structs seem a little more Julian.
I’ve opened an issue to switch to a type-based approach before we release 1.0. Since everything’s pretty specialized to the element shape, I don’t think it’s going to simplify the structure of the code much, but hopefully makes it easier to call.
That was a really nice suggestion. The code and documentation is much shorter and more easily contained (changes in branch). Just need to propagate the changes downstream before merging.
Marking this down in my head as the more “Julian” way to do things…
Funny note - yes, though indirectly. A collaborator and I submitted a grant related to this package (more advanced functionality), and @santiagobadia was kind enough to write a letter of support.
The most recent round of changes were b/c my own research group needed some functionality and bugs fixed, so I wasn’t thinking of Gridap.jl. However, I was planning on contacting @fverdugo eventually after the package stabilized, so I appreciate the reminder .
Using your machinery in a FE computation, including DG, should be pretty straightforward with Gridap. You only need to specialize some well defined interfaces. I can give some hints if needed.
In any case, i think that the improvements mentioned above regarding using structs rather than modules would also simplify the coupling.
.