This branch should only be merged after the adjacency branch is merged (I have pulled that branch's history into this one)
This is basically to set up some of the most basic and core parts of mesh data structures and pre-processing so that we can read/create and use it in the Gauss green gradient tests ASAP. Therefore boundaries are neglected presently, cell-centred only, not all connectivity and geometric data will be constructed, and algorithms will not be optimised for speed performance - most likely there will be n^2 operations floating around and no parallelizations have used.
I used the gambit nuetral format to represent cell-vertex adjacency. I checked for some other formats (esp vtk due to conversations with @HenningScheufler), but ultimately I could either not find the 'face and edge' local connectivity information for the various cell types and/or the faces were not defined in a positively oriented manner when considering accending face index ordering (vtk) - perhaps with the tables done correctly this is not an issue. What is need is a format/library to use with similar tables to the above link.
Ultimately this is all up for debate I am pretty open to any format/library, we can consider this a 'first baseline'. This can be changed easily for connectivity pre-processing since the process involves lookups to determine connections and these are abstracted away from the user. Geometry may be a little bit harder -> but at this early stage, will be easy to change. Finally, I am not 100% on how openFoam orders cells so this may all be a moot point, and we reimplement the same format here?
The approach to unstructured mesh pre-processing (from my experience) should be broken into the following steps:
Read/create points/point cloud, cell-vertex, and cell-type data (primitive mesh) - later boundary data as well.
Connectivity setup, create all connectivity structures required by the mesh.
Geometry setup, compute volumes, face areas, normals etc.
Still to be completed
[ ] testing
[x] basic cell definitions
[ ] minimum cell utilities (searches etc).
[ ] cellCell adjacency
[ ] faceCell adjacency
[ ] cellFace adjacency
[ ] face area + normal
[ ] cell volume
The above will give the ability to compute non-boundary cell's gradients both through face looping and by cell looping.
This branch should only be merged after the adjacency branch is merged (I have pulled that branch's history into this one)
This is basically to set up some of the most basic and core parts of mesh data structures and pre-processing so that we can read/create and use it in the Gauss green gradient tests ASAP. Therefore boundaries are neglected presently, cell-centred only, not all connectivity and geometric data will be constructed, and algorithms will not be optimised for speed performance - most likely there will be n^2 operations floating around and no parallelizations have used.
I used the gambit nuetral format to represent cell-vertex adjacency. I checked for some other formats (esp vtk due to conversations with @HenningScheufler), but ultimately I could either not find the 'face and edge' local connectivity information for the various cell types and/or the faces were not defined in a positively oriented manner when considering accending face index ordering (vtk) - perhaps with the tables done correctly this is not an issue. What is need is a format/library to use with similar tables to the above link.
Ultimately this is all up for debate I am pretty open to any format/library, we can consider this a 'first baseline'. This can be changed easily for connectivity pre-processing since the process involves lookups to determine connections and these are abstracted away from the user. Geometry may be a little bit harder -> but at this early stage, will be easy to change. Finally, I am not 100% on how openFoam orders cells so this may all be a moot point, and we reimplement the same format here?
The approach to unstructured mesh pre-processing (from my experience) should be broken into the following steps:
Still to be completed
The above will give the ability to compute non-boundary cell's gradients both through face looping and by cell looping.