specify quadrature
See original GitHub issueOne of the things arising from the recent investigation into the poor behaviour of elastic modal analysis with ElementTetP1
#75 was the idea of reduced quadrature; e.g. in discussing ElementHex1
, Petyt (1990, Introduction to Finite Element Vibration Analysis, Cambridge University Press, §5.8) recommends a rule with one abscissa at the centroid. Reduced quadrature or ‘selective integration’ is also discussed by
- Benzley, S. E., Perry, E., Merkley, K., Clark, B. & Sjaardema, G. (1995). A comparison of all hexagonal and all tetrahedral finite element meshes for elastic and elasto-plastic analysis. In T. Tautges (ed.), In Proceedings, 4th International Meshing Roundtable (pp. 179–191).
although their practical recommendation is for increasing the order of the element as done here in #322.
Currently I don’t see an easy way to experiment with quadrature in scikit-fem. I think though that enabling this would be simple generalization of the constructor for skfem.assembly.Basis
.
or maybe
(and similarly for FacetBasis
) so that either one specifies:
- the actual quadrature rule, i.e.
X
andW
which become attributes of theInteriorBasis
, or intorder: int
as now, and the rule is computed fromskfem.quadrature.get_quadrature
, or- nothing, also as now, and
intorder
is computed fromself.elem.maxdeg
.
A possible further modification is that the type of the rule returned by get_quadrature
is Tuple[ndarray, ndarray]
from which it is unclear which is weights and which abscissae. Perhaps a quadrature rule might be represented as in quadpy.nsimplex._helpers.NSimplexScheme
as an object with attributes weights
and points
, or more simply as a NamedTuple
(or dataclass
) with similarly named attributes; given Python’s duck-typing, reference from within skfem.assembly
only to attributes weights
and points
might enable direct use of one of the many schemes from quadpy while only importing it at the top-level user-script in which the basis is instantiated.
I don’t think that this is urgent—I don’t have any immediate plans to use it myself—but it seems like an easy addition and something that should be present in a general finite element library. I think it’s mostly a matter of deciding on the desired syntax.
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
Nevertheless, I still don’t oppose using these representations in
skfem.quadrature
. I think it pays off in the long term to be compatible with other packages in the ecosystem.I wonder whether multiple inheritance would help here; e.g. deriving
MeshTet
fromMeshSimplex
as well asMesh3D
.