Enhance CurvedPolygon so WN memoization works with sampling shaper #1672
Conversation
primal::CurvedPolygon so WN memoization works with sampling shaper…ure/spainhour/sampling_shaper_memoization
There was a problem hiding this comment.
Looks reasonable so far.
Lingering questions for this PR include:
-
Many operations on a CurvedPolygon are forbidden at compile time (e.g. split and reverseOrientation) to ensure that the GWN cache is not made invalid. Is this the right approach? Or should the methods be allowed after the cache is cleared, and a warning message displayed to inform the user that this has happened?
- Seems reasonable to start by disallowing these operations (as long as this is documented) since invalidating the cache can have severe performance costs. If we need to allow this in the future, we can add support for it.
-
Some template boilerplate is required in CurvedPolygon.hpp to deduce the numeric type from the curve type. Is this implemented in the right way? Should those template methods be in a detail file?
- I'd leave it as is since it's reasonably self contained. Perhaps move it inside an anonymous namespace or a
detailnamespace (within the same file)?
- I'd leave it as is since it's reasonably self contained. Perhaps move it inside an anonymous namespace or a
…/spainhour/sampling_shaper_memoization
…/spainhour/sampling_shaper_memoization
…://github.com/LLNL/axom into feature/spainhour/sampling_shaper_memoization
…/spainhour/sampling_shaper_memoization
…/spainhour/sampling_shaper_memoization
…/spainhour/sampling_shaper_memoization
| template <typename Lambda, typename T, int NDIMS> | ||
| double evaluate_vector_line_integral(const axom::Array<primal::NURBSCurve<T, NDIMS>>& narray, | ||
| template <typename Lambda, typename CurveType> | ||
| double evaluate_vector_line_integral(const axom::Array<CurveType>& carray, |
There was a problem hiding this comment.
Possible generalization for the future -- perhaps the exposed API should use axom::ArrayView instead of axom::Array ?
Thanks for adding the performance improvement. Could you please also adding the performance change for a Release config? |
This PR will be merged after #1683.
Summary
In order that the SamplingShaper in quest is compatible with recent GWN accelerations via memoization, the
primal::CurvedPolygon<T, NDIMS>class is enhanced so that it is templated directly on curve type, i.e.primal::CurvedPolygon<CurveType>. Currently supported curve types areBezierCurve,NURBSCurve, and the newNURBSCurveGWNCache. BecauseCurvedPolygonis used in many of primal's operators, this requires many updates:in_curved_polygonhave been made compatible with all curve types.compute_moments.hppare currently only compatible withCurvedPolygon<BezierCurve<T, 2>>, since the methods within expect Bezier curves, and would require a non-trivial extension to work onNURBSCurveobjects via Bezier extraction.The tests for these methods are updated in their respective suites to ensure compatibility with the new template.
On the quest side of things, this PR makes the following changes related to SamplingShaper
MFEMReaderso that the default input for an MFEM mesh is aCurvedPolygon<NURBS>instead of Bezier.WindingNumberSamper.hppso that the sampler stores an array of "cached contours," i.e.CurvedPolygon<NURBSCurveGWNCache>instead of a view ofCurvedPolygon<BezierCurve>s.Performance Improvements
These changes reduce the time to complete the test
quest_shaping_driver_ex_heroic_roses_mfem_cpfrom 85.93 seconds on a debug build ofdevelopto 56.68 seconds (or from 12.67s to 6.91s on a release build) on the current branch. Accounting for the time to process the curves and construct/access the BVH (~31.31s debug/~4.47s release) this is about a 2x improvement.