Enhance SamplingShaper so it can work on low order Blueprint meshes - #1875
Enhance SamplingShaper so it can work on low order Blueprint meshes#1875BradWhitlock wants to merge 96 commits into
Conversation
…s in shaping driver for Blueprint meshes.
…github.com:llnl/axom into feature/whitlock/sampling_low_order_blueprint_mesh
…ing. Also move some times and add a new one.
…github.com:llnl/axom into feature/whitlock/sampling_low_order_blueprint_mesh
| return it->second; | ||
| } | ||
|
|
||
| void compute_interpolatory_weights(const axom::Array<double>& nodes, |
There was a problem hiding this comment.
I think this method could use a brief doxygen header to explain what it does, even if it isn't user-facing.
| for(int npts = 1; npts <= maxNpts; ++npts) | ||
| { | ||
| const auto rule = getRule(npts); | ||
| const int exactDegree = getExactDegree(npts); |
There was a problem hiding this comment.
Now that there's a lot of quadrature rules to keep track of, do you think it's generally useful enough to have a helper function like get_exact_degree(numerics::QuadartureType, npts)? Even if it isn't necessary to actually execute it most of the time, its source code could provide a useful compendium of which rules evaluate which order polynomials.
There was a problem hiding this comment.
I had codex move code into a get_exact_degree helper function and update the tests.
|
|
||
| assert("Unhandled Axom quadrature type." && false); | ||
| return 2 * npts - 1; | ||
| } |
There was a problem hiding this comment.
This is very helpful, thank you!
| * \param allocator_id The allocator id to use when allocating new coordinate memory. | ||
| */ | ||
| static void execute(conduit::Node &n_coordset, | ||
| int allocator_id = axom::execution_space<ExecSpace>::allocatorID()) |
There was a problem hiding this comment.
This is maybe a dumb question, but when would I want to use this method instead of the one I was using before in axom::bump::views::make_explicit_coordset? Is it because this one gets done in place?
There was a problem hiding this comment.
axom::bump::views::make_explicit_coordset makes a view of an existing explicit coordset whereas MakeExplicitCoordset takes a conduit::Node containing some other coordset type and converts it into an explicit coordset (it might do some work and data allocation).
| */ | ||
| QuadratureRule get_quadrature_rule(QuadratureType quadratureType, | ||
| int npts, | ||
| int allocatorID = axom::getDefaultAllocatorID()); |
There was a problem hiding this comment.
Some functions here are missing Doxygen comments for allocatorID param.
| public: | ||
| AXOM_HOST_DEVICE function() : invoke(nullptr) { } | ||
|
|
||
| /** |
There was a problem hiding this comment.
Do we want to preserve the some of the doxygen comment blocks being deleted in this file here?
There was a problem hiding this comment.
I'll add that back in. Codex was needlessly aggressive about trying to remove doxygen comments. This may have been before I complained to it.
| } | ||
| } | ||
| template <typename MeshState> | ||
| void checkSampleResolution(const MeshState& meshState, |
There was a problem hiding this comment.
Doxygen comment here for consistency.
| void deleteShapeFunction(const std::string& AXOM_UNUSED_PARAM(name)) | ||
| { | ||
| // TODO: remove the function from m_inoutShapeQFuncs if it exists. | ||
| } |
There was a problem hiding this comment.
Does this still need to be resolved?
| axom::ArrayView<int> sampleResolution, | ||
| axom::numerics::QuadratureType quadratureType); | ||
|
|
||
| void computeVolumeFractionsIdentity(mfem::DataCollection* dc, |
There was a problem hiding this comment.
Doxygen comment here for consistency
3 participants
This PR resolves #1692 so the
quest::SamplingShapercan operate on Blueprint low order meshes.SamplingShaperMFEM state into a state object that can be used among helper routinesBlueprintStateobject to support Blueprint stateSamplingShapercan be built when either MFEM or Conduit (or both) are present -- enables a shaper that works without MFEMconduit::Nodeor viasidre::Group.