I’m considering some multiphysics coupling using OpenMC to calculate a power distribution.
I have managed to tally the power distribution on an unstructured mesh using the libMesh library.
I then can solve the heat conduction equation using a finite element program to calculate a temperature distribution on the unstructured mesh.
How can I specify this temperature distribution in OpenMC?
Ideally, I’d like to specify the temperature at each vertex in the unstructured mesh and then have OpenMC do the finite element interpolation to evaluate the temperature at a collision. This doesn’t seem currently possible but seems feasible with the use of the libMesh library.
Is there another way to specify a temperature distribution?
If temperature is unique to each cell, does that mean that I need to increase the number of cells (and thereby surfaces) to specify the temperature distribution?
For our problem, we would like to be able to look at temperature distribution within a fuel pin so the number of cells/surfaces could get out of hand fast.
Alright. I’ve done some reading so I can ask a more informed question.
I read:
Brown, Forrest B, and William R Martin. “Direct Sampling of Monte Carlo Flight Paths in Media with Continuously Varying Cross-Sections.” In Nuclear Mathematical and Computational Sciences, 12. Gatlinburg, Tennessee: American Nuclear Society, 2003. https://mcnp.lanl.gov/pdf_files/la-ur-02-6530.pdf
Novak, A, P Romano, B Wendt, R Rahaman, E Merzari, L Kerby, C Permann, R Martineau, and R N Slaybaugh. “Preliminary Coupling of OpenMC AND Nek5000,” 13. Cancun, Mexico, 2018.
Romano, Paul K., Steven P. Hamilton, Ronald O. Rahaman, April Novak, Elia Merzari, Sterling M., Harper, Patrick C. Shriwise, and Thomas M. Evans. “A Code-Agnostic Driver Application for Coupled Neutronics and Thermal-Hydraulic Simulations.” Nuclear Science and Engineering 195, no. 4 (April 3, 2021): 391–411. https://doi.org/10.1080/00295639.2020.1830620.
From 2. and 3., I understand that using surface tracking like in OpenMC (as opposed to delta tracking), this type of continuously variable temperature/cross section is traditionally not possible. As 3. is very recent, it seems like the state-of-the-art in Serpent is still to use a single volume-averaged temperature for each cell in OpenMC. Is this correct?
However, 2. mentions that the method from 1. was being investigated in OpenMC to allow for this capability in 2018. Is there any progress on this?
Your research is pretty much on the mark. Because we don’t yet have delta tracking, we don’t have the ability to change temperatures at a granularity finer than an individual cell (which is usually what one would intend to do with an unstructured mesh). There is also a method for tracking over regions with continuously varying properties (density, temperature, etc.) that has been explored and in fact there was a pull request for adding this to the code, but it has been stalled for quite a while. It also wouldn’t naturally work for your use case. So, for now the only method of updating temperatures is to average values over mesh elements contained in a cell as described in paper 3 you came across (associated project).
That being said, @pshriwise is actively working on delta tracking and we’re hopeful that it will make it into the code within the next year or so. He might have some more comments to make on the topic here as he is also the expert on unstructured meshes in OpenMC.
Delta tracking will greatly simplify continuously varying properties indeed. I’ve had some thoughts on how we might specify in our inputs that certain cells should use different methods to look up temperature and density properties by interpolating values on a mesh, using element-based values, or from some specified analytic distribution passed in via the Python API by setting a temperature lookup method on the Cell class in OpenMC. I’ve also considered a similar approach to that of the dynamic library custom sourcew routines were we might simply provide a particle location to a separately compiled library that returns properties for that location. At any rate, this is still a ways out until we get at least a preliminary version of delta tracking in. Any thoughts you have are very welcome!
Thanks for the info! Delta-tracking in OpenMC would be interesting. The “direct” method by Brown & Martin seems more interesting to me but I understand that it is far less mature.
@pshriwise I’m not familiar with the data structures of OpenMC but I can describe what would be useful from a user perspective. The most useful would be to specify the temperature at the vertices of the associated unstructured mesh and (linearly) interpolate. I think this would cover the vast majority of use cases (any sort of FEM solver) and libMesh likely has routines to help with this. There would be problems when a particle may not be contained by any finite element.
Specifying a temperature for each element in the mesh would be fine but likely require an intermediate processing step. I understand this may be easier from the OpenMC side.
Providing an interface for users to specify their own custom temperature distribution function (e.g. Python lambda) is interesting and could be used to generate some cool results but may be less useful for users.
Hope this helps! I’ll keep my eye out for future development.