-
assigned issue to
Rename point integral to vertex integral in dolfin/ufl/ffc/ufc
All other integrals have consistent naming across ufl/ufc/ffc/assembler, and this one exception is in the way for generalizing code on the form 'for integral_type in ("cell", "point", ...)'.
I vote for using 'vertex' for the current feature and reserve 'point' to mean arbitrary points within cells in a future implementation.
@johanhake @meg @pefarrell feel free to comment.
Comments (19)
-
reporter -
The name is not important. If I recall correctly we picked the name such that it could be used for both Vertices and arbitrary points.
If you choose to change the name maybe you can also change
PointIntegralSolver
toVertexIntegralSolver
? -
reporter Ok!
-
Is it really a
VertexIntegralSolver
, or more a LagrangeNodeIntegralSolver
, i.e. solves problems at cell 'nodes'? -
What is the difference between solving problems at cell nodes and vertices?
You have a point about Lagrange, as we only accept problems formulated with CG1 test functions.
-
Vertices are vertices of triangle, etc. 'nodes' are where dofs live, e.g. vertices and side midpoints for P2 elements.
-
reporter I think it's easily generalisable from vertices to nodes. Maybe "node integral" then?
-
Node integral sounds ok, but a comment is needed if this only works for Lagrange nodes.
-
reporter I think Lagrange only, I think a core property of this functionality is that there is one basis function from the global test space that is 1.0 at each node and the rest is 0.0.
However a different generalisation of vertex integrals I've been thinking about is to treat them as cell integrals over 0d vertex cells embedded in Nd.
Does anyone need a node integral solver?
-
Isn't the essential property that we have a nodal basis? It doesn't need to be Lagrange. For all element types we have a basis that satisfies that exactly one dof evaluates to 1 for each basis function so it could well be that the dofs happen to be say tangential component at a point, or some integral moment.
-
Note, FWIW, that EnrichedElements are not nodal (since the basis is not reorthogonalised).
-
reporter I don't know, sounds correct. Still, does anyone need it or is this just a discussion for the sake of it?
However the point/vertex integral is a sum over a set of point coordinates (currently the vertices). From an implementation point of view, the set of dof coordinates can be used without caring about the type of nodal functional. However I don't know if it makes sense. And again, does anyone need it?
In this issue I just proposed a renaming here to enable convenient generalization in some code snippets that does 'if integral type = "point": dosomething("vertex")'.
-
I don't need it for anything right now. Just pointing out that NodeIntegral seems like a good name for it since it actually might work for other nodes than only Lagrange point evaluation.
-
As far as I remember, it is currently only supported for vertices. The work "point" reflects "point measure" as in point evaluation, "vertex measure" sounds less familiar, but I don't mind that being changed.
We are currently actively using the point measure/integral/solver for CG1. A potentially relevant extension would be evaluation in quadrature points (rather than more general dofs), but this is not needed for our applications in the near future.
-
reporter Just to clarify one thing here: one of the main reasons we need different names for (i) arbitrary points vs (ii) vertices/nodes, is that the code generation will be different to exploit precomputation of basis functions in (ii).
Also note that (i) is very close to custom integrals, and we have a use case for that which is why I want it.
-
reporter - marked as minor
-
reporter in next
-
reporter - changed status to resolved
I've renamed point integral but kept *dP and not renamed PointIntegralSolver.
-
reporter - removed milestone
Removing milestone: 1.6 (automated comment)
- Log in to comment