Control decusping #1229
Control decusping #1229
Conversation
Also update docstrings.
Uniform mesh converter was using Flags.FUEL and Flags.CONTROL as "priority" blocks for determining XS type for a block when two blocks with different xs types are blended. Radial shield also has B4C, so B10 XS are needed in the converted uniform block. This commit also checks for the relative insertion fraction of a control rod before adding its top material boundary as a preferred mesh point.
Rounding of the common mesh to 5 places was causing problems because the non-uniform mesh is not rounded, so you could get really small pieces of fuel smeared into plenum above.
Also pass exact=True to `core.getAssemblies()`
| materialTops, | ||
| preference="top", | ||
| ) | ||
| # combine all mesh points using all material boundaries as anchors with top preference |
There was a problem hiding this comment.
it seems like this step top vs bottom is somewhat arbitrary. is that true? if so say that its arbitrary. if not explain why its not? maybe that you know 0.0 is already in there so you want 0.0 + tops
There was a problem hiding this comment.
It is arbitrary. I've gone back and forth on bottom vs. top preference.
The fuel and control material boundaries are all anchorPoints by now, so this is more about adjusting the mesh points away from boundaries if they are smaller than the minimumMeshSize. In most cases, I would expect that this filtering step doesn't actually filter out any mesh points, but there could be a situation where it becomes necessary. It's hard to say whether bottom or top is better in general here; it would depend on the specific circumstances of a given case.
There was a problem hiding this comment.
sorry, i meant to say add a comment in the code that it is arbitrary if its arbitrary. helps next person to figure out if they are breaking past intent
| This function operates by filtering out mesh points that are too close together while always holding on | ||
| to the specified "anchor" points in the mesh. The anchor points are built up progressively as the | ||
| appropriate bottom and top boundaries of fuel and control assemblies are determined. | ||
| """ |
There was a problem hiding this comment.
I really like how clear this code is an how you were able to re-use filter!
|
@mgjarrett You mention performance. This certainly adds a lot of code, do we know how this affects our performance? |
|
This looks great @mgjarrett! thanks! @john-science take a look at the results shared in the latest issue on our internal reactivity control plugin. its hard to evaluate performance of de-cusping without an actual flux solver and we decided it would be better to share that evaluation internally. |
The goal here was to improve performance with respect to accuracy. I don't think this will significantly impact the runtime performance. I have not profiled it at all, but I just ran an example case to measure timing and found that it consistently takes about 0.6-0.7 s for the |
Description
The performance of the
UniformMeshGeometryConverterdepends significantly on how good of a common uniform mesh can be generated. The uniform mesh converter will homogenize materials in neighboring blocks, which can be a problem at material boundaries between fuel or absorber and another material. One manifestation of this issue is a significant control rod "cusping" effect that has been observed when calculating differential rod worth.The existing method
_computeAverageAxialMesh()is too simplistic and is totally agnostic to material boundaries. This PR introduces a new class,UniformMeshGenerator, that has a set of methods to modify the mesh produced by_computeAverageAxialMeshso that it does a better job of representing important material boundaries. The main goal of this PR is to eliminate control rod cusping effects, but it will also help when modeling a core that has fuel assemblies at different heights.Checklist
doc/release/0.X.rst) are up-to-date with any bug fixes or new features.docfolder.setup.py.