Initial MIR component #1438
Initial MIR component #1438
Conversation
data
Outdated
There was a problem hiding this comment.
@BradWhitlock -- Will there be an axom_data PR associated with this PR?
There was a problem hiding this comment.
Yes. I added a few YAML files for some CI test results. I made a PR for the test baselines.
| if args.ninja: | ||
| cmakeline += ' -G "Ninja"' | ||
|
|
src/axom/CMakeLists.txt
Outdated
| # Add MIR if the prerequisites are found. | ||
| if(RAJA_FOUND AND UMPIRE_FOUND AND CONDUIT_FOUND) | ||
| axom_add_component(COMPONENT_NAME mir | ||
| DEFAULT_STATE ${AXOM_ENABLE_ALL_COMPONENTS}) | ||
| else() | ||
| message(STATUS "Axom Component MIR turned off due to missing RAJA, UMPIRE, or Conduit.") | ||
| set(AXOM_ENABLE_MIR OFF CACHE BOOL "") | ||
| endif() |
There was a problem hiding this comment.
This is different than how we handle missing deps in other components. E.g. sidre has a hard dependency on conduit (and inlet and klee depend on sidre), but we don't enforce this at the add_component level.
It might be a good idea to revisit that choice, but I think we should be consistent across the components.
There was a problem hiding this comment.
@kennyweiss - I am making a change to add mir always via axom_add_component. It does fail during configuration when requirements such as RAJA or Conduit are not present. That's what we want. Unfortunately, that makes host-configs such as [email protected] fail to build Axom. That feels like a step backwards. In cases like that, I'm planning to add an explicit set(AXOM_ENABLE_MIR FALSE CACHE BOOL "") so these host-configs continue to work. Any objections?
There was a problem hiding this comment.
Oops. That host-config is just something I have locally. If there is a versioned host-config that lacks MIR required libraries, the plan is to add set(AXOM_ENABLE_MIR FALSE CACHE BOOL "").
There was a problem hiding this comment.
I ended up adding MIR always (in the style of other components) and then adjusted a few CI builds so they pass -DAXOM_ENABLE_MIR:BOOL=OFF if they lack the required tpls.
| AXOM_HOST_DEVICE T* data() noexcept { return &m_data[0]; } | ||
| AXOM_HOST_DEVICE const T* data() const noexcept { return &m_data[0]; } |
There was a problem hiding this comment.
Since these have the same return type/value as operator T*, I assume they're necessary for consistency w/ an expected interface
Should the const overload be marked as constexpr?
src/axom/core/execution/scans.hpp
Outdated
There was a problem hiding this comment.
These are really nice! We can probably use them in several places throughout axom.
…hen we do not have umpire.
| using MaterialID = int; | ||
| using MaterialIDArray = axom::Array<MaterialID>; | ||
| using MaterialIDView = axom::ArrayView<MaterialID>; | ||
| using MaterialVF = float; |
There was a problem hiding this comment.
Is float a design choice over double?
There was a problem hiding this comment.
Yes, but I think I could change it to use the material view's FloatType for MaterialVF so it stays true to the types specified in the material view. I think I had some compiler problems in this code but I could try again.
This PR is adds an initial MIR component to Axom. EquiZ MIR was implemented as the first algorithm because it was more familiar and my first goal was to shake out problems with infrastructure for writing algorithms against Blueprint data. The MIR algorithm takes Blueprint input and generates Blueprint output.
This PR does the following:
NOTE: