Move some Axom Blueprint functionality into BUMP component.#1586
Conversation
…th SLAM template parameters.
…ed usage accordingly.
Arlie-Capps
left a comment
There was a problem hiding this comment.
Thanks, Brad. I appreciate that Bump is its own component now. I appreciate your care with the docs, too.
| axom_add_component(COMPONENT_NAME slam DEFAULT_STATE ${AXOM_ENABLE_ALL_COMPONENTS}) | ||
| axom_add_component(COMPONENT_NAME primal DEFAULT_STATE ${AXOM_ENABLE_ALL_COMPONENTS}) | ||
| axom_add_component(COMPONENT_NAME sidre DEFAULT_STATE ${AXOM_ENABLE_ALL_COMPONENTS}) | ||
| axom_add_component(COMPONENT_NAME bump DEFAULT_STATE ${AXOM_ENABLE_ALL_COMPONENTS}) |
There was a problem hiding this comment.
@LLNL/axom General question independent of this PR: is the ordering of axom_add_component calls intended to represent strict dependencies among Axom components? If so, then I think this needs some re-assessment.
There was a problem hiding this comment.
That's what it looked like to me. Would alphabetical be better? I moved bump/mir to after spin.
There was a problem hiding this comment.
Initially, I was thinking alphabetical would make it easier to keep track of, but the comment before the add component calls implies that ordering matters. We can discuss at the Axom meeting today.
There was a problem hiding this comment.
I think it might need to be sorted by dependencies (e.g. a topological sort) since the axom_component_requires macro lists the component dependencies, e.g.
| # Check necessary dependencies | ||
| #------------------------------------------------------------------------------ | ||
| axom_component_requires(NAME BUMP | ||
| COMPONENTS SLIC SLAM PRIMAL |
There was a problem hiding this comment.
@BradWhitlock follow-up to my comment above....if this line indicates the Axom dependencies for bump, then shoudln't the axom_add_component call for bump come before the axom_add_component call for sidre?
There was a problem hiding this comment.
I moved bump/mir to after spin in that list of axom_add_component calls.
There was a problem hiding this comment.
Aaaand it looks like I need to add spin there.
kennyweiss
left a comment
There was a problem hiding this comment.
Thanks @BradWhitlock -- this is going to be a really useful component for blueprint-related workflows.
Please don't forget to update the RELEASE_NOTES before merging.
There was a problem hiding this comment.
Would it make sense to move these conversion types up to sidre?
(They're ok here too).
…C macro. Renamed visit namespace to tables.
Much infrastructure for processing Blueprint meshes was developed during the course of MIR development. These features are generally useful outside of MIR so they have been refactored into a new Axom component called "BUMP" - Blueprint Utilities for Mesh Processing.
Additional future work (future PR) remains to consolidate Blueprint-related code (e.g. from quest) into BUMP, and possibly make BUMP more Sidre-compatible.