CellDiameter not defined for higher-order cells
When using P2 geometry, CellDiameter raises a warning in UFL followed by an error in ffc:
WARNING:UFL:Only know how to compute cell diameter of P1 or Q1 cell.
".../access.py", line 66, in get
raise RuntimeError("Not handled: {}".format(type(e)))
RuntimeError: Not handled: <class 'ufl.geometry.CellDiameter'>
It is useful to have an estimate of the "cell diameter", even if it is not the actual length of an edge, but just the distance between vertices.
Should this be calculated in ffc, or ufl? Should it still be called CellDiameter?
Should this a UFL issue?
This is rather an UFL issue, CellDiameter should get interpreted in UFL during apply_geometry_lowering. We can also generate a code for it in FFC, but a solution in UFL would be more clean.
I'm not sure if it is best treated in ufl or not. Currently ufl refuses to process it. There is a comment passing it on to the form compiler. Also there is a comment in ffc saying it may be better to code in ffc, than use geometric lowering in ufl.
Yes, but keep it consistent. Linear in UFL and other in FFC is weird. Also, only very few quantities are "lowered" in FFC, so this decision need to be discussed.
To compute non-affine geometric quantities needs more information than UFL can provide I think: arguably the right thing to do is to let the form compiler compute it (even in the affine case). Since it is not necessarily the case that the implementation UFL provides is optimal.
A follow up. A general approach would be to find the convex hull of the element and then compute the diameter of that. For general curvilinear polytopes finding the minimal convex hull is hard, however, if you represent the surface with Bezier splines then you can use the convex hull property of Bezier curves to bound the actual convex hull by the convex hull of the control points. Then one can apply standard algorithms to find the diameter.