-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Pro/E input to intersection shaping driver #1111
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bmhan12!
Please don't forget to update the RELEASE-NOTES
.
for(int i = 0; i < m_num_vertices; i++) | ||
{ | ||
for(int j = i + 1; j < m_num_vertices; j++) | ||
{ | ||
// operator= for Point does not want to play nice... | ||
if(m_vertices[i][0] == m_vertices[j][0] && | ||
m_vertices[i][1] == m_vertices[j][1] && | ||
m_vertices[i][2] == m_vertices[j][2]) | ||
{ | ||
return false; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmhan12 -- do we always want to call a Polyhedron
invalid when it has duplicated vertices?
There are some cases that I can think of where this might be beneficial.
Also, should we be checking for exact duplicates? or should we be supplying a tolerance and checking that the distance b/w vertices is not nearly zero subject to that tolerance?
Suggestion: I think it would be clearer to move the highlighted code to a new function hasDuplicatedVertices(double EPS)
, and consider calling it explicitly, when necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we always want to call a Polyhedron invalid when it has duplicated vertices?
Admittedly, I'm not sure.
I did find this case needs to be handled for the Polyhedron::volume() function. It resulted in an infinite loop condition.
I've added a new test in primal_clip.cpp
for this case in particular.
Also, should we be checking for exact duplicates? or should we be supplying a tolerance and checking that the distance b/w vertices is not nearly zero subject to that tolerance?
👍 . Agreed, a tolerance value would be good.
Suggestion: I think it would be clearer to move the highlighted code to a new function hasDuplicatedVertices(double EPS), and consider calling it explicitly, when necessary.
I can separate this snippet into the function, and have it just in the Polyhedron::volume()
function for now where I was originally seeing the problem.
// Initialize tetrahedra | ||
axom::Array<IndexType> nodeIds(4); | ||
axom::Array<Point3D> pts(4); | ||
|
||
const auto& shapeName = shape.getName(); | ||
AXOM_UNUSED_VAR(shapeDimension); | ||
AXOM_UNUSED_VAR(shapeName); | ||
for(int i = 0; i < m_tetcount; i++) | ||
{ | ||
m_surfaceMesh->getCellNodeIDs(i, nodeIds.data()); | ||
|
||
SLIC_INFO(axom::fmt::format("Current shape is {}", shapeName)); | ||
m_surfaceMesh->getNode(nodeIds[0], pts[0].data()); | ||
m_surfaceMesh->getNode(nodeIds[1], pts[1].data()); | ||
m_surfaceMesh->getNode(nodeIds[2], pts[2].data()); | ||
m_surfaceMesh->getNode(nodeIds[3], pts[3].data()); | ||
|
||
m_tets[i] = TetrahedronType({pts[0], pts[1], pts[2], pts[3]}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to do this w/in a kernel in the ExecSpace
too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to do this w/in a kernel in the ExecSpace too?
I did not explore it in this PR, as a lot of these calls are to mint::UnstructuredMesh
functions which are not host/device annotated yet.
The functions also override virtual mint::Mesh
functions, so that might complicate things.
@@ -882,11 +1005,12 @@ class IntersectionShaper : public Shaper | |||
axom::deallocate(m_hexes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about when we use allocate/deallocate and when we use StackArray for variables/arrays.
Could you please clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Perhaps that's why I have so many comments about it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about when we use allocate/deallocate and when we use StackArray for variables/arrays.
Could you please clarify?
The StackArray's that are being created here are for using the host-device decorated ArrayView constructor:
axom/src/axom/core/ArrayView.hpp
Lines 76 to 87 in 31ae2e4
/*! | |
* \brief Generic constructor for an ArrayView of arbitrary dimension with external data | |
* | |
* \param [in] data the external data this ArrayView will wrap. | |
* \param [in] shape Array size in each dimension. | |
* \param [in] spacing_ Spacing between consecutive items. | |
* | |
* This constructor supports non-unit spacing. | |
*/ | |
AXOM_HOST_DEVICE ArrayView(T* data, | |
const StackArray<IndexType, DIM>& shape, | |
IndexType spacing_ = 1); |
The allocate/deallocate is for memory that will be used inside kernels.
I need to do a pass through these to change them to use axom::Array and axom::ArrayView.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Brian!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bmhan12 A few comments for consideration related to documentation and implementation consistency
…est case for clipping
… the driver level
…e duplicate logic in driver
…to use Array to accomodate changes
375b17f
to
dc5bd9e
Compare
The conversion of pointer allocate/deallocate memory to axom:Array / axom::ArrayView was mostly straightforward. Did encounter an error with HIP trying to use axom::Array with a RAJA::ReduceSum for the size: axom/src/axom/quest/IntersectionShaper.hpp Lines 729 to 755 in 43df7b6
Not seeing the problem with CUDA. This case will be added to a running list of HIP issues in #787 . |
This PR:
quest_intersection_shaper
unit tests:Related to LLNL/axom_data#16
Pro/E Case 1:
Pro/E Case 2: