0 indexed meshes(#114)

[zasexton]

*Arbitrary Mesh Indexing for Problem Initialization *

Current situation & Problem

In response to issue #114. Face mesh data for svFSIplus assumes that GlobalNodeID and GlobalElementID are indexed at 1. This scheme is inconsistent with how VTK tools external to SimVascular construct connectivity data on meshes. The different scheme thus makes it difficult to build models in a scripted fashion either though SimVascular's Python VTK functions or external VTK functions. Further changes were made to avoid hanging that occurred during previous integration testing.

Release Notes

• arbitrary element type to be correctly initialized by the solver
• agreement with internal and external mesh generation routines

Documentation

No new functions are added through this pull. Instead changes are introduced to existing functions for importing and handling mesh initialization.

Testing

Further testing will be needed for different element types for VTK_WEDGE. In addition, changes introduced to the code should be checked for clarity and minimal code needed for fast implementation. I've included my thoughts as I wrote these changes in #114.

Code of Conduct & Contributing Guidelines

• I agree to follow the Code of Conduct and Contributing Guidelines.

[zasexton]

Okay, trying this again but hopefully with working integration tests this time. @ktbolt and @mrp089 mostly what I want to make sure is that any of these changes are how we would like to address this issue.

Specifically I assume that we conserve the counter-clockwise ordering of nodes within elements of the imported meshes (the same conventions used by VTK) thus the following elements have the following node orders:

• VTK_HEXAHEDRON

      7-------6
     /|      /|
    / |     / |
   4-------5  |
   |  3----|--2
   | /     | /
   |/      |/
   0-------1

Node Ordering for Faces

1. Bottom face: 0-3-2-1 (counter-clockwise when viewed from below)
2. Top face: 4-5-6-7 (counter-clockwise when viewed from above)
3. Front face: 0-1-5-4 (counter-clockwise when viewed from front)
4. Back face: 2-3-7-6 (counter-clockwise when viewed from back)
5. Left face: 3-0-4-7 (counter-clockwise when viewed from left)
6. Right face: 1-2-6-5 (counter-clockwise when viewed from right)

• VTK_WEDGE

3-----------5
|\         /|
| \       / |
|  \     /  |
|   \   /   |
|    \ /    |
|     4     |
0-----|-----2
 \    |    /       
  \   |   /
   \  |  /
    \ | /
      1

Node ordering of Faces

1. Bottom triangular face: 0-1-2 (counter-clockwise when viewed from below)
2. Top triangular face: 3-4-5 (counter-clockwise when viewed from above)
3. Back quadrilateral face: 2-0-3-5 (counter-clockwise when viewed from the back)
4. Left quadrilateral face: 0-1-4-3 (counter-clockwise when viewed from the left)
5. Right quadrilateral face: 1-2-5-4 (counter-clockwise when viewed from the right)

• VTK_TETRA

       3
      /|\
     / | \
    /  |  \
   /   |   \
  0----|----2
   \   |   /
    \  |  /
     \ | /
      \|/
       1

Node ordering for Faces

1. Face 0-1-2 (counter-clockwise when viewed from outside, in this case, from below)
2. Face 0-1-3 (counter-clockwise when viewed from the left)
3. Face 1-2-3 (counter-clockwise when viewed from the right)
4. Face 2-0-3 (counter-clockwise when viewed from the back)

• VTK_QUAD

3-------2
|       |
|       |
|       |
0-------1

Node ordering of Edges

1. Bottom edge: 0-1 (counter-clockwise when viewed from the front)
2. Right edge: 1-2 (counter-clockwise when viewed from the front)
3. Top edge: 2-3 (counter-clockwise when viewed from the front)
4. Left edge: 3-0 (counter-clockwise when viewed from the front)

• VTK_TRIANGLE

      2
     / \
    /   \
   /     \
  0-------1

Node ordering of Edges

1. Bottom edge: 0-1 (counter-clockwise when viewed from the front)
2. Right edge: 1-2 (counter-clockwise when viewed from the front)
3. Left edge: 2-0 (counter-clockwise when viewed from the front)

• VTK_LINE

0----------1

Node ordering

1. Start of the line segment: 0
2. End of the line segment: 1

These ordering schemes for the boundaries are reflected in as a mesh attribute ordering which is a std::vector<std::vector<int>> and mapped to the element type in the vtk_xml_parser.cpp file here:
https://github.com/zasexton/svFSIplus/blob/fd04be0c476969788e54980ece00185a2c8d5ffe/Code/Source/svFSI/vtk_xml_parser.cpp#L43-L67

[ktbolt]

@zasexton svFSIplus will reorder element connectivity to whatever node ordering it needs.

[zasexton]

@ktbolt yes and to avoid checking all combinations of nodes for matching (which seemed to cause hanging on the test_niederer_benchmark_ECGs_quadrature I decided to supply this explicit ordering. This is not intended to be used in place of other reordering schemes.

[ktbolt]

std::to_string() only converts to six significant digits. If you want to use strings then you will need to use std::stringstream and std::setprecision().

It would be faster (?) and use less memory but a bit more complicated to map the coordinates into an integer index.

[zasexton]

Okay, I can include this. Is there a certain precision that we should set by default?

[ktbolt]

Assuming a precision that will convert a double exactly is the problem with using strings, would need to set it to 16 maybe but then the strings would be 18 bytes, larger using std::scientific.

I think a better solution is to map the coordinates to an integer index into a map of some sort.

[zasexton]

I've changed the unsorted_map keys for the global nodes to be constructed as strings from 16 precision scientific format of the coordinates using std::scientific and std::set_precision. Maybe we can change this to an integer map later on...

[ktbolt]

@zasexton Good, we can refine the code later if needed.

[ktbolt]

@zasexton You mixing in code from two different Issues.

[zasexton]

Yes I was trying to merge the other way around so I could continue on the perfusion problem (oops). I reverted those changes

[ktbolt]

@zasexton Add a check if the unsorted_map key already exists when mapping the global nodes. This will uncover any problems with the specified precision.

Also encapsulate all of these functions into a class, separating each portion of the computation into its own method.

[zasexton]

encapsulation of functions creating the hash maps for the global node and element IDs have been added the load_msh.cpp file in the load_msh namespace. These have been encapsulated in the MeshHashMaps class.

[ktbolt]

Very nice! Be sure to remove commented out code, it is always confusing.

[zasexton]

@ktbolt @mrp089 let me know if there are any other considerations that need to be made for this pull request. Otherwise I think it should be ready for a final review