Initial 2D intersection shaping #1509
Conversation
…nd sidre (no mfem yet). Includes adding 2D support for blueprint box mesh generation, reading 2D coordinates from blueprint in IntersectionShaper, allowing Shaper constructor to convert structured to unstructured in 2D, using BoxDim to switch between 2D and 3D in-memory quest example.
bmhan12
added
Quest
bmhan12
requested review from
BradWhitlock,
kennyweiss,
nselliott,
publixsubfan,
ltaylor16 and
gunney1
| /* | ||
| Constructing a mint mesh from meshGrp fails unless we add some | ||
| extra data. Blueprint doesn't require this extra data. (The mesh | ||
| passes conduit's Blueprint verification.) This should be fixed, | ||
| or we should write better blueprint support utilities. | ||
| */ | ||
| /* | ||
| Make the coordinate arrays 2D to use mint::Mesh. | ||
| For some reason, mint::Mesh requires the arrays to be | ||
| 2D, even though the second dimension is always 1. | ||
| */ |
| # steel triangle: star composed of 16 right triangles with | ||
| # leg length 0.25 has analytic volume 0.5 | ||
| set_tests_properties(${_testname} PROPERTIES | ||
| PASS_REGULAR_EXPRESSION "Volume of material 'steel' is 0.5") |
|
|
||
| // Get the coordinates for the vertices | ||
| for(int j = 0; j < NUM_VERTS_PER_HEX; ++j) | ||
| // This runs only only on host, because the mfem::Mesh only uses host memory, I think. |
There was a problem hiding this comment.
I don't think Axom currently tests an mfem+{cuda,hip} configuration.
We could add one and make the mfem::Mesh use device memory if/when necessary.
There was a problem hiding this comment.
I don't think Axom currently tests an mfem+{cuda,hip} configuration.
Definitely good to have enabled, captured this task in issue #1514 .
| volView[cellIdx] = hexesView[cellIdx].volume(); | ||
| }); | ||
| // Set vertex coords to zero if within threshold. | ||
| // (I don't know why we do this. I'm following examples.) |
There was a problem hiding this comment.
It is sort of strange to only snap for coordinates near zero.
Anyone have thoughts/context?
We probably shouldn't check this comment in though :)
There was a problem hiding this comment.
It is sort of strange to only snap for coordinates near zero.
I made a comment about it here.
I don't think these "snaps" are needed, and have removed them from quest_shape_in_memory.cpp and IntersectionShaper.cpp
| axom::sidre::Group* make_structured_blueprint_box_mesh_2d( | ||
| axom::sidre::Group* meshGrp, | ||
| const primal::BoundingBox<double, 2>& bbox, | ||
| const NumericArray<int, 2>& res, | ||
| const std::string& topologyName = "mesh", | ||
| const std::string& coordsetName = "coords", | ||
| axom::runtime_policy::Policy runtimePolicy = axom::runtime_policy::Policy::seq); | ||
|
|
||
| axom::sidre::Group* make_unstructured_blueprint_box_mesh_2d( | ||
| axom::sidre::Group* meshGrp, | ||
| const primal::BoundingBox<double, 2>& bbox, | ||
| const NumericArray<int, 2>& res, | ||
| const std::string& topologyName = "mesh", | ||
| const std::string& coordsetName = "coords", | ||
| axom::runtime_policy::Policy runtimePolicy = axom::runtime_policy::Policy::seq); |
There was a problem hiding this comment.
This function is declared identically twice.
There was a problem hiding this comment.
These are both necessary, one is for unstructured and the other for structured mesh generation (though I agree the names are very similar).
This PR:
stlmesh of triangles (0 for z-coordinates) or a 2D in-memory triangle blueprint mesh.quest_shape_in_memory.cppmodified to support a 2D in-memory triangle mesh (create2DShapeSet).mesh_helpersfor generation of 2D quad meshes using mfem/sidre/blueprintstlmesh for testing.shaping_driver.cppwhere policy used for allocation would always be sequential.src/axom/quest/examples/CMakeLists.txtforquest_shaping_driver_exandquest_shape_in_memory_exexecutables.