X3d 3d ssfile

[kgbudge]

Background

• We have a use case for transport run on a pure hexahedral X3D mesh.
• While adding the necessary capability to our code library, we found that the X3D_Draco_Mesh_Reader sorts the nodes on a boundary face by node index, destroying the original counterclockwise ordering of the nodes.

Purpose of Pull Request

• Modify X3D_Draco_Mesh_Reader to store boundary face nodes in the original counterclockwise node ordering, rather than sorted by index.

Description of changes

• The reader sorts the nodes by node index to allow easy matching of boundary faces to cell faces. This is fine, but the code then added the sorted version to the side to node linkage. The code has been modified to add the original version (listed in counterclockwise order) to the side to node linkage instead.

Status

• Reference:
  • Pre-Merge Code Review
  • CDash Status
• Checks
  • Travis/Appveyor CI checks pass
  • Code coverage does not decrease
  • Valgrind test passes
  • Toss3 checks pass
  • Trinitite checks pass
  • Code reviewed/approved, sufficient DbC checks, testing, documentation

[RyanWollaeger]

@kgbudge It looks like the diff is picking up changes from previous PRs. @KineticTheory do you know what's going one here? Does Github get confused from certain rebase/merges (I see a lot of merge commits in the commit log for this PR)?

[KineticTheory]

@kgbudge It looks like the diff is picking up changes from previous PRs. @KineticTheory do you know what's going one here? Does Github get confused from certain rebase/merges (I see a lot of merge commits in the commit log for this PR)?

Long lived git branches often cause this issue -- especially when there are so many merge commits from upstream/develop. @kgbudge Can you apply this change set to a new branch based on the current upstream/develop and update the PR?

[KineticTheory]

@kgbudge It looks like the diff is picking up changes from previous PRs. @KineticTheory do you know what's going one here? Does Github get confused from certain rebase/merges (I see a lot of merge commits in the commit log for this PR)?

Long lived git branches often cause this issue -- especially when there are so many merge commits from upstream/develop. @kgbudge Can you apply this change set to a new branch based on the current upstream/develop and update the PR?

The diff is clean now. The changes look good to me.

@RyanWollaeger Can you review these changes?

[RyanWollaeger]

LGTM

[KineticTheory]

I'll merge this if the CI testing passes.

[codecov]

Codecov Report

Merging #1086 (6f15349) into develop (dcb5c56) will not change coverage.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##           develop   #1086   +/-   ##
=======================================
  Coverage     88.7%   88.7%           
=======================================
  Files          374     374           
  Lines        18601   18601           
=======================================
  Hits         16505   16505           
  Misses        2096    2096