You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In adding tests for reading face groups (sidesets), the C++ test data in TestMeshIO_Data identifies faces using cell + face vertices, which is consistent with the ASCII input. This seems easiest from a test setup perspective. However, this is sensitive to the order of vertices when getting the vertices for a face.
The alternative is to update the test data to use the points corresponding to the face. This information is not usually available in the input mesh, so it would require examining the created mesh to identify the point for each face.
The text was updated successfully, but these errors were encountered:
The way I had envisioned it, we would use the ExodusII system (which is why they created it). You specify (cell + local face) and it is translated to face.
Specifying a cell + its local side is easy to mess up in creating the unit tests, especially in 3D. Specifying a cell + vertices on a face is much easier to setup and check.
We could use local vertex numbers, but I think global vertex numbers is less prone to errors. With global vertex numbers there is a nice 1:1 match between a ASCII input file with cell and global vertex numbers and the test data, so it is very easy to setup and debug.
We have a lot of test data, so the simpler the better.
For that, you would have to get the closure of the cell and filter out the vertices (I do this in many places in plex.c), then all getRawFaces(), translate the local vertices to global vertices using your closure, put those vertices in a set or somehow do setwise comparison with your vertex set.
In adding tests for reading face groups (sidesets), the C++ test data in
TestMeshIO_Data
identifies faces using cell + face vertices, which is consistent with the ASCII input. This seems easiest from a test setup perspective. However, this is sensitive to the order of vertices when getting the vertices for a face.The alternative is to update the test data to use the points corresponding to the face. This information is not usually available in the input mesh, so it would require examining the created mesh to identify the point for each face.
The text was updated successfully, but these errors were encountered: