Implementation of Triply Periodic Minimal Surfaces (TPMS) in OpenMC

[pferney05]

Description

Hello,

This is my first contribution to OpenMC. I did my best to fit the guidelines but it might not be perfect. I am very open to critics so I can be more efficient in the future. Sorry in advance for potential headaches as it is a big feature.

I am publishing a paper soon that will dive in the technical details of this pull request. Here is a reference to provide some context on TPMS:

https://www.sciencedirect.com/science/article/pii/S014919702300330X

This development introduces two new Surfaces objects:

• TPMS which represent a TPMS surface which can be "Schwarz-P", "Gyroid" or "Diamond" . It has got a pitch and an isovalue coefficient alongside 12 other coefficients who define the translation and rotation of the surface.
• FunctionTPMS which represent a TPMS whose pitch and isovalue are not constant, but interpolated from a 3D matrix.

This development has been made because we initially used meshed TPMS with Serpent2. It works fine for unit-cell cases but with more complexity, the size of files are just too big (several GB) or the mesh is too coarse, which leads to several % of bias on the keff. The performance are not better, but at least we don't have biases as we work with high fidelity surfaces.

To support the distance calculation, an algorithm of ray-tracing has been developed in tpms.cpp. Comments explain the philosophy behind the implementation. This has been tested and verificated against a Serpent + CAD files workflow. The very workflow used in the article above.

The cell.cpp file is updated so TPMS surfaces get a special treatment. First, all non TPMS surfaces are treated to get a first distance estimation. Then the TPMS are treated with the ray-tracing algorithm which takes in input the first distance estimation as an end of loop condition.

The implementation have been made so it will be easy in the future to implement other kind of TPMS or Function. Helper functions to perform all necessary operations have been implemented. a bisection function has been implemented, directly taken from the Boost library.

Fixes # (issue)

Initial implementation. No fixes.

Checklist

• [X] I have performed a self-review of my own code
• [X] I have run clang-format (version 15) on any C++ source files (if applicable)
• [X] I have followed the style guidelines for Python source files (if applicable)
• [x] I have made corresponding changes to the documentation (if applicable)
• [x] I have added tests that prove my fix is effective or that my feature works (if applicable)

[pferney05]

Here are some preliminary comments on your code. Regardless of the utility of the functionality being introduced, I think there’s room for improvement in how the data is structured. In particular, some existing OpenMC functionality could be leveraged—such as using the XML-to-xtensor reader instead of building custom string-to-matrix readers.

I also recommend reviewing the developer style guide, especially regarding function naming. The use of camel case is inconsistent with our convention, and keeping things uniform improves readability and maintainability.

Lastly, have you considered using mesh-based geometries for these exotic surfaces? Is there a measurable speed advantage to the current approach? Given enough complexity, mesh-based ray tracing might actually be faster than handling intricate ray-surface intersections.

Thank you very much @gridley for your insightful review. I addressed the straightforward comments in the new commit. It makes the code already much simpler. I also adopted the xml-to-xtensor logic. This development has been made because we initially used meshed TPMS with Serpent2. It works fine for unit-cell cases but with more complexity, the size of files are just too big (several GB) or the mesh is too coarse, which leads to several % of bias on the keff. The performance are not better, but at least we don't have biases as we work with high fidelity surfaces.

[MicahGale]

My ~two cents~ (oh wait, pennies are illegal) zero cents.

I think TPMS geometries are very interesting, and hold a lot of potential for future reactor designs. (Dr. Woolstenhume is good at selling it). Having this feature in OpenMC would give it a very clear competitive edge.

The question I have been struggling with though: are TPMSs CSG primitives? I am pretty confident that thy are not quadric, though that's not a requirement of CSG. To me CSG requires "partition" surfaces capable of forming two half-spaces. For example: spheres form in/out, and planes form top/bottom. It's unclear to me that you can rigorously define such half-spaces from a TPMS. Specifically can you get a unique solution for a given TPMS for $\forall \vec{x} \in \mathbb{R}^3$ that is positive or negative value (defining which halfspace the point is in)? Left on it's own is a possible for a TPMS to degenerate into something like a Klein bottle? Do you have a good reference to the theory of TPMSs? I would like to learn more.

[pferney05]

My ~two cents~ (oh wait, pennies are illegal) zero cents.

I think TPMS geometries are very interesting, and hold a lot of potential for future reactor designs. (Dr. Woolstenhume is good at selling it). Having this feature in OpenMC would give it a very clear competitive edge.

The question I have been struggling with though: are TPMSs CSG primitives? I am pretty confident that thy are not quadric, though that's not a requirement of CSG. To me CSG requires "partition" surfaces capable of forming two half-spaces. For example: spheres form in/out, and planes form top/bottom. It's unclear to me that you can rigorously define such half-spaces from a TPMS. Specifically can you get a unique solution for a given TPMS for ∀ x → ∈ R 3 that is positive or negative value (defining which halfspace the point is in)? Left on it's own is a possible for a TPMS to degenerate into something like a Klein bottle? Do you have a good reference to the theory of TPMSs? I would like to learn more.

Hi Micah, Good question !

Here is a paper who dive in the mathematical formalism of TPMS -> https://advanced.onlinelibrary.wiley.com/doi/full/10.1002/adem.201900524

TPMS are unfortunately not quadric. I did limited development of TPMS to the order 2 and higher of TPMS implicit equations. With order 2 you still get a quadric equation but you are very far from the TPMS shape. To get a "good enough" shape you need to push at least to order 6 to 10. You can define rigorous half-space for any function f(x,y,z) explicitly defined on the whole space and continuous. To get a degenerate surface like your klein bottle, you need a parametric function which is out of the formalism we are using with TPMS.