The mesh was missing the order value which caused a lexical error and segmentation fault when trying to write the octree mesh.
This bug was discovered when trying to address a bigger issue still under investigation where when using the curvature based refinement in NekMesh. Currently, we are getting meshes that do not meet our expectations and in order to try and figure out why we wanted to use the booleanparameter "WriteOctree" to help us uncover the underlying issue. Using this parameter in the MCF file results in a segmentation fault as no order was set in the mesh factory.
Use RegisterConfig to set an order for the mesh. This can be done by passing the boolean expression that's the input of the WriteOctree function (was was previously the name of the output file). The name of the output octree mesh is now changed from "1" to "octree.xml".
nm previously was a boolean converted to a string "1" that was also used for the filename (no extension and no option to change it). It makes no sense to have a filename called "1" as the output.
See lines 96--99 in
While this is not a big improvement, we can use that string
nm which equals to "1" for the order and change the fixed filename from "1" to something a bit more descriptive like "octree.xml".
I envision that this will be overhauled down the line as we work on the larger issue to maybe generate the octree with the <case_name> + "_octree.xml" or something of the like, and get this to work with the block vtk functionality (it doesn't now) as well as other enhancements to the feature. But, the idea of this MR was not to improve the feature but only fix the segmentation fault and this seemed like the shortest and most reasonable way to do it.
Functions and classes, or changes to them, are documented.
User guide/documentation is updated.
Changelog is updated.
Suitable tests added for new functionality.
Contributed code is correctly formatted. (See the contributing guidelines).
License added to any new files.
No extraneous files have been added (e.g. compiler output or test data files).
On the 19.07 the code formatting (code style) was standardised using clang-format, over the whole Nektar++ code. This means changes in your branch will conflict with formatting changes on the
master branch. To resolve these conflicts , see