Evaluate surface and volume integrals over Bezier and NURBS patches

[kennyweiss]

Summary

• This PR is a feature
• It add primal::evaluate_surface_integral and primal::evaluate_volume_integral functions for integrands over collections of BezierPatch and NURBSPatch objects
• This is an implementation of the algorithm from "High-Accuracy Mesh-Free Quadrature for Trimmed Parametric Surfaces and Volumes" by D. Gunderman, K. Weiss and J. Evans in Computer-Aided Design 2021. https://doi.org/10.1016/j.cad.2021.103093.
• Also adds an example that evaluates surface- and volume- moments over a BRep defined in a STEP model, and computes a best-fit ellipsoid and oriented bounding box to the model based on its mass, centroid and moments of inertia.
  • Here is an inertia-matched ellipsoid to the connector.step model
    

[jcs15c]

Looks good to me! Minor thing with the new biquartic_sphere.step in axom data, but otherwise the math looks sound.

[kennyweiss]

Looks good to me! Minor thing with the new biquartic_sphere.step in axom data, but otherwise the math looks sound.

Thanks -- I'll update it

Edit: Done.

[jcs15c]

I know I already approved these changes, but I'm wondering now if there's something inherently circular about these includes. Currently, NURBSPatch objects call evaluate_area_integral on their trimming curves, which means NURBSPatch.hpp should technically include evaluate_integral.hpp, which seems like it would conflict with this include here.

This doesn't seem to be an issue right now, since NURBSPatch is somehow able to find the relevant definition for evaluate_area_integral without the correct include, but on my new branch #1834 something changed to make the include tree more picky, and now it can't find the function anymore. Still working on a fix there The fix was fixing a bug where CurvedPolygon included NURBSPatch, but there still might be an issue for whoever's PR gets merged second.

There was a similar issue with the winding number methods, which we resolved by having a winding_number.hpp file containing the interface to 2D and 3D methods, and then separate winding_number_2d_impl.hpp and winding_number_3d_impl.hpp files. Do you anticipate that we would eventually need something here too, with separate evaluate_integral_curve_impl.hpp and evaluate_integral_surface_impl.hpp files, either here or in a later PR?

[kennyweiss]

Great catch! Fixed.