fixes for builds with no raja or umpire #1270
Conversation
| @@ -267,17 +271,29 @@ axom::Array<DoF, 2, axom::MemorySpace::Host> GetElementRestriction(const mfem::F | |||
| } | |||
|
|
|||
| if (n == 0) { | |||
| #ifdef SERAC_USE_RAJA | |||
There was a problem hiding this comment.
I think this should be SERAC_USE_UMPIRE
There was a problem hiding this comment.
Yeah makes sense, basically all of the axom::MemorySpace::Host stuff needs to be fixed.
ebchin
changed the title
| void write_to_file(axom::Array<T, 2, axom::MemorySpace::Host> arr, std::string filename) | ||
| #else |
There was a problem hiding this comment.
You would think that Host would always be there but its guarded in axom and Dynamic is the one unguarded....
There was a problem hiding this comment.
Seems like host should be safe to unguard in addition to dynamic? Regardless, we could use dynamic + umpire allocator IDs to achieve the same without the clunky #ifdef blocks. Though we would lose the explicit typing of the memory. Thoughts?
There was a problem hiding this comment.
I say go with Dynamic for now to avoid the ifdef's... but this really needs to be revisited. Might need to chat with Axom about this.
There was a problem hiding this comment.
@white238 and I spoke -- it makes sense to go with (the default) Dynamic
|
Should we test this in CI? Maybe in Azure? |
We probably don't want to get into all of the combinatorics, but I see the value in adding a CI test with minimal TPLs, just to check stuff like this. |
I tried building serac without RAJA or Umpire and found some code that needs some
#ifdefmacros around it. This PR adds them.