[ML] integration for triangles with 7 IPs

[FZill]

Added Gauss-Legendre Integration for Triangles with 7 Integration Points.
Necessary to output secondary variables at least in HM.
We might change the integration order to 5 as in the reference, but I opted for 4 as it is the 4th option available.
Values are from here (Appendix II, p=5):
Dunavant, D. A. "High degree efficient symmetrical Gaussian quadrature rules for the triangle." International journal for numerical methods in engineering 21.6 (1985): 1129-1148.
URL: https://onlinelibrary.wiley.com/doi/epdf/10.1002/nme.1620210612

[x] Feature description was added to the changelog

[endJunction]

It would be nice if the commit message would include the detailed PR-description.

Formatting.

[wenqing]

👍
It would be nice to include a ctest.

[FZill]

Found another source with more decimal places -> updated the values.
Also made a simple plausibility test with rectangular vs. triangular elements. The results compare reasonably well. A ctest verifying the integration point positions and weights is for a future PR.

[ThieJan]

Necessary to output secondary variables at least in HM.

Just curious: Is this the reason to select a higher integration order?

[FZill]

@ThieJan The extrapolation is not possible with fewer integration points than nodes. The secondary variable output was just the reason for me to implement it, because the HM process needs quadratic elements and thus I couldnt simulate HM with triangular elements with the secondary variable output.

[ThieJan]

@FZill
The used extrapolation algorithm does not work if there are less integration points than nodes. Obviously this is a shortcoming of the selected method.

However, I would not have used a higher integration order as work-around:

• more possibly non-linear material models to solve
• more material states to store

[FZill]

@ThieJan You have a point there, but this was just now an easier solution instead of implementing a new extrapolator. But it is indeed a good idea to implement that in the future.

[ThieJan]

I see. This solution surprised me. It is beyond my creativity :-)

To get a clue on the stresses I recently added a averaged output for the RM process. Probably a bad idea doing it hard coded into the process (#2784). Would be nice to move it to the output classes and make it selectable in the prj output definition.

[endJunction]

@ThieJan Fully agree with the extrapolation/interpolation suggestion to move it out of the classes.

[wenqing]

One idea for future improvement of the extrapolation method:

1. Extrapolate integration point values to vertex nodes of element with the current method,
2. Interpolate vertex node values to edges nodes on element edges if the element is higher order.

By this way, the criterion becomes that the number of integration points must not be less than the number of vertexes of an element. This is satisfied with the integration schemes of all existed element types, and makes one be free to choose the integration order.

[ogsbot]

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.