Support Blueprint mesh in shaping #1455
Conversation
This version compiles without MFEM, if conduit is supported. But it doesn't run because the conduit side is not fully written yet.
GridFunctionView is renamed TempArrayView to reflect that it doesn't work with just GridFunctions.
…memory' into feature/gunney/blueprint-mesh-shaping
The feature was never used and we are moving away from MFEM mesh in favor of blueprint mesh.
Add blueprint support to shaper code and test code.
The code required what to Blueprint was optional.
Facilitated by ability to reshape array data in sidre Views.
Also add code to save results for visualization.
gunney1
force-pushed
the
feature/gunney/blueprint-mesh-shaping
branch
from
364b7b2 to
97b531c
Compare
| , m_bpNodeExt(nullptr) | ||
| , m_bpNodeInt() | ||
| #endif | ||
| , m_comm(MPI_COMM_WORLD) |
There was a problem hiding this comment.
Maybe outside the scope of this PR but in the CMakeLists.txt, there are some files that are only enabled when AXOM_USE_MPI is enabled. This file is always enabled and it contains the m_comm member. Can quest build without MPI? It looked like before the communicator was mostly accessed through the MFEM data collection.
There was a problem hiding this comment.
Quest can build without MPI -- but it uses a fake comm in those cases (which is apparently hidden in an obscure location :) )
See: https://github.com/LLNL/axom/blob/develop/src/axom/quest/interface/internal/mpicomm_wrapper.hpp
(As I recall, this was seen as a one-off at the time, and @white238 was hoping to work on an MPI wrapper component.)
There was a problem hiding this comment.
Ah, didn't know about the MPI_Comm wrapper.
| auto order = mapping.getStrideOrder(); | ||
| if(int(order) & int(axom::ArrayStrideOrder::COLUMN)) | ||
| { | ||
| RAJA::kernel<EXEC_POL>( |
There was a problem hiding this comment.
Looks like we need variadic axom::for_all() - or overloads.
There was a problem hiding this comment.
Thanks @gunney1
- The Shaper classes are getting pretty complicated, which indicates that we probably need to redesign them to support all the cases we care about in a cleaner way. Since you're planning follow-up PRs, I'm ok with this happening in the future, but we should think this through before it gets too complicated.
- Also, can you please explain why Umpire is needed for all shapers, even if we're only using the CPU? Is there a way to use Axom's memory abstraction to avoid this requirement?
- There are a lot of small utility functions that are added/modified throughout. Please consider adding unit tests for these, as appropriate
- One cleanup note:
sidrealways depends onconduit, so if we have a file that usessidrewithout checking ifAXOM_USE_SIDRE, then it is safe to assume that conduit is available without guards.
Motivation
IntersectionShapercurrently support only MFEM mesh. That was due to convenience when the class was developed.IntersectionShaperdoesn't make any use of any features not supported by Blueprint. We need to support Blueprint mesh, as that is the standard for LLNL.Summary
IntersectionShaperand the shaper in-memory shape tests #1452IntersectionShaper. This largely consists ofconduit::Nodeorsidre::Group.mfem::GridFunction*withaxom::ArrayView<double>as a means of handling cell-centered data.quest_shape_in_memory.cpp) to test the Blueprint mesh support.Planned follow-up.
To keep this PR and its companion as as small as possible, I avoided moving code around too much. As a result the code is a bit messy. Issue #1445 tracks the planned follow-on work.