mirror of
https://github.com/openmc-dev/openmc.git
synced 2026-07-27 13:45:36 -04:00
adding back files to be reviewed
This commit is contained in:
Paul Romano
parent
ae28233110
commit
bc09d1ef55
1244 changed files with 301904 additions and 0 deletions
BIN
docs/source/_images/3dba.png
Normal file
BIN
docs/source/_images/3dba.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
docs/source/_images/3dcore.png
Normal file
BIN
docs/source/_images/3dcore.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 278 KiB |
BIN
docs/source/_images/3dgeomplot.png
Normal file
BIN
docs/source/_images/3dgeomplot.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
BIN
docs/source/_images/Tracks.png
Normal file
BIN
docs/source/_images/Tracks.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
BIN
docs/source/_images/atr.png
Normal file
BIN
docs/source/_images/atr.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 460 KiB |
BIN
docs/source/_images/cmfd_flow.png
Normal file
BIN
docs/source/_images/cmfd_flow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
29
docs/source/_images/cmfd_flow.tex
Normal file
29
docs/source/_images/cmfd_flow.tex
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
\documentclass{standalone}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{tikz}
|
||||
\usepackage{pgfplots}
|
||||
\pgfplotsset{compat=1.11}
|
||||
\usetikzlibrary{shapes,snakes,shadows,arrows,calc,decorations.markings,patterns,fit,matrix,spy}
|
||||
\pagestyle{empty}
|
||||
\begin{document}
|
||||
\begin{tikzpicture}
|
||||
\matrix[every node/.style={draw, thick, minimum width=3cm, minimum height=1cm, align=center}, column sep=2cm, row sep=1cm] (m) {
|
||||
\node[draw, fill=red!40] (start) {Batch $i$ \\ tally NDA}; & \\
|
||||
\node[draw, diamond, aspect=2, fill=green!40] (cmfd) {Run NDA?}; & \node[draw, fill=red!40] (end) {Batch $i + 1$ \\ tally NDA}; \\
|
||||
\node[draw, fill=blue!40] (xs) {Calculate XS \& DC}; & \node[draw, fill=blue!40] (modify) {Modify MC Source}; \\
|
||||
\node[draw, fill=blue!40] (nonlinear) {Calculate Equivalence}; & \node[draw, fill=blue!40] (eqs) {Solve NDA eqs.};\\
|
||||
};
|
||||
|
||||
\begin{scope}[every path/.style={->,very thick,draw}]
|
||||
\draw (start.south) -- (cmfd.north);
|
||||
\draw (cmfd.east) -- node[above] {no} (end.west);
|
||||
\draw (cmfd.south) -- node[right] {yes} (xs.north);
|
||||
\draw (xs.south) -- (nonlinear.north);
|
||||
\draw (nonlinear.east) -- (eqs.west);
|
||||
\draw (eqs.north) -- (modify.south);
|
||||
\draw (modify.north) -- (end.south);
|
||||
\end{scope}
|
||||
|
||||
\end{tikzpicture}
|
||||
\end{document}
|
||||
BIN
docs/source/_images/cosine-dist.png
Normal file
BIN
docs/source/_images/cosine-dist.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
docs/source/_images/fluxplot.png
Normal file
BIN
docs/source/_images/fluxplot.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
docs/source/_images/fork.png
Normal file
BIN
docs/source/_images/fork.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
54
docs/source/_images/halfspace.svg
Normal file
54
docs/source/_images/halfspace.svg
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
version="1.1"
|
||||
width="338.45703"
|
||||
height="172"
|
||||
id="svg2">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<metadata
|
||||
id="metadata7">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
transform="translate(-152.54297,-201.36218)"
|
||||
id="layer1">
|
||||
<path
|
||||
d="m 490,287.36218 a 150,85 0 1 1 -300,0 150,85 0 1 1 300,0 z"
|
||||
id="path2987"
|
||||
style="fill:none;stroke:#000000;stroke-width:2;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
x="150"
|
||||
y="272.36218"
|
||||
id="text3765"
|
||||
xml:space="preserve"
|
||||
style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="150"
|
||||
y="272.36218"
|
||||
id="tspan3769">+1</tspan></text>
|
||||
<text
|
||||
x="205"
|
||||
y="272.36218"
|
||||
id="text3765-4"
|
||||
xml:space="preserve"
|
||||
style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="205"
|
||||
y="272.36218"
|
||||
id="tspan3794">-1</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 2 KiB |
780
docs/source/_images/hex_lat.svg
Normal file
780
docs/source/_images/hex_lat.svg
Normal file
|
|
@ -0,0 +1,780 @@
|
|||
<?xml version="1.0" encoding="utf-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
|
||||
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<!-- Created with matplotlib (http://matplotlib.org/) -->
|
||||
<svg height="513pt" version="1.1" viewBox="0 0 513 513" width="513pt" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<defs>
|
||||
<style type="text/css">
|
||||
*{stroke-linecap:butt;stroke-linejoin:round;}
|
||||
</style>
|
||||
</defs>
|
||||
<g id="figure_1">
|
||||
<g id="patch_1">
|
||||
<path d="
|
||||
M0 513
|
||||
L513 513
|
||||
L513 0
|
||||
L0 0
|
||||
z
|
||||
" style="fill:#ffffff;"/>
|
||||
</g>
|
||||
<g id="axes_1">
|
||||
<g id="patch_2">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M231.818 213.75
|
||||
L207.137 256.5
|
||||
L231.818 299.25
|
||||
L281.182 299.25
|
||||
L305.863 256.5
|
||||
L281.182 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_3">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M234.286 218.025
|
||||
L212.073 256.5
|
||||
L234.286 294.975
|
||||
L278.714 294.975
|
||||
L300.927 256.5
|
||||
L278.714 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_4">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M231.818 128.25
|
||||
L207.137 171
|
||||
L231.818 213.75
|
||||
L281.182 213.75
|
||||
L305.863 171
|
||||
L281.182 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_5">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M234.286 132.525
|
||||
L212.073 171
|
||||
L234.286 209.475
|
||||
L278.714 209.475
|
||||
L300.927 171
|
||||
L278.714 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_6">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M305.863 171
|
||||
L281.182 213.75
|
||||
L305.863 256.5
|
||||
L355.227 256.5
|
||||
L379.909 213.75
|
||||
L355.227 171
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_7">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M308.332 175.275
|
||||
L286.118 213.75
|
||||
L308.332 252.225
|
||||
L352.759 252.225
|
||||
L374.972 213.75
|
||||
L352.759 175.275
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_8">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M305.863 256.5
|
||||
L281.182 299.25
|
||||
L305.863 342
|
||||
L355.227 342
|
||||
L379.909 299.25
|
||||
L355.227 256.5
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_9">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M308.332 260.775
|
||||
L286.118 299.25
|
||||
L308.332 337.725
|
||||
L352.759 337.725
|
||||
L374.972 299.25
|
||||
L352.759 260.775
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_10">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M231.818 299.25
|
||||
L207.137 342
|
||||
L231.818 384.75
|
||||
L281.182 384.75
|
||||
L305.863 342
|
||||
L281.182 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_11">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M234.286 303.525
|
||||
L212.073 342
|
||||
L234.286 380.475
|
||||
L278.714 380.475
|
||||
L300.927 342
|
||||
L278.714 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_12">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M157.773 256.5
|
||||
L133.091 299.25
|
||||
L157.773 342
|
||||
L207.137 342
|
||||
L231.818 299.25
|
||||
L207.137 256.5
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_13">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M160.241 260.775
|
||||
L138.028 299.25
|
||||
L160.241 337.725
|
||||
L204.668 337.725
|
||||
L226.882 299.25
|
||||
L204.668 260.775
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_14">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M157.773 171
|
||||
L133.091 213.75
|
||||
L157.773 256.5
|
||||
L207.137 256.5
|
||||
L231.818 213.75
|
||||
L207.137 171
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_15">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M160.241 175.275
|
||||
L138.028 213.75
|
||||
L160.241 252.225
|
||||
L204.668 252.225
|
||||
L226.882 213.75
|
||||
L204.668 175.275
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_16">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M231.818 42.75
|
||||
L207.137 85.5
|
||||
L231.818 128.25
|
||||
L281.182 128.25
|
||||
L305.863 85.5
|
||||
L281.182 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_17">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M234.286 47.025
|
||||
L212.073 85.5
|
||||
L234.286 123.975
|
||||
L278.714 123.975
|
||||
L300.927 85.5
|
||||
L278.714 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_18">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M305.863 85.5
|
||||
L281.182 128.25
|
||||
L305.863 171
|
||||
L355.227 171
|
||||
L379.909 128.25
|
||||
L355.227 85.5
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_19">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M308.332 89.775
|
||||
L286.118 128.25
|
||||
L308.332 166.725
|
||||
L352.759 166.725
|
||||
L374.972 128.25
|
||||
L352.759 89.775
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_20">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M379.909 128.25
|
||||
L355.227 171
|
||||
L379.909 213.75
|
||||
L429.272 213.75
|
||||
L453.954 171
|
||||
L429.272 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_21">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M382.377 132.525
|
||||
L360.163 171
|
||||
L382.377 209.475
|
||||
L426.804 209.475
|
||||
L449.017 171
|
||||
L426.804 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_22">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M379.909 213.75
|
||||
L355.227 256.5
|
||||
L379.909 299.25
|
||||
L429.272 299.25
|
||||
L453.954 256.5
|
||||
L429.272 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_23">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M382.377 218.025
|
||||
L360.163 256.5
|
||||
L382.377 294.975
|
||||
L426.804 294.975
|
||||
L449.017 256.5
|
||||
L426.804 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_24">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M379.909 299.25
|
||||
L355.227 342
|
||||
L379.909 384.75
|
||||
L429.272 384.75
|
||||
L453.954 342
|
||||
L429.272 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_25">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M382.377 303.525
|
||||
L360.163 342
|
||||
L382.377 380.475
|
||||
L426.804 380.475
|
||||
L449.017 342
|
||||
L426.804 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_26">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M305.863 342
|
||||
L281.182 384.75
|
||||
L305.863 427.5
|
||||
L355.227 427.5
|
||||
L379.909 384.75
|
||||
L355.227 342
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_27">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M308.332 346.275
|
||||
L286.118 384.75
|
||||
L308.332 423.225
|
||||
L352.759 423.225
|
||||
L374.972 384.75
|
||||
L352.759 346.275
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_28">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M231.818 384.75
|
||||
L207.137 427.5
|
||||
L231.818 470.25
|
||||
L281.182 470.25
|
||||
L305.863 427.5
|
||||
L281.182 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_29">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M234.286 389.025
|
||||
L212.073 427.5
|
||||
L234.286 465.975
|
||||
L278.714 465.975
|
||||
L300.927 427.5
|
||||
L278.714 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_30">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M157.773 342
|
||||
L133.091 384.75
|
||||
L157.773 427.5
|
||||
L207.137 427.5
|
||||
L231.818 384.75
|
||||
L207.137 342
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_31">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M160.241 346.275
|
||||
L138.028 384.75
|
||||
L160.241 423.225
|
||||
L204.668 423.225
|
||||
L226.882 384.75
|
||||
L204.668 346.275
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_32">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M83.7279 299.25
|
||||
L59.0462 342
|
||||
L83.7279 384.75
|
||||
L133.091 384.75
|
||||
L157.773 342
|
||||
L133.091 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_33">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M86.1961 303.525
|
||||
L63.9826 342
|
||||
L86.1961 380.475
|
||||
L130.623 380.475
|
||||
L152.837 342
|
||||
L130.623 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_34">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M83.7279 213.75
|
||||
L59.0462 256.5
|
||||
L83.7279 299.25
|
||||
L133.091 299.25
|
||||
L157.773 256.5
|
||||
L133.091 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_35">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M86.1961 218.025
|
||||
L63.9826 256.5
|
||||
L86.1961 294.975
|
||||
L130.623 294.975
|
||||
L152.837 256.5
|
||||
L130.623 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_36">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M83.7279 128.25
|
||||
L59.0462 171
|
||||
L83.7279 213.75
|
||||
L133.091 213.75
|
||||
L157.773 171
|
||||
L133.091 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_37">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M86.1961 132.525
|
||||
L63.9826 171
|
||||
L86.1961 209.475
|
||||
L130.623 209.475
|
||||
L152.837 171
|
||||
L130.623 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_38">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M157.773 85.5
|
||||
L133.091 128.25
|
||||
L157.773 171
|
||||
L207.137 171
|
||||
L231.818 128.25
|
||||
L207.137 85.5
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_39">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M160.241 89.775
|
||||
L138.028 128.25
|
||||
L160.241 166.725
|
||||
L204.668 166.725
|
||||
L226.882 128.25
|
||||
L204.668 89.775
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_40">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M41.04 58.995
|
||||
L41.04 64.125
|
||||
L82.08 64.125
|
||||
L82.08 69.255
|
||||
L92.34 61.56
|
||||
L82.08 53.865
|
||||
L82.08 58.995
|
||||
z
|
||||
" style="fill:#0000ff;stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_41">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M38.8186 62.8425
|
||||
L43.2614 60.2775
|
||||
L22.7414 24.7358
|
||||
L27.1841 22.1708
|
||||
L15.39 17.1329
|
||||
L13.8559 29.8658
|
||||
L18.2986 27.3008
|
||||
z
|
||||
" style="fill:#ff0000;stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="line2d_1">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M108.41 513
|
||||
L108.41 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_2">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 575.59
|
||||
M106.678 514
|
||||
L513 279.41" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_3">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M182.455 513
|
||||
L182.455 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_4">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 490.09
|
||||
L513 193.91" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_5">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M256.5 513
|
||||
L256.5 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_6">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 404.59
|
||||
L513 108.41" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_7">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M330.545 513
|
||||
L330.545 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_8">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 319.09
|
||||
L513 22.9097" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_9">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M404.59 513
|
||||
L404.59 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_10">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 233.59
|
||||
L406.322 -1" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="text_1">
|
||||
<!-- -2 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M19.1875 8.29688
|
||||
L53.6094 8.29688
|
||||
L53.6094 0
|
||||
L7.32812 0
|
||||
L7.32812 8.29688
|
||||
Q12.9375 14.1094 22.625 23.8906
|
||||
Q32.3281 33.6875 34.8125 36.5312
|
||||
Q39.5469 41.8438 41.4219 45.5312
|
||||
Q43.3125 49.2188 43.3125 52.7812
|
||||
Q43.3125 58.5938 39.2344 62.25
|
||||
Q35.1562 65.9219 28.6094 65.9219
|
||||
Q23.9688 65.9219 18.8125 64.3125
|
||||
Q13.6719 62.7031 7.8125 59.4219
|
||||
L7.8125 69.3906
|
||||
Q13.7656 71.7812 18.9375 73
|
||||
Q24.125 74.2188 28.4219 74.2188
|
||||
Q39.75 74.2188 46.4844 68.5469
|
||||
Q53.2188 62.8906 53.2188 53.4219
|
||||
Q53.2188 48.9219 51.5312 44.8906
|
||||
Q49.8594 40.875 45.4062 35.4062
|
||||
Q44.1875 33.9844 37.6406 27.2188
|
||||
Q31.1094 20.4531 19.1875 8.29688" id="DejaVuSans-32"/>
|
||||
<path d="
|
||||
M4.89062 31.3906
|
||||
L31.2031 31.3906
|
||||
L31.2031 23.3906
|
||||
L4.89062 23.3906
|
||||
z
|
||||
" id="DejaVuSans-2d"/>
|
||||
</defs>
|
||||
<g transform="translate(116.959655953 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-2d"/>
|
||||
<use x="36.083984375" xlink:href="#DejaVuSans-32"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_2">
|
||||
<!-- -1 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M12.4062 8.29688
|
||||
L28.5156 8.29688
|
||||
L28.5156 63.9219
|
||||
L10.9844 60.4062
|
||||
L10.9844 69.3906
|
||||
L28.4219 72.9062
|
||||
L38.2812 72.9062
|
||||
L38.2812 8.29688
|
||||
L54.3906 8.29688
|
||||
L54.3906 0
|
||||
L12.4062 0
|
||||
z
|
||||
" id="DejaVuSans-31"/>
|
||||
</defs>
|
||||
<g transform="translate(191.004827976 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-2d"/>
|
||||
<use x="36.083984375" xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_3">
|
||||
<!-- -1 -->
|
||||
<g transform="translate(8.55 472.990344047)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-2d"/>
|
||||
<use x="36.083984375" xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_4">
|
||||
<!-- 0 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M31.7812 66.4062
|
||||
Q24.1719 66.4062 20.3281 58.9062
|
||||
Q16.5 51.4219 16.5 36.375
|
||||
Q16.5 21.3906 20.3281 13.8906
|
||||
Q24.1719 6.39062 31.7812 6.39062
|
||||
Q39.4531 6.39062 43.2812 13.8906
|
||||
Q47.125 21.3906 47.125 36.375
|
||||
Q47.125 51.4219 43.2812 58.9062
|
||||
Q39.4531 66.4062 31.7812 66.4062
|
||||
M31.7812 74.2188
|
||||
Q44.0469 74.2188 50.5156 64.5156
|
||||
Q56.9844 54.8281 56.9844 36.375
|
||||
Q56.9844 17.9688 50.5156 8.26562
|
||||
Q44.0469 -1.42188 31.7812 -1.42188
|
||||
Q19.5312 -1.42188 13.0625 8.26562
|
||||
Q6.59375 17.9688 6.59375 36.375
|
||||
Q6.59375 54.8281 13.0625 64.5156
|
||||
Q19.5312 74.2188 31.7812 74.2188" id="DejaVuSans-30"/>
|
||||
</defs>
|
||||
<g transform="translate(265.05 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-30"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_5">
|
||||
<!-- 0 -->
|
||||
<g transform="translate(8.55 387.490344047)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-30"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_6">
|
||||
<!-- 1 -->
|
||||
<g transform="translate(339.095172024 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_7">
|
||||
<!-- 1 -->
|
||||
<g transform="translate(8.55 301.990344047)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_8">
|
||||
<!-- 2 -->
|
||||
<g transform="translate(413.140344047 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-32"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_9">
|
||||
<!-- 2 -->
|
||||
<g transform="translate(8.55 216.490344047)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-32"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_10">
|
||||
<!-- $\hat x$ -->
|
||||
<defs>
|
||||
<path d="
|
||||
M13.4844 53.8125
|
||||
L11.5312 55.9062
|
||||
L25 69.3906
|
||||
L38.375 55.9062
|
||||
L36.375 53.8125
|
||||
L25 63.8125
|
||||
z
|
||||
" id="Cmr10-5e"/>
|
||||
<path d="
|
||||
M7.8125 2.875
|
||||
Q9.57812 1.51562 12.7969 1.51562
|
||||
Q15.9219 1.51562 18.3125 4.51562
|
||||
Q20.7031 7.51562 21.5781 11.0781
|
||||
L26.125 28.8125
|
||||
Q27.2031 33.6406 27.2031 35.4062
|
||||
Q27.2031 37.8906 25.8125 39.75
|
||||
Q24.4219 41.6094 21.9219 41.6094
|
||||
Q18.75 41.6094 15.9688 39.625
|
||||
Q13.1875 37.6406 11.2812 34.5938
|
||||
Q9.375 31.5469 8.59375 28.4219
|
||||
Q8.40625 27.7812 7.8125 27.7812
|
||||
L6.59375 27.7812
|
||||
Q5.8125 27.7812 5.8125 28.7188
|
||||
L5.8125 29
|
||||
Q6.78125 32.7188 9.125 36.25
|
||||
Q11.4688 39.7969 14.8594 41.9844
|
||||
Q18.2656 44.1875 22.125 44.1875
|
||||
Q25.7812 44.1875 28.7344 42.2344
|
||||
Q31.6875 40.2812 32.9062 36.9219
|
||||
Q34.625 39.9844 37.2812 42.0781
|
||||
Q39.9375 44.1875 43.1094 44.1875
|
||||
Q45.2656 44.1875 47.5 43.4219
|
||||
Q49.75 42.6719 51.1719 41.1094
|
||||
Q52.5938 39.5469 52.5938 37.2031
|
||||
Q52.5938 34.6719 50.9531 32.8281
|
||||
Q49.3125 31 46.7812 31
|
||||
Q45.1719 31 44.0938 32.0312
|
||||
Q43.0156 33.0625 43.0156 34.625
|
||||
Q43.0156 36.7188 44.4531 38.2969
|
||||
Q45.9062 39.8906 47.9062 40.1875
|
||||
Q46.0938 41.6094 42.9219 41.6094
|
||||
Q39.7031 41.6094 37.3281 38.625
|
||||
Q34.9688 35.6406 33.9844 31.9844
|
||||
L29.5938 14.3125
|
||||
Q28.5156 10.2969 28.5156 7.71875
|
||||
Q28.5156 5.17188 29.9531 3.34375
|
||||
Q31.3906 1.51562 33.7969 1.51562
|
||||
Q38.4844 1.51562 42.1562 5.64062
|
||||
Q45.8438 9.76562 47.0156 14.7031
|
||||
Q47.2188 15.2812 47.7969 15.2812
|
||||
L49.0312 15.2812
|
||||
Q49.4219 15.2812 49.6562 15.0156
|
||||
Q49.9062 14.75 49.9062 14.4062
|
||||
Q49.9062 14.3125 49.8125 14.1094
|
||||
Q48.3906 8.15625 43.8438 3.51562
|
||||
Q39.3125 -1.125 33.5938 -1.125
|
||||
Q29.9375 -1.125 26.9844 0.84375
|
||||
Q24.0312 2.82812 22.7969 6.20312
|
||||
Q21.2344 3.26562 18.4688 1.0625
|
||||
Q15.7188 -1.125 12.5938 -1.125
|
||||
Q10.4531 -1.125 8.17188 -0.359375
|
||||
Q5.90625 0.390625 4.48438 1.95312
|
||||
Q3.07812 3.51562 3.07812 5.90625
|
||||
Q3.07812 8.25 4.70312 10.1719
|
||||
Q6.34375 12.1094 8.79688 12.1094
|
||||
Q10.4531 12.1094 11.5781 11.1094
|
||||
Q12.7031 10.1094 12.7031 8.5
|
||||
Q12.7031 6.39062 11.2969 4.82812
|
||||
Q9.90625 3.26562 7.8125 2.875" id="Cmmi10-78"/>
|
||||
</defs>
|
||||
<g transform="translate(61.56 81.886875)scale(0.2 -0.2)">
|
||||
<use transform="translate(-0.53125 3.609375)" xlink:href="#Cmr10-5e"/>
|
||||
<use transform="translate(0.0 0.734375)" xlink:href="#Cmmi10-78"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_11">
|
||||
<!-- $\hat \alpha$ -->
|
||||
<defs>
|
||||
<path d="
|
||||
M20.125 -1.125
|
||||
Q15.375 -1.125 11.6875 1.125
|
||||
Q8.01562 3.375 6 7.17188
|
||||
Q4 10.9844 4 15.8281
|
||||
Q4 22.6094 7.78125 29.25
|
||||
Q11.5781 35.8906 17.8438 40.0312
|
||||
Q24.125 44.1875 31 44.1875
|
||||
Q36.0781 44.1875 39.9375 41.5312
|
||||
Q43.7969 38.875 45.7969 34.4531
|
||||
Q47.7969 30.0312 47.7969 25
|
||||
L47.9062 18.3125
|
||||
Q51.3125 23.0469 53.6875 28.1406
|
||||
Q56.0625 33.25 57.3281 38.7188
|
||||
Q57.5156 39.3125 58.1094 39.3125
|
||||
L59.2812 39.3125
|
||||
Q60.2031 39.3125 60.2031 38.375
|
||||
Q60.2031 38.2812 60.1094 38.0938
|
||||
Q58.9375 33.5 57.1719 29.2656
|
||||
Q55.4219 25.0469 53.0469 21.0938
|
||||
Q50.6875 17.1406 47.9062 13.9219
|
||||
Q47.9062 1.51562 50.7812 1.51562
|
||||
Q52.6406 1.51562 53.8281 2.60938
|
||||
Q55.0312 3.71875 55.9375 5.32812
|
||||
Q56.8438 6.9375 57.0781 6.98438
|
||||
L58.2969 6.98438
|
||||
Q59.0781 6.98438 59.0781 6
|
||||
Q59.0781 3.51562 56.2188 1.1875
|
||||
Q53.375 -1.125 50.5938 -1.125
|
||||
Q46.9688 -1.125 44.5781 1.21875
|
||||
Q42.1875 3.5625 41.3125 7.32812
|
||||
Q36.625 3.32812 31.1562 1.09375
|
||||
Q25.6875 -1.125 20.125 -1.125
|
||||
M20.3125 1.51562
|
||||
Q31 1.51562 40.8281 10.2969
|
||||
Q40.7656 10.8906 40.6719 11.7344
|
||||
Q40.5781 12.5938 40.5781 12.7031
|
||||
L40.5781 23.4844
|
||||
Q40.5781 41.6094 30.8125 41.6094
|
||||
Q24.9531 41.6094 20.5469 36.5938
|
||||
Q16.1562 31.5938 13.9375 24.625
|
||||
Q11.7188 17.6719 11.7188 11.9219
|
||||
Q11.7188 7.5625 13.9375 4.53125
|
||||
Q16.1562 1.51562 20.3125 1.51562" id="Cmmi10-ae"/>
|
||||
</defs>
|
||||
<g transform="translate(35.91 35.91)scale(0.2 -0.2)">
|
||||
<use transform="translate(3.46875 3.609375)" xlink:href="#Cmr10-5e"/>
|
||||
<use transform="translate(0.0 0.734375)" xlink:href="#Cmmi10-ae"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<defs>
|
||||
<clipPath id="p5382b9a736">
|
||||
<rect height="513.0" width="513.0" x="0.0" y="0.0"/>
|
||||
</clipPath>
|
||||
</defs>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 17 KiB |
BIN
docs/source/_images/loss.png
Normal file
BIN
docs/source/_images/loss.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
BIN
docs/source/_images/master-slave.png
Normal file
BIN
docs/source/_images/master-slave.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
BIN
docs/source/_images/meshfig.png
Normal file
BIN
docs/source/_images/meshfig.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
639
docs/source/_images/meshfig.tex
Normal file
639
docs/source/_images/meshfig.tex
Normal file
|
|
@ -0,0 +1,639 @@
|
|||
\documentclass[tikz]{standalone}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{tikz}
|
||||
\usepackage{pgfplots}
|
||||
\pgfplotsset{compat=1.11}
|
||||
\usetikzlibrary{shapes,snakes,shadows,arrows,calc,decorations.markings,patterns,fit,matrix,spy}
|
||||
\usepackage{fixltx2e}
|
||||
\pagestyle{empty}
|
||||
\begin{document}
|
||||
|
||||
% these dimensions are determined in arrow_dimms.ods
|
||||
|
||||
\def\scale{1.0}
|
||||
|
||||
\def\latWidth{0.2808363589*\scale}
|
||||
|
||||
\def\RPVOR{3*\scale}
|
||||
\def\rectW{0.75*\scale}
|
||||
\def\RPVIR{2.8694005485*\scale}
|
||||
\def\BarrelIR{2.4547472901*\scale}
|
||||
\def\BarrelOR{2.5293848766*\scale}
|
||||
\def\ShieldOR{2.6040224631*\scale}
|
||||
|
||||
\def\bafCIRx{0.9829272561*\scale}
|
||||
\def\bafCIRy{2.1062726917*\scale}
|
||||
\def\bafCORx{1.0119529842*\scale}
|
||||
\def\bafCORy{2.1352984197*\scale}
|
||||
\def\bafMIRx{1.8254363328*\scale}
|
||||
\def\bafMIRy{1.5445999739*\scale}
|
||||
\def\bafMORx{1.8544620609*\scale}
|
||||
\def\bafMORy{1.573625702*\scale}
|
||||
|
||||
\tikzset{Assembly/.style={
|
||||
inner sep=0pt,
|
||||
text width=\latWidth in,
|
||||
minimum size=\latWidth in,
|
||||
draw=black,
|
||||
align=center
|
||||
}
|
||||
}
|
||||
|
||||
\def\tkzRPV{(0,0) circle (\RPVIR) (0,0) circle (\RPVOR)}
|
||||
\def\tkzBarrel{(0,0) circle (\BarrelIR) (0,0) circle (\BarrelOR)}
|
||||
\def\tkzShields{(0,0) circle (\BarrelOR) (0,0) circle (\ShieldOR)}
|
||||
|
||||
\def\tkzBaffCOR{(-\bafCORx, -\bafCORy) rectangle (\bafCORx, \bafCORy)}
|
||||
\def\tkzBaffCIR{(-\bafCIRx, -\bafCIRy) rectangle (\bafCIRx, \bafCIRy)}
|
||||
\def\tkzBaffMOR{(-\bafMORx, -\bafMORy) rectangle (\bafMORx, \bafMORy)}
|
||||
\def\tkzBaffMIR{(-\bafMIRx, -\bafMIRy) rectangle (\bafMIRx, \bafMIRy) }
|
||||
\def\tkzBaffleC{ \tkzBaffCIR \tkzBaffCOR }
|
||||
\def\tkzBaffleM{ \tkzBaffMIR \tkzBaffMOR }
|
||||
|
||||
\def\tkzBaffCClip{\tkzBaffCIR (-\RPVOR, -\RPVOR) rectangle (\RPVOR, \RPVOR)}
|
||||
\def\tkzBaffMClip{\tkzBaffMIR (-\RPVOR, -\RPVOR) rectangle (\RPVOR, \RPVOR)}
|
||||
|
||||
\def\highenr{blue!50}
|
||||
\def\midenr{yellow!50}
|
||||
\def\lowenr{red!50}
|
||||
\def\lightgray{black!25}
|
||||
\def\darkgray{black!80}
|
||||
|
||||
\begin{tikzpicture}[x=1in,y=1in, xshift=3in]
|
||||
\scalebox{0.6}{
|
||||
% draw RPV, barrel, and shield panels
|
||||
|
||||
\path[fill=black,even odd rule] \tkzRPV;
|
||||
\path[fill=black,even odd rule] \tkzBarrel;
|
||||
\begin{scope}
|
||||
\clip[rotate around={45:(0,0)}] (-\RPVOR, -\rectW) rectangle (\RPVOR, \rectW) (-\rectW, \RPVOR) rectangle (\rectW, -\RPVOR);
|
||||
\path[fill=black,even odd rule] \tkzShields;
|
||||
\end{scope}
|
||||
|
||||
|
||||
% draw assembly row/column headers
|
||||
|
||||
\draw[red, thick] ($(-7*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {R} -- ($(-7*\latWidth,4*\latWidth)$);
|
||||
\draw[red, thick] ($(-6*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {P} -- ($(-6*\latWidth,6*\latWidth)$);
|
||||
\draw[red, thick] ($(-5*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {N} -- ($(-5*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(-4*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {M} -- ($(-4*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(-3*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {L} -- ($(-3*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-2*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {K} -- ($(-2*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-1*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {J} -- ($(-1*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-0*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {H} -- ($(-0*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(1*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {G} -- ($(1*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(2*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {F} -- ($(2*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(3*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {E} -- ($(3*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(4*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {D} -- ($(4*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(5*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {C} -- ($(5*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(6*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {B} -- ($(6*\latWidth,6*\latWidth)$);
|
||||
\draw[red, thick] ($(7*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[above, anchor=south] {A} -- ($(7*\latWidth,4*\latWidth)$);
|
||||
|
||||
\begin{scope}[rotate=90]
|
||||
\draw[red, thick] ($(-7*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {15} -- ($(-7*\latWidth,4*\latWidth)$);
|
||||
\draw[red, thick] ($(-6*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {14} -- ($(-6*\latWidth,6*\latWidth)$);
|
||||
\draw[red, thick] ($(-5*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {13} -- ($(-5*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(-4*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {12} -- ($(-4*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(-3*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {11} -- ($(-3*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-2*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {10} -- ($(-2*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-1*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {9} -- ($(-1*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(-0*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {8} -- ($(-0*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(1*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {7} -- ($(1*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(2*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {6} -- ($(2*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(3*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {5} -- ($(3*\latWidth,8*\latWidth)$);
|
||||
\draw[red, thick] ($(4*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {4} -- ($(4*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(5*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {3} -- ($(5*\latWidth,7*\latWidth)$);
|
||||
\draw[red, thick] ($(6*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {2} -- ($(6*\latWidth,6*\latWidth)$);
|
||||
\draw[red, thick] ($(7*\latWidth,\RPVOR/\latWidth*\latWidth)$) node[left, anchor=east] {1} -- ($(7*\latWidth,4*\latWidth)$);
|
||||
\end{scope}
|
||||
|
||||
% draw fuel assembly nodes
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-5*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-4*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-3*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-2*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-1*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-0*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 1*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 2*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 3*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 4*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 5*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,8*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-5*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-4*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-3*\latWidth,7*\latWidth)$) {}; % L1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-2*\latWidth,7*\latWidth)$) {6}; % K1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-1*\latWidth,7*\latWidth)$) {}; % J1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-0*\latWidth,7*\latWidth)$) {6}; % H1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 1*\latWidth,7*\latWidth)$) {}; % G1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 2*\latWidth,7*\latWidth)$) {6}; % F1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 3*\latWidth,7*\latWidth)$) {}; % E1
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 4*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 5*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,7*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-5*\latWidth,6*\latWidth)$) {}; % N2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-4*\latWidth,6*\latWidth)$) {}; % M2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-3*\latWidth,6*\latWidth)$) {16}; % L2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,6*\latWidth)$) {}; % K2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-1*\latWidth,6*\latWidth)$) {20}; % J2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,6*\latWidth)$) {}; % H2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 1*\latWidth,6*\latWidth)$) {20}; % G2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,6*\latWidth)$) {}; % F2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 3*\latWidth,6*\latWidth)$) {16}; % E2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 4*\latWidth,6*\latWidth)$) {}; % D2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 5*\latWidth,6*\latWidth)$) {}; % C2
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,6*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,5*\latWidth)$) {}; % P3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-5*\latWidth,5*\latWidth)$) {15}; % N3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,5*\latWidth)$) {16}; % M3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,5*\latWidth)$) {}; % L3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,5*\latWidth)$) {16}; % K3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,5*\latWidth)$) {}; % J3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,5*\latWidth)$) {16}; % H3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,5*\latWidth)$) {}; % G3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,5*\latWidth)$) {16}; % F3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,5*\latWidth)$) {}; % E3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,5*\latWidth)$) {16}; % D3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 5*\latWidth,5*\latWidth)$) {15}; % C3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,5*\latWidth)$) {}; % B3
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,5*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,4*\latWidth)$) {}; % P4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-5*\latWidth,4*\latWidth)$) {16}; % N4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,4*\latWidth)$) {}; % M4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-3*\latWidth,4*\latWidth)$) {16}; % L4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,4*\latWidth)$) {}; % K4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-1*\latWidth,4*\latWidth)$) {12}; % J4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,4*\latWidth)$) {}; % H4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 1*\latWidth,4*\latWidth)$) {12}; % G4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,4*\latWidth)$) {}; % F4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 3*\latWidth,4*\latWidth)$) {16}; % E4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,4*\latWidth)$) {}; % D4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 5*\latWidth,4*\latWidth)$) {16}; % C4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,4*\latWidth)$) {}; % B4
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,4*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,3*\latWidth)$) {}; % R5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,3*\latWidth)$) {16}; % P5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-5*\latWidth,3*\latWidth)$) {}; % N5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,3*\latWidth)$) {16}; % M5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,3*\latWidth)$) {}; % L5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,3*\latWidth)$) {12}; % K5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,3*\latWidth)$) {}; % J5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,3*\latWidth)$) {12}; % H5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,3*\latWidth)$) {}; % G5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,3*\latWidth)$) {12}; % F5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,3*\latWidth)$) {}; % E5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,3*\latWidth)$) {16}; % D5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 5*\latWidth,3*\latWidth)$) {}; % C5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,3*\latWidth)$) {16}; % B5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,3*\latWidth)$) {}; % A5
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,3*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,2*\latWidth)$) {6}; % R6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-6*\latWidth,2*\latWidth)$) {}; % P6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-5*\latWidth,2*\latWidth)$) {16}; % N6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-4*\latWidth,2*\latWidth)$) {}; % M6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-3*\latWidth,2*\latWidth)$) {12}; % L6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,2*\latWidth)$) {}; % K6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-1*\latWidth,2*\latWidth)$) {12}; % J6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,2*\latWidth)$) {}; % H6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 1*\latWidth,2*\latWidth)$) {12}; % G6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,2*\latWidth)$) {}; % F6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 3*\latWidth,2*\latWidth)$) {12}; % E6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 4*\latWidth,2*\latWidth)$) {}; % D6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 5*\latWidth,2*\latWidth)$) {16}; % C6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 6*\latWidth,2*\latWidth)$) {}; % B6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,2*\latWidth)$) {6}; % A6
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,2*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,1*\latWidth)$) {}; % R7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,1*\latWidth)$) {20}; % P7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-5*\latWidth,1*\latWidth)$) {}; % N7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,1*\latWidth)$) {12}; % M7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,1*\latWidth)$) {}; % L7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,1*\latWidth)$) {12}; % K7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,1*\latWidth)$) {}; % J7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,1*\latWidth)$) {16}; % H7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,1*\latWidth)$) {}; % G7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,1*\latWidth)$) {12}; % F7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,1*\latWidth)$) {}; % E7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,1*\latWidth)$) {12}; % D7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 5*\latWidth,1*\latWidth)$) {}; % C7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,1*\latWidth)$) {20}; % B7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,1*\latWidth)$) {}; % A7
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,1*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,0*\latWidth)$) {6}; % R8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-6*\latWidth,0*\latWidth)$) {}; % P8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-5*\latWidth,0*\latWidth)$) {16}; % N8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-4*\latWidth,0*\latWidth)$) {}; % M8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-3*\latWidth,0*\latWidth)$) {12}; % L8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,0*\latWidth)$) {}; % K8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-1*\latWidth,0*\latWidth)$) {16}; % J8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,0*\latWidth)$) {}; % H8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 1*\latWidth,0*\latWidth)$) {16}; % G8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,0*\latWidth)$) {}; % F8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 3*\latWidth,0*\latWidth)$) {12}; % E8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 4*\latWidth,0*\latWidth)$) {}; % D8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 5*\latWidth,0*\latWidth)$) {16}; % C8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 6*\latWidth,0*\latWidth)$) {}; % B8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,0*\latWidth)$) {6}; % A8
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,0*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,0*\latWidth)$) {};
|
||||
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,-1*\latWidth)$) {}; % R9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,-1*\latWidth)$) {20}; % P9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-5*\latWidth,-1*\latWidth)$) {}; % N9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,-1*\latWidth)$) {12}; % M9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,-1*\latWidth)$) {}; % L9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,-1*\latWidth)$) {12}; % K9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,-1*\latWidth)$) {}; % J9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,-1*\latWidth)$) {16}; % H9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,-1*\latWidth)$) {}; % G9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,-1*\latWidth)$) {12}; % F9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,-1*\latWidth)$) {}; % E9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,-1*\latWidth)$) {12}; % D9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 5*\latWidth,-1*\latWidth)$) {}; % C9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,-1*\latWidth)$) {20}; % B9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,-1*\latWidth)$) {}; % A9
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,-1*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-1*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,-2*\latWidth)$) {6}; % R10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-6*\latWidth,-2*\latWidth)$) {}; % P10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-5*\latWidth,-2*\latWidth)$) {16}; % N10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-4*\latWidth,-2*\latWidth)$) {}; % M10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-3*\latWidth,-2*\latWidth)$) {12}; % L10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,-2*\latWidth)$) {}; % K10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-1*\latWidth,-2*\latWidth)$) {12}; % J10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,-2*\latWidth)$) {}; % H10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 1*\latWidth,-2*\latWidth)$) {12}; % G10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,-2*\latWidth)$) {}; % F10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 3*\latWidth,-2*\latWidth)$) {12}; % E10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 4*\latWidth,-2*\latWidth)$) {}; % D10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 5*\latWidth,-2*\latWidth)$) {16}; % C10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 6*\latWidth,-2*\latWidth)$) {}; % B10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,-2*\latWidth)$) {6}; % A10
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,-2*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-2*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-7*\latWidth,-3*\latWidth)$) {}; % R11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-7*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,-3*\latWidth)$) {16}; % P11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-5*\latWidth,-3*\latWidth)$) {}; % N11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,-3*\latWidth)$) {16}; % M11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,-3*\latWidth)$) {}; % L11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,-3*\latWidth)$) {12}; % K11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,-3*\latWidth)$) {}; % J11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,-3*\latWidth)$) {12}; % H11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,-3*\latWidth)$) {}; % G11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,-3*\latWidth)$) {12}; % F11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,-3*\latWidth)$) {}; % E11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,-3*\latWidth)$) {16}; % D11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 5*\latWidth,-3*\latWidth)$) {}; % C11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,-3*\latWidth)$) {16}; % B11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 7*\latWidth,-3*\latWidth)$) {}; % A11
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 7*\latWidth,-3*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-3*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,-4*\latWidth)$) {}; % P12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-5*\latWidth,-4*\latWidth)$) {16}; % N12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,-4*\latWidth)$) {}; % M12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-3*\latWidth,-4*\latWidth)$) {16}; % L12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,-4*\latWidth)$) {}; % K12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-1*\latWidth,-4*\latWidth)$) {12}; % J12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,-4*\latWidth)$) {}; % H12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 1*\latWidth,-4*\latWidth)$) {12}; % G12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,-4*\latWidth)$) {}; % F12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 3*\latWidth,-4*\latWidth)$) {16}; % E12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,-4*\latWidth)$) {}; % D12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 5*\latWidth,-4*\latWidth)$) {16}; % C12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,-4*\latWidth)$) {}; % B12
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,-4*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-4*\latWidth)$) {};
|
||||
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-6*\latWidth,-5*\latWidth)$) {}; % P13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-6*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-5*\latWidth,-5*\latWidth)$) {15}; % N13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-4*\latWidth,-5*\latWidth)$) {16}; % M13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-3*\latWidth,-5*\latWidth)$) {}; % L13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-2*\latWidth,-5*\latWidth)$) {16}; % K13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-1*\latWidth,-5*\latWidth)$) {}; % J13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($(-0*\latWidth,-5*\latWidth)$) {16}; % H13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 1*\latWidth,-5*\latWidth)$) {}; % G13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 2*\latWidth,-5*\latWidth)$) {16}; % F13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 3*\latWidth,-5*\latWidth)$) {}; % E13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\midenr] at ($( 4*\latWidth,-5*\latWidth)$) {16}; % D13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 5*\latWidth,-5*\latWidth)$) {15}; % C13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 6*\latWidth,-5*\latWidth)$) {}; % B13
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 6*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,-5*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-5*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-5*\latWidth,-6*\latWidth)$) {}; % N14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-5*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-4*\latWidth,-6*\latWidth)$) {}; % M14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-4*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-3*\latWidth,-6*\latWidth)$) {16}; % L14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-2*\latWidth,-6*\latWidth)$) {}; % K14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-1*\latWidth,-6*\latWidth)$) {20}; % J14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($(-0*\latWidth,-6*\latWidth)$) {}; % H14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 1*\latWidth,-6*\latWidth)$) {20}; % G14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lowenr] at ($( 2*\latWidth,-6*\latWidth)$) {}; % F14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 3*\latWidth,-6*\latWidth)$) {16}; % E14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 4*\latWidth,-6*\latWidth)$) {}; % D14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 4*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 5*\latWidth,-6*\latWidth)$) {}; % C14
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 5*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,-6*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-6*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-5*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-4*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-3*\latWidth,-7*\latWidth)$) {}; % L15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-3*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-2*\latWidth,-7*\latWidth)$) {6}; % K15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-2*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-1*\latWidth,-7*\latWidth)$) {}; % J15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-1*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($(-0*\latWidth,-7*\latWidth)$) {6}; % H15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($(-0*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 1*\latWidth,-7*\latWidth)$) {}; % G15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 1*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 2*\latWidth,-7*\latWidth)$) {6}; % F15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 2*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\highenr] at ($( 3*\latWidth,-7*\latWidth)$) {}; % E15
|
||||
\node [Assembly, fill=\darkgray, opacity=0.7] at ($( 3*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 4*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 5*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,-7*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-7*\latWidth)$) {};
|
||||
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-8*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-7*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-6*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-5*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-4*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-3*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-2*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-1*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($(-0*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 1*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 2*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 3*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 4*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 5*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 6*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 7*\latWidth,-8*\latWidth)$) {};
|
||||
\node [Assembly, fill=\lightgray, opacity=0.3] at ($( 8*\latWidth,-8*\latWidth)$) {};
|
||||
|
||||
% draw baffle north/south
|
||||
|
||||
\begin{scope}[even odd rule]
|
||||
\clip[rotate=90] \tkzBaffMClip;
|
||||
\path[fill=black] \tkzBaffleC;
|
||||
\end{scope}
|
||||
\begin{scope}[even odd rule]
|
||||
\clip \tkzBaffCClip;
|
||||
\clip \tkzBaffMClip;
|
||||
\path[fill=black, rotate=90] \tkzBaffleM;
|
||||
\end{scope}
|
||||
|
||||
% draw baffle east/west
|
||||
|
||||
\begin{scope}[rotate=90]
|
||||
\begin{scope}[even odd rule]
|
||||
\clip[rotate=90] \tkzBaffMClip;
|
||||
\path[fill=black] \tkzBaffleC;
|
||||
\end{scope}
|
||||
\begin{scope}[even odd rule]
|
||||
\clip \tkzBaffCClip;
|
||||
\clip \tkzBaffMClip;
|
||||
\path[fill=black, rotate=90] \tkzBaffleM;
|
||||
\end{scope}
|
||||
\end{scope}}
|
||||
\end{tikzpicture}
|
||||
\end{document}
|
||||
BIN
docs/source/_images/nearest-neighbor-example.png
Normal file
BIN
docs/source/_images/nearest-neighbor-example.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
BIN
docs/source/_images/nearest-neighbor.png
Normal file
BIN
docs/source/_images/nearest-neighbor.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4 KiB |
BIN
docs/source/_images/openmc_logo.png
Normal file
BIN
docs/source/_images/openmc_logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
60
docs/source/_images/openmc_logo.svg
Normal file
60
docs/source/_images/openmc_logo.svg
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
width="257.157px" height="60px" viewBox="0 0 257.157 60" enable-background="new 0 0 257.157 60" xml:space="preserve">
|
||||
<g>
|
||||
<g>
|
||||
<path fill="#656565" d="M81.676,48.809c-2.67,0-5.128-0.469-7.367-1.409c-2.243-0.937-4.179-2.206-5.81-3.805
|
||||
c-1.632-1.601-2.901-3.477-3.807-5.638c-0.908-2.158-1.36-4.475-1.36-6.947v-0.099c0-2.472,0.46-4.788,1.385-6.945
|
||||
c0.922-2.159,2.199-4.057,3.832-5.688c1.63-1.631,3.576-2.916,5.834-3.856s4.724-1.409,7.392-1.409
|
||||
c2.67,0,5.125,0.469,7.367,1.409s4.179,2.21,5.812,3.808c1.63,1.6,2.899,3.479,3.805,5.637c0.907,2.161,1.361,4.476,1.361,6.947
|
||||
v0.099c0,2.472-0.463,4.79-1.385,6.945c-0.922,2.161-2.2,4.059-3.832,5.688c-1.63,1.629-3.576,2.918-5.834,3.854
|
||||
C86.81,48.34,84.344,48.809,81.676,48.809z M81.773,41.788c1.517,0,2.918-0.279,4.203-0.839c1.286-0.561,2.382-1.336,3.288-2.325
|
||||
c0.907-0.986,1.614-2.131,2.126-3.437c0.512-1.302,0.768-2.694,0.768-4.178v-0.099c0-1.481-0.256-2.883-0.768-4.202
|
||||
c-0.512-1.318-1.235-2.475-2.175-3.461c-0.94-0.991-2.053-1.771-3.338-2.35c-1.285-0.576-2.687-0.864-4.201-0.864
|
||||
c-1.552,0-2.958,0.279-4.228,0.838c-1.27,0.562-2.358,1.336-3.264,2.327c-0.907,0.987-1.616,2.132-2.125,3.436
|
||||
c-0.511,1.303-0.768,2.693-0.768,4.178v0.099c0,1.483,0.257,2.884,0.768,4.205c0.51,1.318,1.234,2.47,2.175,3.46
|
||||
c0.939,0.988,2.042,1.772,3.313,2.347C78.815,41.499,80.224,41.788,81.773,41.788z"/>
|
||||
<path fill="#656565" d="M102.145,21.715h7.516v3.808c0.924-1.253,2.035-2.283,3.338-3.09c1.301-0.809,2.942-1.211,4.92-1.211
|
||||
c1.549,0,3.048,0.297,4.498,0.889c1.453,0.594,2.737,1.475,3.859,2.645c1.119,1.17,2.019,2.604,2.694,4.301
|
||||
c0.675,1.7,1.013,3.652,1.013,5.859v0.1c0,2.209-0.338,4.162-1.013,5.858c-0.675,1.697-1.565,3.133-2.67,4.301
|
||||
c-1.105,1.173-2.381,2.054-3.832,2.648c-1.452,0.594-2.966,0.889-4.548,0.889c-2.012,0-3.667-0.397-4.971-1.187
|
||||
c-1.302-0.79-2.396-1.712-3.287-2.768v11.371h-7.516V21.715z M115.989,42.332c0.889,0,1.722-0.172,2.498-0.518
|
||||
c0.773-0.348,1.458-0.843,2.051-1.484c0.592-0.641,1.064-1.408,1.409-2.298c0.347-0.89,0.52-1.896,0.52-3.018v-0.1
|
||||
c0-1.087-0.173-2.082-0.52-2.99c-0.345-0.907-0.816-1.682-1.409-2.325c-0.593-0.642-1.278-1.137-2.051-1.482
|
||||
c-0.776-0.345-1.609-0.52-2.498-0.52s-1.722,0.175-2.496,0.52c-0.775,0.346-1.451,0.841-2.028,1.482
|
||||
c-0.577,0.644-1.037,1.418-1.385,2.325c-0.345,0.908-0.518,1.903-0.518,2.99v0.1c0,1.087,0.173,2.086,0.518,2.991
|
||||
c0.348,0.906,0.808,1.684,1.385,2.324c0.577,0.642,1.253,1.137,2.028,1.484C114.267,42.16,115.101,42.332,115.989,42.332z"/>
|
||||
<path fill="#656565" d="M145.62,48.809c-1.979,0-3.814-0.329-5.514-0.986c-1.696-0.661-3.162-1.6-4.399-2.816
|
||||
c-1.237-1.223-2.199-2.666-2.891-4.331c-0.693-1.661-1.041-3.517-1.041-5.559v-0.102c0-1.877,0.321-3.658,0.964-5.34
|
||||
c0.645-1.682,1.543-3.147,2.695-4.4c1.154-1.251,2.53-2.241,4.129-2.967c1.6-0.725,3.37-1.086,5.316-1.086
|
||||
c2.206,0,4.118,0.394,5.733,1.187c1.617,0.791,2.958,1.854,4.03,3.188c1.072,1.335,1.864,2.867,2.374,4.598
|
||||
c0.511,1.731,0.766,3.537,0.766,5.417c0,0.295-0.008,0.61-0.024,0.938c-0.016,0.331-0.04,0.676-0.074,1.038h-18.442
|
||||
c0.364,1.716,1.112,3.009,2.25,3.881c1.138,0.873,2.547,1.313,4.228,1.313c1.251,0,2.373-0.216,3.363-0.646
|
||||
c0.988-0.427,2.01-1.118,3.064-2.076l4.304,3.81c-1.254,1.547-2.771,2.76-4.552,3.633C150.12,48.372,148.026,48.809,145.62,48.809
|
||||
z M150.464,32.89c-0.227-1.681-0.821-3.042-1.777-4.08c-0.956-1.037-2.226-1.557-3.807-1.557c-1.582,0-2.861,0.512-3.832,1.53
|
||||
c-0.973,1.023-1.607,2.393-1.904,4.106H150.464z"/>
|
||||
<path fill="#656565" d="M159.415,21.715h7.518v3.787c0.428-0.562,0.896-1.103,1.408-1.616c0.512-0.517,1.08-0.971,1.706-1.371
|
||||
c0.625-0.397,1.318-0.712,2.078-0.946c0.757-0.233,1.613-0.347,2.569-0.347c2.867,0,5.084,0.873,6.65,2.619
|
||||
c1.565,1.746,2.35,4.152,2.35,7.219v17.156h-7.518V33.471c0-1.776-0.395-3.118-1.186-4.021c-0.792-0.903-1.913-1.355-3.361-1.355
|
||||
c-1.451,0-2.598,0.452-3.437,1.355c-0.841,0.903-1.261,2.245-1.261,4.021v14.745h-7.518V21.715z"/>
|
||||
<path fill="#A31F34" d="M187.056,13.607h8.209l9.095,14.634l9.099-14.634h8.207v34.608h-7.513V25.619l-9.742,14.784h-0.196
|
||||
l-9.645-14.634v22.446h-7.514V13.607z"/>
|
||||
<path fill="#A31F34" d="M242.235,48.809c-2.537,0-4.893-0.459-7.071-1.385c-2.175-0.922-4.052-2.18-5.636-3.78
|
||||
c-1.583-1.601-2.819-3.485-3.709-5.66c-0.888-2.179-1.333-4.501-1.333-6.974v-0.099c0-2.472,0.445-4.788,1.333-6.945
|
||||
c0.89-2.159,2.126-4.057,3.709-5.688c1.584-1.631,3.477-2.916,5.687-3.856c2.207-0.94,4.647-1.409,7.317-1.409
|
||||
c1.613,0,3.091,0.132,4.425,0.396c1.336,0.265,2.547,0.625,3.635,1.089c1.088,0.461,2.093,1.021,3.016,1.682
|
||||
c0.923,0.657,1.781,1.385,2.57,2.175l-4.846,5.586c-1.349-1.218-2.728-2.175-4.128-2.866c-1.401-0.692-2.974-1.038-4.721-1.038
|
||||
c-1.453,0-2.793,0.279-4.03,0.838c-1.235,0.562-2.299,1.336-3.188,2.327c-0.89,0.987-1.582,2.132-2.077,3.436
|
||||
c-0.494,1.303-0.742,2.693-0.742,4.178v0.099c0,1.483,0.248,2.884,0.742,4.205c0.495,1.318,1.178,2.47,2.053,3.46
|
||||
c0.872,0.988,1.929,1.772,3.164,2.347c1.235,0.576,2.594,0.865,4.079,0.865c1.979,0,3.65-0.362,5.02-1.086
|
||||
c1.366-0.726,2.726-1.714,4.079-2.968l4.844,4.895c-0.89,0.958-1.814,1.814-2.768,2.571c-0.958,0.758-2.003,1.411-3.142,1.953
|
||||
c-1.136,0.544-2.379,0.959-3.733,1.236C245.433,48.669,243.915,48.809,242.235,48.809z"/>
|
||||
</g>
|
||||
<path fill="#A31F34" d="M30.614,1.024c-10.866,0-20.325,5.991-25.284,14.845h20.495l13.167,22.804l-11.609,20.11
|
||||
c1.062,0.119,2.139,0.192,3.231,0.192c16.003,0,28.975-12.972,28.975-28.976C59.589,13.997,46.617,1.024,30.614,1.024z"/>
|
||||
<path fill="#656565" d="M16.416,55.243h5.807l9.567-16.57l-9.567-16.566H3.093l-0.607,1.052C1.954,25.355,1.639,27.638,1.639,30
|
||||
C1.639,40.84,7.603,50.274,16.416,55.243z"/>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.9 KiB |
BIN
docs/source/_images/plotmeshtally.png
Normal file
BIN
docs/source/_images/plotmeshtally.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 71 KiB |
BIN
docs/source/_images/prod.png
Normal file
BIN
docs/source/_images/prod.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
711
docs/source/_images/rect_lat.svg
Normal file
711
docs/source/_images/rect_lat.svg
Normal file
|
|
@ -0,0 +1,711 @@
|
|||
<?xml version="1.0" encoding="utf-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
|
||||
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<!-- Created with matplotlib (http://matplotlib.org/) -->
|
||||
<svg height="513pt" version="1.1" viewBox="0 0 513 513" width="513pt" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<defs>
|
||||
<style type="text/css">
|
||||
*{stroke-linecap:butt;stroke-linejoin:round;}
|
||||
</style>
|
||||
</defs>
|
||||
<g id="figure_1">
|
||||
<g id="patch_1">
|
||||
<path d="
|
||||
M0 513
|
||||
L513 513
|
||||
L513 0
|
||||
L0 0
|
||||
z
|
||||
" style="fill:#ffffff;"/>
|
||||
</g>
|
||||
<g id="axes_1">
|
||||
<g id="patch_2">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M42.75 470.25
|
||||
L128.25 470.25
|
||||
L128.25 384.75
|
||||
L42.75 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_3">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M47.025 465.975
|
||||
L123.975 465.975
|
||||
L123.975 389.025
|
||||
L47.025 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_4">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M128.25 470.25
|
||||
L213.75 470.25
|
||||
L213.75 384.75
|
||||
L128.25 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_5">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M132.525 465.975
|
||||
L209.475 465.975
|
||||
L209.475 389.025
|
||||
L132.525 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_6">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M213.75 470.25
|
||||
L299.25 470.25
|
||||
L299.25 384.75
|
||||
L213.75 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_7">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M218.025 465.975
|
||||
L294.975 465.975
|
||||
L294.975 389.025
|
||||
L218.025 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_8">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M299.25 470.25
|
||||
L384.75 470.25
|
||||
L384.75 384.75
|
||||
L299.25 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_9">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M303.525 465.975
|
||||
L380.475 465.975
|
||||
L380.475 389.025
|
||||
L303.525 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_10">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M384.75 470.25
|
||||
L470.25 470.25
|
||||
L470.25 384.75
|
||||
L384.75 384.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_11">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M389.025 465.975
|
||||
L465.975 465.975
|
||||
L465.975 389.025
|
||||
L389.025 389.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_12">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M42.75 384.75
|
||||
L128.25 384.75
|
||||
L128.25 299.25
|
||||
L42.75 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_13">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M47.025 380.475
|
||||
L123.975 380.475
|
||||
L123.975 303.525
|
||||
L47.025 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_14">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M128.25 384.75
|
||||
L213.75 384.75
|
||||
L213.75 299.25
|
||||
L128.25 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_15">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M132.525 380.475
|
||||
L209.475 380.475
|
||||
L209.475 303.525
|
||||
L132.525 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_16">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M213.75 384.75
|
||||
L299.25 384.75
|
||||
L299.25 299.25
|
||||
L213.75 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_17">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M218.025 380.475
|
||||
L294.975 380.475
|
||||
L294.975 303.525
|
||||
L218.025 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_18">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M299.25 384.75
|
||||
L384.75 384.75
|
||||
L384.75 299.25
|
||||
L299.25 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_19">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M303.525 380.475
|
||||
L380.475 380.475
|
||||
L380.475 303.525
|
||||
L303.525 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_20">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M384.75 384.75
|
||||
L470.25 384.75
|
||||
L470.25 299.25
|
||||
L384.75 299.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_21">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M389.025 380.475
|
||||
L465.975 380.475
|
||||
L465.975 303.525
|
||||
L389.025 303.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_22">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M42.75 299.25
|
||||
L128.25 299.25
|
||||
L128.25 213.75
|
||||
L42.75 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_23">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M47.025 294.975
|
||||
L123.975 294.975
|
||||
L123.975 218.025
|
||||
L47.025 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_24">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M128.25 299.25
|
||||
L213.75 299.25
|
||||
L213.75 213.75
|
||||
L128.25 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_25">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M132.525 294.975
|
||||
L209.475 294.975
|
||||
L209.475 218.025
|
||||
L132.525 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_26">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M213.75 299.25
|
||||
L299.25 299.25
|
||||
L299.25 213.75
|
||||
L213.75 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_27">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M218.025 294.975
|
||||
L294.975 294.975
|
||||
L294.975 218.025
|
||||
L218.025 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_28">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M299.25 299.25
|
||||
L384.75 299.25
|
||||
L384.75 213.75
|
||||
L299.25 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_29">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M303.525 294.975
|
||||
L380.475 294.975
|
||||
L380.475 218.025
|
||||
L303.525 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_30">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M384.75 299.25
|
||||
L470.25 299.25
|
||||
L470.25 213.75
|
||||
L384.75 213.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_31">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M389.025 294.975
|
||||
L465.975 294.975
|
||||
L465.975 218.025
|
||||
L389.025 218.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_32">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M42.75 213.75
|
||||
L128.25 213.75
|
||||
L128.25 128.25
|
||||
L42.75 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_33">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M47.025 209.475
|
||||
L123.975 209.475
|
||||
L123.975 132.525
|
||||
L47.025 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_34">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M128.25 213.75
|
||||
L213.75 213.75
|
||||
L213.75 128.25
|
||||
L128.25 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_35">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M132.525 209.475
|
||||
L209.475 209.475
|
||||
L209.475 132.525
|
||||
L132.525 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_36">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M213.75 213.75
|
||||
L299.25 213.75
|
||||
L299.25 128.25
|
||||
L213.75 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_37">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M218.025 209.475
|
||||
L294.975 209.475
|
||||
L294.975 132.525
|
||||
L218.025 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_38">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M299.25 213.75
|
||||
L384.75 213.75
|
||||
L384.75 128.25
|
||||
L299.25 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_39">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M303.525 209.475
|
||||
L380.475 209.475
|
||||
L380.475 132.525
|
||||
L303.525 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_40">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M384.75 213.75
|
||||
L470.25 213.75
|
||||
L470.25 128.25
|
||||
L384.75 128.25
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_41">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M389.025 209.475
|
||||
L465.975 209.475
|
||||
L465.975 132.525
|
||||
L389.025 132.525
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_42">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M42.75 128.25
|
||||
L128.25 128.25
|
||||
L128.25 42.75
|
||||
L42.75 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_43">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M47.025 123.975
|
||||
L123.975 123.975
|
||||
L123.975 47.025
|
||||
L47.025 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_44">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M128.25 128.25
|
||||
L213.75 128.25
|
||||
L213.75 42.75
|
||||
L128.25 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_45">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M132.525 123.975
|
||||
L209.475 123.975
|
||||
L209.475 47.025
|
||||
L132.525 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_46">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M213.75 128.25
|
||||
L299.25 128.25
|
||||
L299.25 42.75
|
||||
L213.75 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_47">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M218.025 123.975
|
||||
L294.975 123.975
|
||||
L294.975 47.025
|
||||
L218.025 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_48">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M299.25 128.25
|
||||
L384.75 128.25
|
||||
L384.75 42.75
|
||||
L299.25 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_49">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M303.525 123.975
|
||||
L380.475 123.975
|
||||
L380.475 47.025
|
||||
L303.525 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="patch_50">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M384.75 128.25
|
||||
L470.25 128.25
|
||||
L470.25 42.75
|
||||
L384.75 42.75
|
||||
z
|
||||
" style="stroke:#000000;"/>
|
||||
</g>
|
||||
<g id="patch_51">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M389.025 123.975
|
||||
L465.975 123.975
|
||||
L465.975 47.025
|
||||
L389.025 47.025
|
||||
z
|
||||
" style="fill:#ffffff;stroke:#ffffff;"/>
|
||||
</g>
|
||||
<g id="line2d_1">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M85.5 513
|
||||
L85.5 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_2">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M171 513
|
||||
L171 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_3">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M256.5 513
|
||||
L256.5 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_4">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M342 513
|
||||
L342 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_5">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M427.5 513
|
||||
L427.5 0" style="fill:none;stroke:#0000ff;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_6">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 427.5
|
||||
L513 427.5" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_7">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 342
|
||||
L513 342" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_8">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 256.5
|
||||
L513 256.5" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_9">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 171
|
||||
L513 171" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="line2d_10">
|
||||
<path clip-path="url(#p5382b9a736)" d="
|
||||
M0 85.5
|
||||
L513 85.5" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-width:3;"/>
|
||||
</g>
|
||||
<g id="text_1">
|
||||
<!-- 1 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M12.4062 8.29688
|
||||
L28.5156 8.29688
|
||||
L28.5156 63.9219
|
||||
L10.9844 60.4062
|
||||
L10.9844 69.3906
|
||||
L28.4219 72.9062
|
||||
L38.2812 72.9062
|
||||
L38.2812 8.29688
|
||||
L54.3906 8.29688
|
||||
L54.3906 0
|
||||
L12.4062 0
|
||||
z
|
||||
" id="DejaVuSans-31"/>
|
||||
</defs>
|
||||
<g transform="translate(94.05 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_2">
|
||||
<!-- 2 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M19.1875 8.29688
|
||||
L53.6094 8.29688
|
||||
L53.6094 0
|
||||
L7.32812 0
|
||||
L7.32812 8.29688
|
||||
Q12.9375 14.1094 22.625 23.8906
|
||||
Q32.3281 33.6875 34.8125 36.5312
|
||||
Q39.5469 41.8438 41.4219 45.5312
|
||||
Q43.3125 49.2188 43.3125 52.7812
|
||||
Q43.3125 58.5938 39.2344 62.25
|
||||
Q35.1562 65.9219 28.6094 65.9219
|
||||
Q23.9688 65.9219 18.8125 64.3125
|
||||
Q13.6719 62.7031 7.8125 59.4219
|
||||
L7.8125 69.3906
|
||||
Q13.7656 71.7812 18.9375 73
|
||||
Q24.125 74.2188 28.4219 74.2188
|
||||
Q39.75 74.2188 46.4844 68.5469
|
||||
Q53.2188 62.8906 53.2188 53.4219
|
||||
Q53.2188 48.9219 51.5312 44.8906
|
||||
Q49.8594 40.875 45.4062 35.4062
|
||||
Q44.1875 33.9844 37.6406 27.2188
|
||||
Q31.1094 20.4531 19.1875 8.29688" id="DejaVuSans-32"/>
|
||||
</defs>
|
||||
<g transform="translate(179.55 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-32"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_3">
|
||||
<!-- 3 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M40.5781 39.3125
|
||||
Q47.6562 37.7969 51.625 33
|
||||
Q55.6094 28.2188 55.6094 21.1875
|
||||
Q55.6094 10.4062 48.1875 4.48438
|
||||
Q40.7656 -1.42188 27.0938 -1.42188
|
||||
Q22.5156 -1.42188 17.6562 -0.515625
|
||||
Q12.7969 0.390625 7.625 2.20312
|
||||
L7.625 11.7188
|
||||
Q11.7188 9.32812 16.5938 8.10938
|
||||
Q21.4844 6.89062 26.8125 6.89062
|
||||
Q36.0781 6.89062 40.9375 10.5469
|
||||
Q45.7969 14.2031 45.7969 21.1875
|
||||
Q45.7969 27.6406 41.2812 31.2656
|
||||
Q36.7656 34.9062 28.7188 34.9062
|
||||
L20.2188 34.9062
|
||||
L20.2188 43.0156
|
||||
L29.1094 43.0156
|
||||
Q36.375 43.0156 40.2344 45.9219
|
||||
Q44.0938 48.8281 44.0938 54.2969
|
||||
Q44.0938 59.9062 40.1094 62.9062
|
||||
Q36.1406 65.9219 28.7188 65.9219
|
||||
Q24.6562 65.9219 20.0156 65.0312
|
||||
Q15.375 64.1562 9.8125 62.3125
|
||||
L9.8125 71.0938
|
||||
Q15.4375 72.6562 20.3438 73.4375
|
||||
Q25.25 74.2188 29.5938 74.2188
|
||||
Q40.8281 74.2188 47.3594 69.1094
|
||||
Q53.9062 64.0156 53.9062 55.3281
|
||||
Q53.9062 49.2656 50.4375 45.0938
|
||||
Q46.9688 40.9219 40.5781 39.3125" id="DejaVuSans-33"/>
|
||||
</defs>
|
||||
<g transform="translate(265.05 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-33"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_4">
|
||||
<!-- 4 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M37.7969 64.3125
|
||||
L12.8906 25.3906
|
||||
L37.7969 25.3906
|
||||
z
|
||||
|
||||
M35.2031 72.9062
|
||||
L47.6094 72.9062
|
||||
L47.6094 25.3906
|
||||
L58.0156 25.3906
|
||||
L58.0156 17.1875
|
||||
L47.6094 17.1875
|
||||
L47.6094 0
|
||||
L37.7969 0
|
||||
L37.7969 17.1875
|
||||
L4.89062 17.1875
|
||||
L4.89062 26.7031
|
||||
z
|
||||
" id="DejaVuSans-34"/>
|
||||
</defs>
|
||||
<g transform="translate(350.55 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-34"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_5">
|
||||
<!-- 5 -->
|
||||
<defs>
|
||||
<path d="
|
||||
M10.7969 72.9062
|
||||
L49.5156 72.9062
|
||||
L49.5156 64.5938
|
||||
L19.8281 64.5938
|
||||
L19.8281 46.7344
|
||||
Q21.9688 47.4688 24.1094 47.8281
|
||||
Q26.2656 48.1875 28.4219 48.1875
|
||||
Q40.625 48.1875 47.75 41.5
|
||||
Q54.8906 34.8125 54.8906 23.3906
|
||||
Q54.8906 11.625 47.5625 5.09375
|
||||
Q40.2344 -1.42188 26.9062 -1.42188
|
||||
Q22.3125 -1.42188 17.5469 -0.640625
|
||||
Q12.7969 0.140625 7.71875 1.70312
|
||||
L7.71875 11.625
|
||||
Q12.1094 9.23438 16.7969 8.0625
|
||||
Q21.4844 6.89062 26.7031 6.89062
|
||||
Q35.1562 6.89062 40.0781 11.3281
|
||||
Q45.0156 15.7656 45.0156 23.3906
|
||||
Q45.0156 31 40.0781 35.4375
|
||||
Q35.1562 39.8906 26.7031 39.8906
|
||||
Q22.75 39.8906 18.8125 39.0156
|
||||
Q14.8906 38.1406 10.7969 36.2812
|
||||
z
|
||||
" id="DejaVuSans-35"/>
|
||||
</defs>
|
||||
<g transform="translate(436.05 504.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-35"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_6">
|
||||
<!-- 1 -->
|
||||
<g transform="translate(8.55 418.95)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-31"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_7">
|
||||
<!-- 2 -->
|
||||
<g transform="translate(8.55 333.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-32"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_8">
|
||||
<!-- 3 -->
|
||||
<g transform="translate(8.55 247.95)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-33"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_9">
|
||||
<!-- 4 -->
|
||||
<g transform="translate(8.55 162.45)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-34"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_10">
|
||||
<!-- 5 -->
|
||||
<g transform="translate(8.55 76.95)scale(0.2 -0.2)">
|
||||
<use xlink:href="#DejaVuSans-35"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<defs>
|
||||
<clipPath id="p5382b9a736">
|
||||
<rect height="513.0" width="513.0" x="0.0" y="0.0"/>
|
||||
</clipPath>
|
||||
</defs>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 15 KiB |
105
docs/source/_images/union.svg
Normal file
105
docs/source/_images/union.svg
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
version="1.1"
|
||||
width="452"
|
||||
height="272"
|
||||
id="svg2">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<metadata
|
||||
id="metadata7">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
transform="translate(-109,-151.36218)"
|
||||
id="layer1">
|
||||
<path
|
||||
d="m 490,287.36218 a 150,85 0 1 1 -300,0 150,85 0 1 1 300,0 z"
|
||||
id="path2987"
|
||||
style="fill:none;stroke:#000000;stroke-width:2;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<path
|
||||
d="m 151,-22.503909 0,269.999999"
|
||||
transform="translate(189,174.86609)"
|
||||
id="path3817"
|
||||
style="fill:none;stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<path
|
||||
d="m -79,127.49609 450,0"
|
||||
transform="translate(189,174.86609)"
|
||||
id="path3819"
|
||||
style="fill:none;stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<path
|
||||
d="m 152.14286,162.63371 0,-33.57143 72.14285,0 c 39.67858,0 72.14286,0.1556 72.14286,0.34577 0,0.83636 -4.22498,8.93075 -6.5305,12.51137 -1.39125,2.16072 -4.89349,6.45329 -7.78275,9.53904 -19.70935,21.04977 -54.95495,36.54118 -96.04389,42.21394 -7.56736,1.04476 -25.70992,2.51107 -31.25,2.52568 l -2.67857,0.007 0,-33.57143 z"
|
||||
transform="translate(189,174.86609)"
|
||||
id="path3821"
|
||||
style="fill:#aab4ff;fill-opacity:1;stroke:none" />
|
||||
<text
|
||||
x="210"
|
||||
y="222.36218"
|
||||
id="text3823"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="210"
|
||||
y="222.36218"
|
||||
id="tspan3825">+1</tspan></text>
|
||||
<text
|
||||
x="240"
|
||||
y="242.36218"
|
||||
id="text3823-0"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="240"
|
||||
y="242.36218"
|
||||
id="tspan3825-1">-1</tspan></text>
|
||||
<text
|
||||
x="315"
|
||||
y="262.36218"
|
||||
id="text3823-0-5"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="315"
|
||||
y="262.36218"
|
||||
id="tspan3825-1-8">-2</tspan></text>
|
||||
<text
|
||||
x="345"
|
||||
y="262.36218"
|
||||
id="text3823-0-5-2"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="345"
|
||||
y="262.36218"
|
||||
id="tspan3825-1-8-2">+2</tspan></text>
|
||||
<text
|
||||
x="260"
|
||||
y="322.36218"
|
||||
id="text3823-0-5-0"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="260"
|
||||
y="322.36218"
|
||||
id="tspan3825-1-8-0">-3</tspan></text>
|
||||
<text
|
||||
x="255"
|
||||
y="297.36218"
|
||||
id="text3823-0-5-2-4"
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"><tspan
|
||||
x="255"
|
||||
y="297.36218"
|
||||
id="tspan3825-1-8-2-2">+3</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.9 KiB |
29
docs/source/_static/theme_overrides.css
Normal file
29
docs/source/_static/theme_overrides.css
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
/* override table width restrictions */
|
||||
.wy-table-responsive table td, .wy-table-responsive table th {
|
||||
white-space: normal;
|
||||
}
|
||||
|
||||
.wy-table-responsive {
|
||||
margin-bottom: 24px;
|
||||
max-width: 100%;
|
||||
overflow: visible;
|
||||
}
|
||||
|
||||
.wy-plain-list-disc, .rst-content .section ul, .rst-content .toctree-wrapper ul, article ul {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.wy-table, .rst-content table.docutils, .rst-content table.field-list {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.wy-side-nav-search {
|
||||
background-color: #343131;
|
||||
}
|
||||
|
||||
/* Make embedded Jupyter notebooks look better */
|
||||
div#notebook-container.container {
|
||||
padding: 0px;
|
||||
width: auto;
|
||||
box-shadow: none;
|
||||
}
|
||||
18
docs/source/_templates/layout.html
Normal file
18
docs/source/_templates/layout.html
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
{% extends "!layout.html" %}
|
||||
|
||||
{% block footer %}
|
||||
{{ super() }}
|
||||
<script type="text/javascript">
|
||||
|
||||
var _gaq = _gaq || [];
|
||||
_gaq.push(['_setAccount', 'UA-30411614-1']);
|
||||
_gaq.push(['_trackPageview']);
|
||||
|
||||
(function() {
|
||||
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
|
||||
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
|
||||
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
|
||||
})();
|
||||
|
||||
</script>
|
||||
{% endblock %}
|
||||
9
docs/source/_templates/mycallable.rst
Normal file
9
docs/source/_templates/mycallable.rst
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
{{ fullname }}
|
||||
{{ underline }}
|
||||
|
||||
.. currentmodule:: {{ module }}
|
||||
|
||||
.. autoclass:: {{ objname }}
|
||||
:members:
|
||||
:special-members: __call__
|
||||
|
||||
7
docs/source/_templates/myclass.rst
Normal file
7
docs/source/_templates/myclass.rst
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
{{ fullname }}
|
||||
{{ underline }}
|
||||
|
||||
.. currentmodule:: {{ module }}
|
||||
|
||||
.. autoclass:: {{ objname }}
|
||||
:members:
|
||||
8
docs/source/_templates/myclassinherit.rst
Normal file
8
docs/source/_templates/myclassinherit.rst
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
{{ fullname }}
|
||||
{{ underline }}
|
||||
|
||||
.. currentmodule:: {{ module }}
|
||||
|
||||
.. autoclass:: {{ objname }}
|
||||
:members:
|
||||
:inherited-members:
|
||||
6
docs/source/_templates/myfunction.rst
Normal file
6
docs/source/_templates/myfunction.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
{{ fullname }}
|
||||
{{ underline }}
|
||||
|
||||
.. currentmodule:: {{ module }}
|
||||
|
||||
.. autofunction:: {{ objname }}
|
||||
9
docs/source/_templates/myintegrator.rst
Normal file
9
docs/source/_templates/myintegrator.rst
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
{{ fullname }}
|
||||
{{ underline }}
|
||||
|
||||
.. currentmodule:: {{ module }}
|
||||
|
||||
.. autoclass:: {{ objname }}
|
||||
:members:
|
||||
:inherited-members:
|
||||
:special-members: __call__, __len__, __iter__
|
||||
596
docs/source/capi/index.rst
Normal file
596
docs/source/capi/index.rst
Normal file
|
|
@ -0,0 +1,596 @@
|
|||
.. _capi:
|
||||
|
||||
=========
|
||||
C/C++ API
|
||||
=========
|
||||
|
||||
The libopenmc shared library that is built when installing OpenMC exports a
|
||||
number of C interoperable functions and global variables that can be used for
|
||||
in-memory coupling. While it is possible to directly use the C/C++ API as
|
||||
documented here for coupling, most advanced users will find it easier to work
|
||||
with the Python bindings in the :py:mod:`openmc.lib` module.
|
||||
|
||||
.. warning:: The C/C++ API is still experimental and may undergo substantial
|
||||
changes in future releases.
|
||||
|
||||
----------------
|
||||
Type Definitions
|
||||
----------------
|
||||
|
||||
.. c:type:: Bank
|
||||
|
||||
Attributes of a source particle.
|
||||
|
||||
.. c:member:: double wgt
|
||||
|
||||
Weight of the particle
|
||||
|
||||
.. c:member:: double xyz[3]
|
||||
|
||||
Position of the particle (units of cm)
|
||||
|
||||
.. c:member:: double uvw[3]
|
||||
|
||||
Unit vector indicating direction of the particle
|
||||
|
||||
.. c:member:: double E
|
||||
|
||||
Energy of the particle in eV
|
||||
|
||||
.. c:member:: int delayed_group
|
||||
|
||||
If the particle is a delayed neutron, indicates which delayed precursor
|
||||
group it was born from. If not a delayed neutron, this member is zero.
|
||||
|
||||
---------
|
||||
Functions
|
||||
---------
|
||||
|
||||
.. c:function:: int openmc_calculate_volumes()
|
||||
|
||||
Run a stochastic volume calculation
|
||||
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_get_fill(int32_t index, int* type, int32_t** indices, int32_t* n)
|
||||
|
||||
Get the fill for a cell
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param int* type: Type of the fill
|
||||
:param int32_t** indices: Array of material indices for cell
|
||||
:param int32_t* n: Length of indices array
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_get_id(int32_t index, int32_t* id)
|
||||
|
||||
Get the ID of a cell
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param int32_t* id: ID of the cell
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_get_temperature(int32_t index, const int32_t* instance, double* T)
|
||||
|
||||
Get the temperature of a cell
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param int32_t* instance: Which instance of the cell. If a null pointer is passed, the temperature
|
||||
of the first instance is returned.
|
||||
:param double* T: temperature of the cell
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_set_fill(int32_t index, int type, int32_t n, const int32_t* indices)
|
||||
|
||||
Set the fill for a cell
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param int type: Type of the fill
|
||||
:param int32_t n: Length of indices array
|
||||
:param indices: Array of material indices for cell
|
||||
:type indices: const int32_t*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_set_id(int32_t index, int32_t id)
|
||||
|
||||
Set the ID of a cell
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param int32_t id: ID of the cell
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_cell_set_temperature(index index, double T, const int32_t* instance)
|
||||
|
||||
Set the temperature of a cell.
|
||||
|
||||
:param int32_t index: Index in the cells array
|
||||
:param double T: Temperature in Kelvin
|
||||
:param instance: Which instance of the cell. To set the temperature for all
|
||||
instances, pass a null pointer.
|
||||
:type instance: const int32_t*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_energy_filter_get_bins(int32_t index, double** energies, int32_t* n)
|
||||
|
||||
Return the bounding energies for an energy filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param double** energies: Bounding energies of the bins for the energy filter
|
||||
:param int32_t* n: Number of energies specified
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_energy_filter_set_bins(int32_t index, int32_t n, const double* energies)
|
||||
|
||||
Set the bounding energies for an energy filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t n: Number of energies specified
|
||||
:param energies: Bounding energies of the bins for the energy filter
|
||||
:type energies: const double*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_extend_cells(int32_t n, int32_t* index_start, int32_t* index_end)
|
||||
|
||||
Extend the cells array by n elements
|
||||
|
||||
:param int32_t n: Number of cells to create
|
||||
:param int32_t* index_start: Index of first new cell
|
||||
:param int32_t* index_end: Index of last new cell
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_extend_filters(int32_t n, int32_t* index_start, int32_t* index_end)
|
||||
|
||||
Extend the filters array by n elements
|
||||
|
||||
:param int32_t n: Number of filters to create
|
||||
:param int32_t* index_start: Index of first new filter
|
||||
:param int32_t* index_end: Index of last new filter
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_extend_materials(int32_t n, int32_t* index_start, int32_t* index_end)
|
||||
|
||||
Extend the materials array by n elements
|
||||
|
||||
:param int32_t n: Number of materials to create
|
||||
:param int32_t* index_start: Index of first new material
|
||||
:param int32_t* index_end: Index of last new material
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_extend_sources(int32_t n, int32_t* index_start, int32_t* index_end)
|
||||
|
||||
Extend the external sources array by n elements
|
||||
|
||||
:param int32_t n: Number of sources to create
|
||||
:param int32_t* index_start: Index of first new source
|
||||
:param int32_t* index_end: Index of last new source
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_extend_tallies(int32_t n, int32_t* index_start, int32_t* index_end)
|
||||
|
||||
Extend the tallies array by n elements
|
||||
|
||||
:param int32_t n: Number of tallies to create
|
||||
:param int32_t* index_start: Index of first new tally
|
||||
:param int32_t* index_end: Index of last new tally
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_filter_get_id(int32_t index, int32_t* id)
|
||||
|
||||
Get the ID of a filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t* id: ID of the filter
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_filter_set_id(int32_t index, int32_t id)
|
||||
|
||||
Set the ID of a filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t id: ID of the filter
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_finalize()
|
||||
|
||||
Finalize a simulation
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_find(double* xyz, int rtype, int32_t* id, int32_t* instance)
|
||||
|
||||
Determine the ID of the cell/material containing a given point
|
||||
|
||||
:param double[3] xyz: Cartesian coordinates
|
||||
:param int rtype: Which ID to return (1=cell, 2=material)
|
||||
:param int32_t* id: ID of the cell/material found. If a material is requested
|
||||
and the point is in a void, the ID is 0. If an error
|
||||
occurs, the ID is -1.
|
||||
:param int32_t* instance: If a cell is repeated in the geometry, the instance
|
||||
of the cell that was found and zero otherwise.
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_get_cell_index(int32_t id, int32_t* index)
|
||||
|
||||
Get the index in the cells array for a cell with a given ID
|
||||
|
||||
:param int32_t id: ID of the cell
|
||||
:param int32_t* index: Index in the cells array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_get_filter_index(int32_t id, int32_t* index)
|
||||
|
||||
Get the index in the filters array for a filter with a given ID
|
||||
|
||||
:param int32_t id: ID of the filter
|
||||
:param int32_t* index: Index in the filters array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: void openmc_get_filter_next_id(int32_t* id)
|
||||
|
||||
Get an integer ID that has not been used by any filters.
|
||||
|
||||
:param int32_t* id: Unused integer ID
|
||||
|
||||
.. c:function:: int openmc_get_keff(double k_combined[2])
|
||||
|
||||
:param double[2] k_combined: Combined estimate of k-effective
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_get_material_index(int32_t id, int32_t* index)
|
||||
|
||||
Get the index in the materials array for a material with a given ID
|
||||
|
||||
:param int32_t id: ID of the material
|
||||
:param int32_t* index: Index in the materials array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_get_nuclide_index(const char name[], int* index)
|
||||
|
||||
Get the index in the nuclides array for a nuclide with a given name
|
||||
|
||||
:param name: Name of the nuclide
|
||||
:type name: const char[]
|
||||
:param int* index: Index in the nuclides array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_get_tally_index(int32_t id, int32_t* index)
|
||||
|
||||
Get the index in the tallies array for a tally with a given ID
|
||||
|
||||
:param int32_t id: ID of the tally
|
||||
:param int32_t* index: Index in the tallies array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_hard_reset()
|
||||
|
||||
Reset tallies, timers, and pseudo-random number generator state
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_init(int argc, char** argv, const void* intracomm)
|
||||
|
||||
Initialize OpenMC
|
||||
|
||||
:param int argc: Number of command-line arguments (including command)
|
||||
:param char** argv: Command-line arguments
|
||||
:param intracomm: MPI intracommunicator. If MPI is not being used, a null
|
||||
pointer should be passed.
|
||||
:type intracomm: const void*
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_load_nuclide(char name[])
|
||||
|
||||
Load data for a nuclide from the HDF5 data library.
|
||||
|
||||
:param char[] name: Name of the nuclide.
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_add_nuclide(int32_t index, const char name[], double density)
|
||||
|
||||
Add a nuclide to an existing material. If the nuclide already exists, the
|
||||
density is overwritten.
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param name: Name of the nuclide
|
||||
:type name: const char[]
|
||||
:param double density: Density in atom/b-cm
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_get_densities(int32_t index, int** nuclides, double** densities, int* n)
|
||||
|
||||
Get density for each nuclide in a material.
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param int** nuclides: Pointer to array of nuclide indices
|
||||
:param double** densities: Pointer to the array of densities
|
||||
:param int* n: Length of the array
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_get_density(int32_t index, double* density)
|
||||
|
||||
Get density of a material.
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param double* denity: Pointer to a density
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_get_id(int32_t index, int32_t* id)
|
||||
|
||||
Get the ID of a material
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param int32_t* id: ID of the material
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_set_density(int32_t index, double density, const char* units)
|
||||
|
||||
Set the density of a material.
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param double density: Density of the material
|
||||
:param units: Units for density
|
||||
:type units: const char*
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_set_densities(int32_t index, int n, const char** name, const double density*)
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param int n: Length of name/density
|
||||
:param name: Array of nuclide names
|
||||
:type name: const char**
|
||||
:param density: Array of densities
|
||||
:type density: const double*
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_set_id(int32_t index, int32_t id)
|
||||
|
||||
Set the ID of a material
|
||||
|
||||
:param int32_t index: Index in the materials array
|
||||
:param int32_t id: ID of the material
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_filter_get_bins(int32_t index, int32_t** bins, int32_t* n)
|
||||
|
||||
Get the bins for a material filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t** bins: Index in the materials array for each bin
|
||||
:param int32_t* n: Number of bins
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_material_filter_set_bins(int32_t index, int32_t n, const int32_t* bins)
|
||||
|
||||
Set the bins for a material filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t n: Number of bins
|
||||
:param bins: Index in the materials array for each bin
|
||||
:type bins: const int32_t*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_mesh_filter_set_mesh(int32_t index, int32_t index_mesh)
|
||||
|
||||
Set the mesh for a mesh filter
|
||||
|
||||
:param int32_t index: Index in the filters array
|
||||
:param int32_t index_mesh: Index in the meshes array
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_next_batch()
|
||||
|
||||
Simulate next batch of particles. Must be called after openmc_simulation_init().
|
||||
|
||||
:return: Integer indicating whether simulation has finished (negative) or not
|
||||
finished (zero).
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_nuclide_name(int index, char** name)
|
||||
|
||||
Get name of a nuclide
|
||||
|
||||
:param int index: Index in the nuclides array
|
||||
:param char** name: Name of the nuclide
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_plot_geometry()
|
||||
|
||||
Run plotting mode.
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_reset()
|
||||
|
||||
Resets all tally scores
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_run()
|
||||
|
||||
Run a simulation
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_simulation_finalize()
|
||||
|
||||
Finalize a simulation.
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_simulation_init()
|
||||
|
||||
Initialize a simulation. Must be called after openmc_init().
|
||||
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_source_bank(struct Bank** ptr, int64_t* n)
|
||||
|
||||
Return a pointer to the source bank array.
|
||||
|
||||
:param ptr: Pointer to the source bank array
|
||||
:type ptr: struct Bank**
|
||||
:param int64_t* n: Length of the source bank array
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_source_set_strength(int32_t index, double strength)
|
||||
|
||||
Set the strength of an external source
|
||||
|
||||
:param int32_t index: Index in the external source array
|
||||
:param double strength: Source strength
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_statepoint_write(const char filename[], const bool* write_source)
|
||||
|
||||
Write a statepoint file
|
||||
|
||||
:param filename: Name of file to create. If a null pointer is passed, a
|
||||
filename is assigned automatically.
|
||||
:type filename: const char[]
|
||||
:param write_source: Whether to include the source bank
|
||||
:type write_source: const bool*
|
||||
:return: Return status (negative if an error occurs)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_get_id(int32_t index, int32_t* id)
|
||||
|
||||
Get the ID of a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int32_t* id: ID of the tally
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_get_filters(int32_t index, int32_t** indices, int* n)
|
||||
|
||||
Get filters specified in a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int32_t** indices: Array of filter indices
|
||||
:param int* n: Number of filters
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_get_n_realizations(int32_t index, int32_t* n)
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int32_t* n: Number of realizations
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_get_nuclides(int32_t index, int** nuclides, int* n)
|
||||
|
||||
Get nuclides specified in a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int** nuclides: Array of nuclide indices
|
||||
:param int* n: Number of nuclides
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_get_scores(int32_t index, int** scores, int* n)
|
||||
|
||||
Get scores specified for a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int** scores: Array of scores
|
||||
:param int* n: Number of scores
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_results(int32_t index, double** ptr, int shape_[3])
|
||||
|
||||
Get a pointer to tally results array.
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param double** ptr: Pointer to the results array
|
||||
:param int[3] shape_: Shape of the results array
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_set_filters(int32_t index, int n, const int32_t* indices)
|
||||
|
||||
Set filters for a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int n: Number of filters
|
||||
:param indices: Array of filter indices
|
||||
:type indices: const int32_t*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_set_id(int32_t index, int32_t id)
|
||||
|
||||
Set the ID of a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int32_t id: ID of the tally
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_set_nuclides(int32_t index, int n, const char** nuclides)
|
||||
|
||||
Set the nuclides for a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int n: Number of nuclides
|
||||
:param nuclides: Array of nuclide names
|
||||
:type nuclides: const char**
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
|
||||
.. c:function:: int openmc_tally_set_scores(int32_t index, int n, const int* scores)
|
||||
|
||||
Set scores for a tally
|
||||
|
||||
:param int32_t index: Index in the tallies array
|
||||
:param int n: Number of scores
|
||||
:param scores: Array of scores
|
||||
:type scores: const int*
|
||||
:return: Return status (negative if an error occurred)
|
||||
:rtype: int
|
||||
260
docs/source/conf.py
Normal file
260
docs/source/conf.py
Normal file
|
|
@ -0,0 +1,260 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# metasci documentation build configuration file, created by
|
||||
# sphinx-quickstart on Sun Feb 7 22:29:49 2010.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import sys, os
|
||||
|
||||
# Determine if we're on Read the Docs server
|
||||
on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
|
||||
|
||||
# On Read the Docs, we need to mock a few third-party modules so we don't get
|
||||
# ImportErrors when building documentation
|
||||
from unittest.mock import MagicMock
|
||||
|
||||
|
||||
MOCK_MODULES = [
|
||||
'numpy', 'numpy.polynomial', 'numpy.polynomial.polynomial',
|
||||
'numpy.ctypeslib', 'scipy', 'scipy.sparse', 'scipy.sparse.linalg',
|
||||
'scipy.interpolate', 'scipy.integrate', 'scipy.optimize', 'scipy.special',
|
||||
'scipy.stats', 'scipy.spatial', 'h5py', 'pandas', 'uncertainties',
|
||||
'matplotlib', 'matplotlib.pyplot', 'openmoc',
|
||||
'openmc.data.reconstruct', 'openmc.checkvalue'
|
||||
]
|
||||
sys.modules.update((mod_name, MagicMock()) for mod_name in MOCK_MODULES)
|
||||
|
||||
import numpy as np
|
||||
np.ndarray = MagicMock
|
||||
np.polynomial.Polynomial = MagicMock
|
||||
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
sys.path.insert(0, os.path.abspath('../sphinxext'))
|
||||
sys.path.insert(0, os.path.abspath('../..'))
|
||||
|
||||
|
||||
# -- General configuration -----------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be extensions
|
||||
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
||||
extensions = ['sphinx.ext.autodoc',
|
||||
'sphinx.ext.napoleon',
|
||||
'sphinx.ext.autosummary',
|
||||
'sphinx.ext.intersphinx',
|
||||
'sphinx.ext.viewcode',
|
||||
'sphinxcontrib.katex',
|
||||
'sphinx_numfig',
|
||||
'notebook_sphinxext']
|
||||
if not on_rtd:
|
||||
extensions.append('sphinxcontrib.rsvgconverter')
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The encoding of source files.
|
||||
#source_encoding = 'utf-8'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'OpenMC'
|
||||
copyright = '2011-2019, Massachusetts Institute of Technology and OpenMC contributors'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = "0.11"
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = "0.11.0"
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#language = None
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
#today = ''
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
#today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of documents that shouldn't be included in the build.
|
||||
#unused_docs = []
|
||||
|
||||
# List of directories, relative to source directory, that shouldn't be searched
|
||||
# for source files.
|
||||
exclude_trees = []
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all documents.
|
||||
#default_role = None
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
#add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
#add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
#show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
#pygments_style = 'sphinx'
|
||||
#pygments_style = 'friendly'
|
||||
#pygments_style = 'bw'
|
||||
#pygments_style = 'fruity'
|
||||
#pygments_style = 'manni'
|
||||
pygments_style = 'tango'
|
||||
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
#modindex_common_prefix = []
|
||||
|
||||
|
||||
# -- Options for HTML output ---------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages
|
||||
if not on_rtd:
|
||||
import sphinx_rtd_theme
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
|
||||
|
||||
html_logo = '_images/openmc_logo.png'
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
html_title = "OpenMC Documentation"
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
#html_short_title = None
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
#html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
def setup(app):
|
||||
app.add_stylesheet('theme_overrides.css')
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
#html_last_updated_fmt = '%b %d, %Y'
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
#html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
#html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
#html_use_modindex = True
|
||||
|
||||
# If false, no index is generated.
|
||||
#html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
#html_split_index = False
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
#html_show_sourcelink = True
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
#html_use_opensearch = ''
|
||||
|
||||
# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
|
||||
#html_file_suffix = ''
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'openmcdoc'
|
||||
|
||||
|
||||
|
||||
# -- Options for LaTeX output --------------------------------------------------
|
||||
|
||||
# The paper size ('letter' or 'a4').
|
||||
#latex_paper_size = 'letter'
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#latex_font_size = '10pt'
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title, author, documentclass [howto/manual]).
|
||||
latex_documents = [
|
||||
('index', 'openmc.tex', 'OpenMC Documentation',
|
||||
'OpenMC contributors', 'manual'),
|
||||
]
|
||||
|
||||
latex_elements = {
|
||||
'preamble': r"""
|
||||
\usepackage{enumitem}
|
||||
\usepackage{amsfonts}
|
||||
\usepackage{amsmath}
|
||||
\setlistdepth{99}
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes,snakes,shadows,arrows,calc,decorations.markings,patterns,fit,matrix,spy}
|
||||
\usepackage{fixltx2e}
|
||||
\hypersetup{bookmarksdepth=3}
|
||||
\setcounter{tocdepth}{2}
|
||||
\numberwithin{equation}{section}
|
||||
""",
|
||||
'printindex': r""
|
||||
}
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
#latex_logo = None
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
#latex_use_parts = False
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#latex_preamble = ''
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#latex_use_modindex = True
|
||||
|
||||
#Autodocumentation Flags
|
||||
#autodoc_member_order = "groupwise"
|
||||
#autoclass_content = "both"
|
||||
autosummary_generate = True
|
||||
|
||||
napoleon_use_ivar = True
|
||||
|
||||
intersphinx_mapping = {
|
||||
'python': ('https://docs.python.org/3', None),
|
||||
'numpy': ('https://docs.scipy.org/doc/numpy/', None),
|
||||
'pandas': ('https://pandas.pydata.org/pandas-docs/stable/', None),
|
||||
'matplotlib': ('https://matplotlib.org/', None)
|
||||
}
|
||||
129
docs/source/devguide/contributing.rst
Normal file
129
docs/source/devguide/contributing.rst
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
.. _devguide_contributing:
|
||||
|
||||
======================
|
||||
Contributing to OpenMC
|
||||
======================
|
||||
|
||||
Thank you for considering contributing to OpenMC! We look forward to welcoming
|
||||
new members to the community and will do our best to help you get up to speed.
|
||||
The purpose of this section is to document how the project is managed: how
|
||||
contributions (bug fixes, enhancements, new features) are made, how they are
|
||||
evaluated, who is permitted to merge pull requests, and what happens in the
|
||||
event of disagreements. Once you have read through this section, the
|
||||
:ref:`devguide_workflow` section outlines the actual mechanics of making a
|
||||
contribution (forking, submitting a pull request, etc.).
|
||||
|
||||
The goal of our governance model is to:
|
||||
|
||||
- Encourage new contributions.
|
||||
- Encourage contributors to remain involved.
|
||||
- Avoid unnecessary processes and bureaucracy whenever possible.
|
||||
- Create a transparent decision making process which makes it clear how
|
||||
contributors can be involved in decision making.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
OpenMC uses a liberal contribution model for project governance. Anyone involved
|
||||
in development in a non-trivial capacity is given an opportunity to influence
|
||||
the direction of the project. Project decisions are made through a
|
||||
consensus-seeking process rather than by voting.
|
||||
|
||||
Terminology
|
||||
-----------
|
||||
|
||||
- A *Contributor* is any individual creating or commenting on an issue or pull
|
||||
request.
|
||||
- A *Committer* is a subset of contributors who are authorized to review and
|
||||
merge pull requests.
|
||||
- The *TC* (Technical Committee) is a group of committers who have the authority
|
||||
to make decisions on behalf of the project team in order to resolve disputes.
|
||||
- The *Project Lead* is a single individual who has the authority to make a final
|
||||
decision when the TC is unable to reach consensus.
|
||||
|
||||
Contribution Process
|
||||
--------------------
|
||||
|
||||
Any change to the OpenMC repository must be made through a pull request (PR).
|
||||
This applies to all changes to documentation, code, binary files, etc. Even long
|
||||
term committers and TC members must use pull requests.
|
||||
|
||||
No pull request may be merged without being independently reviewed.
|
||||
|
||||
For non-trivial contributions, pull requests should not be merged for at least
|
||||
36 hours to ensure that contributors in other timezones have time to review.
|
||||
Consideration should be given to weekends and other holiday periods to ensure
|
||||
active committers have reasonable time to become involved in the discussion and
|
||||
review process if they wish. Any committer may request that the review period be
|
||||
extended if they are unable to review the change within 36 hours.
|
||||
|
||||
During review, a committer may request that a specific contributor who is most
|
||||
versed in a particular area review the PR before it can be merged.
|
||||
|
||||
A pull request can be merged by any committer, but only if no objections are
|
||||
raised by any other committer. In the case of an objection being raised, all
|
||||
involved committers should seek consensus through discussion and compromise.
|
||||
|
||||
In the case of an objection being raised in a pull request by another committer,
|
||||
all involved committers should seek to arrive at a consensus by way of
|
||||
addressing concerns being expressed through discussion, compromise on the
|
||||
proposed change, or withdrawal of the proposed change.
|
||||
|
||||
If objections to a PR are made and committers cannot reach a consensus on how to
|
||||
proceed, the decision is escalated to the TC. TC members should regularly
|
||||
discuss pending contributions in order to find a resolution. It is expected that
|
||||
only a small minority of issues be brought to the TC for resolution and that
|
||||
discussion and compromise among committers be the default resolution mechanism.
|
||||
|
||||
Becoming a Committer
|
||||
--------------------
|
||||
|
||||
All contributors who make a non-trivial contribution will be added as a
|
||||
committer in a timely manner. Committers are expected to follow this policy.
|
||||
|
||||
TC Process
|
||||
----------
|
||||
|
||||
Any issues brought to the TC will be addressed among the committee with a
|
||||
consensus-seeking process. The group tries to find a resolution that has no
|
||||
objections among TC members. If a consensus cannot be reached, the Project Lead
|
||||
has the ultimate authority to make a final decision. It is expected that the
|
||||
majority of decisions made by the TC are via a consensus seeking process and
|
||||
that the Project Lead intercedes only as a last resort.
|
||||
|
||||
Resolution may involve returning the issue to committers with suggestions on how
|
||||
to move forward towards a consensus.
|
||||
|
||||
Members can be added to the TC at any time. Any committer can nominate another
|
||||
committer to the TC and the TC uses its standard consensus seeking process to
|
||||
evaluate whether or not to add this new member. Members who do not participate
|
||||
consistently at the level of a majority of the other members are expected to
|
||||
resign.
|
||||
|
||||
In the event that the Project Lead resigns or otherwise steps down, the TC uses
|
||||
a consensus seeking process to choose a new Project Lead.
|
||||
|
||||
Leadership Team
|
||||
---------------
|
||||
|
||||
The TC consists of the following individuals:
|
||||
|
||||
- `Paul Romano <https://github.com/paulromano>`_
|
||||
- `Sterling Harper <https://github.com/smharper>`_
|
||||
- `Adam Nelson <https://github.com/nelsonag>`_
|
||||
- `Benoit Forget <https://github.com/bforget>`_
|
||||
|
||||
The Project Lead is Paul Romano.
|
||||
|
||||
Next Steps
|
||||
----------
|
||||
|
||||
If you are interested in working on a specific feature or helping to address
|
||||
outstanding issues, consider joining the developer's `mailing list
|
||||
<https://groups.google.com/forum/#!forum/openmc-dev>`_ and/or `Slack community
|
||||
<https://openmc.slack.com/signup>`_. Note that some issues have specifically
|
||||
been labeled as good for `first-time contributors
|
||||
<https://github.com/openmc-dev/openmc/issues?q=is%3Aopen+is%3Aissue+label%3AFirst-Timers-Only>`_.
|
||||
Once you're at the point of writing code, make sure your read through the
|
||||
:ref:`devguide_workflow` section to understand the mechanics of making pull
|
||||
requests and what is expected during code reviews.
|
||||
45
docs/source/devguide/docbuild.rst
Normal file
45
docs/source/devguide/docbuild.rst
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
.. _devguide_docbuild:
|
||||
|
||||
=============================
|
||||
Building Sphinx Documentation
|
||||
=============================
|
||||
|
||||
In order to build the documentation in the ``docs`` directory, you will need to
|
||||
have the `Sphinx <https://www.sphinx-doc.org/en/master/>`_ third-party Python
|
||||
package. The easiest way to install Sphinx is via pip:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
pip install sphinx
|
||||
|
||||
Additionally, you will need several Sphinx extensions that can be installed
|
||||
directly with pip:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
pip install sphinx-numfig
|
||||
pip install sphinxcontrib-katex
|
||||
pip install sphinxcontrib-svg2pdfconverter
|
||||
|
||||
-----------------------------------
|
||||
Building Documentation as a Webpage
|
||||
-----------------------------------
|
||||
|
||||
To build the documentation as a webpage (what appears at
|
||||
https://docs.openmc.org), simply go to the ``docs`` directory and run:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
make html
|
||||
|
||||
-------------------------------
|
||||
Building Documentation as a PDF
|
||||
-------------------------------
|
||||
|
||||
To build PDF documentation, you will need to have a LaTeX distribution installed
|
||||
on your computer. Once you have a LaTeX distribution installed, simply go to the
|
||||
``docs`` directory and run:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
make latexpdf
|
||||
56
docs/source/devguide/docker.rst
Normal file
56
docs/source/devguide/docker.rst
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
.. _devguide_docker:
|
||||
|
||||
======================
|
||||
Deployment with Docker
|
||||
======================
|
||||
|
||||
OpenMC can be easily deployed using `Docker <https://www.docker.com/>`_ on any
|
||||
Windows, Mac or Linux system. With Docker running, execute the following
|
||||
command in the shell to build a `Docker image`_ called ``debian/openmc:latest``:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
docker build -t debian/openmc:latest https://github.com/openmc-dev/openmc.git#develop
|
||||
|
||||
.. note:: This may take 5 -- 10 minutes to run to completion.
|
||||
|
||||
This command will execute the instructions in OpenMC's ``Dockerfile`` to
|
||||
build a Docker image with OpenMC installed. The image includes OpenMC with
|
||||
MPICH and parallel HDF5 in the ``/opt/openmc`` directory, and
|
||||
`Miniconda3 <https://conda.io/miniconda.html>`_ with all of the Python
|
||||
pre-requisites (NumPy, SciPy, Pandas, etc.) installed. The
|
||||
`NJOY2016 <https://www.njoy21.io/NJOY2016/>`_ codebase is installed in
|
||||
``/opt/NJOY2016`` to support full functionality and testing of the
|
||||
``openmc.data`` Python module. The publicly available nuclear data libraries
|
||||
necessary to run OpenMC's test suite -- including NNDC and WMP cross sections
|
||||
and ENDF data -- are in the ``/opt/openmc/data directory``, and the
|
||||
corresponding :envvar:`OPENMC_CROSS_SECTIONS`,
|
||||
:envvar:`OPENMC_MULTIPOLE_LIBRARY`, and :envvar:`OPENMC_ENDF_DATA`
|
||||
environment variables are initialized.
|
||||
|
||||
After building the Docker image, you can run the following to see the names of
|
||||
all images on your machine, including ``debian/openmc:latest``:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
docker image ls
|
||||
|
||||
Now you can run the following to create a `Docker container`_ called
|
||||
``my_openmc`` based on the ``debian/openmc:latest`` image:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
docker run -it --name=my_openmc debian/openmc:latest
|
||||
|
||||
This command will open an interactive shell running from within the
|
||||
Docker container where you have access to use OpenMC.
|
||||
|
||||
.. note:: The ``docker run`` command supports many
|
||||
`options <https://docs.docker.com/engine/reference/commandline/run/>`_
|
||||
for spawning containers -- including `mounting volumes`_ from the
|
||||
host filesystem -- which many users will find useful.
|
||||
|
||||
.. _Docker image: https://docs.docker.com/engine/reference/commandline/images/
|
||||
.. _Docker container: https://www.docker.com/resources/what-container
|
||||
.. _options: https://docs.docker.com/engine/reference/commandline/run/
|
||||
.. _mounting volumes: https://docs.docker.com/storage/volumes/
|
||||
21
docs/source/devguide/index.rst
Normal file
21
docs/source/devguide/index.rst
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
.. _devguide:
|
||||
|
||||
=================
|
||||
Developer's Guide
|
||||
=================
|
||||
|
||||
Welcome to the OpenMC Developer's Guide! This guide documents how contributions
|
||||
are made to OpenMC, what style rules exist for the code, how to run tests, and
|
||||
other related topics.
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 2
|
||||
|
||||
contributing
|
||||
workflow
|
||||
styleguide
|
||||
tests
|
||||
user-input
|
||||
docbuild
|
||||
docker
|
||||
241
docs/source/devguide/styleguide.rst
Normal file
241
docs/source/devguide/styleguide.rst
Normal file
|
|
@ -0,0 +1,241 @@
|
|||
.. _devguide_styleguide:
|
||||
|
||||
======================
|
||||
Style Guide for OpenMC
|
||||
======================
|
||||
|
||||
In order to keep the OpenMC code base consistent in style, this guide specifies
|
||||
a number of rules which should be adhered to when modified existing code or
|
||||
adding new code in OpenMC.
|
||||
|
||||
---
|
||||
C++
|
||||
---
|
||||
|
||||
Indentation
|
||||
-----------
|
||||
|
||||
Use two spaces per indentation level.
|
||||
|
||||
Miscellaneous
|
||||
-------------
|
||||
|
||||
Follow the `C++ Core Guidelines`_ except when they conflict with another
|
||||
guideline listed here. For convenience, many important guidelines from that
|
||||
list are repeated here.
|
||||
|
||||
Conform to the C++14 standard.
|
||||
|
||||
Always use C++-style comments (``//``) as opposed to C-style (``/**/``). (It
|
||||
is more difficult to comment out a large section of code that uses C-style
|
||||
comments.)
|
||||
|
||||
Do not use C-style casting. Always use the C++-style casts ``static_cast``,
|
||||
``const_cast``, or ``reinterpret_cast``. (See `ES.49 <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es49-if-you-must-use-a-cast-use-a-named-cast>`_)
|
||||
|
||||
Source Files
|
||||
------------
|
||||
|
||||
Use a ``.cpp`` suffix for code files and ``.h`` for header files.
|
||||
|
||||
Header files should always use include guards with the following style (See
|
||||
`SF.8 <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf8-use-include-guards-for-all-h-files>`_):
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
#ifndef OPENMC_MODULE_NAME_H
|
||||
#define OPENMC_MODULE_NAME_H
|
||||
|
||||
namespace openmc {
|
||||
...
|
||||
content
|
||||
...
|
||||
}
|
||||
|
||||
#endif // OPENMC_MODULE_NAME_H
|
||||
|
||||
Avoid hidden dependencies by always including a related header file first,
|
||||
followed by C/C++ library includes, other library includes, and then local
|
||||
includes. For example:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
// foo.cpp
|
||||
#include "foo.h"
|
||||
|
||||
#include <cstddef>
|
||||
#include <iostream>
|
||||
#include <vector>
|
||||
|
||||
#include "hdf5.h"
|
||||
#include "pugixml.hpp"
|
||||
|
||||
#include "error.h"
|
||||
#include "random_lcg.h"
|
||||
|
||||
Naming
|
||||
------
|
||||
|
||||
Struct and class names should be CamelCase, e.g. ``HexLattice``.
|
||||
|
||||
Functions (including member functions) should be lower-case with underscores,
|
||||
e.g. ``get_indices``.
|
||||
|
||||
Local variables, global variables, and struct/class member variables should be
|
||||
lower-case with underscores (e.g., ``n_cells``) except for physics symbols that
|
||||
are written differently by convention (e.g., ``E`` for energy). Data members of
|
||||
classes (but not structs) additionally have trailing underscores (e.g.,
|
||||
``a_class_member_``).
|
||||
|
||||
The following conventions are used for variables with short names:
|
||||
|
||||
- ``d`` stands for "distance"
|
||||
- ``E`` stands for "energy"
|
||||
- ``p`` stands for "particle"
|
||||
- ``r`` stands for "position"
|
||||
- ``rx`` stands for "reaction"
|
||||
- ``u`` stands for "direction"
|
||||
- ``xs`` stands for "cross section"
|
||||
|
||||
All classes and non-member functions should be declared within the ``openmc``
|
||||
namespace. Global variables must be declared in a namespace nested within the
|
||||
``openmc`` namespace. The following sub-namespaces are in use:
|
||||
|
||||
- ``openmc::data``: Fundamental nuclear data (cross sections, multigroup data,
|
||||
decay constants, etc.)
|
||||
- ``openmc::model``: Variables related to geometry, materials, and tallies
|
||||
- ``openmc::settings``: Global settings / options
|
||||
- ``openmc::simulation``: Variables used only during a simulation
|
||||
|
||||
Accessors and mutators (get and set functions) may be named like
|
||||
variables. These often correspond to actual member variables, but this is not
|
||||
required. For example, ``int count()`` and ``void set_count(int count)``.
|
||||
|
||||
Variables declared constexpr or const that have static storage duration (exist
|
||||
for the duration of the program) should be upper-case with underscores,
|
||||
e.g., ``SQRT_PI``.
|
||||
|
||||
Use C++-style declarator layout (see `NL.18
|
||||
<http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#nl18-use-c-style-declarator-layout>`_):
|
||||
pointer and reference operators in declarations should be placed adject to the
|
||||
base type rather than the variable name. Avoid declaring multiple names in a
|
||||
single declaration to avoid confusion:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
T* p; // good
|
||||
T& p; // good
|
||||
T *p; // bad
|
||||
T* p, q; // misleading
|
||||
|
||||
Curly braces
|
||||
------------
|
||||
|
||||
For a class declaration, the opening brace should be on the same line that
|
||||
lists the name of the class.
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
class Matrix {
|
||||
...
|
||||
};
|
||||
|
||||
For a function definition, the opening and closing braces should each be on
|
||||
their own lines. This helps distinguish function code from the argument list.
|
||||
If the entire function fits on one or two lines, then the braces can be on the
|
||||
same line. e.g.:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
return_type function(type1 arg1, type2 arg2)
|
||||
{
|
||||
content();
|
||||
}
|
||||
|
||||
return_type
|
||||
function_with_many_args(type1 arg1, type2 arg2, type3 arg3,
|
||||
type4 arg4)
|
||||
{
|
||||
content();
|
||||
}
|
||||
|
||||
int return_one() {return 1;}
|
||||
|
||||
int return_one()
|
||||
{return 1;}
|
||||
|
||||
For a conditional, the opening brace should be on the same line as the end of
|
||||
the conditional statement. If there is a following ``else if`` or ``else``
|
||||
statement, the closing brace should be on the same line as that following
|
||||
statement. Otherwise, the closing brace should be on its own line. A one-line
|
||||
conditional can have the closing brace on the same line or it can omit the
|
||||
braces entirely e.g.:
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
if (condition) {
|
||||
content();
|
||||
}
|
||||
|
||||
if (condition1) {
|
||||
content();
|
||||
} else if (condition 2) {
|
||||
more_content();
|
||||
} else {
|
||||
further_content();
|
||||
}
|
||||
|
||||
if (condition) {content()};
|
||||
|
||||
if (condition) content();
|
||||
|
||||
For loops similarly have an opening brace on the same line as the statement and
|
||||
a closing brace on its own line. One-line loops may have the closing brace on
|
||||
the same line or omit the braces entirely.
|
||||
|
||||
.. code-block:: C++
|
||||
|
||||
for (int i = 0; i < 5; i++) {
|
||||
content();
|
||||
}
|
||||
|
||||
for (int i = 0; i < 5; i++) {content();}
|
||||
|
||||
for (int i = 0; i < 5; i++) content();
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
Classes, structs, and functions are to be annotated for the `Doxygen
|
||||
<http://www.doxygen.nl/>`_ documentation generation tool. Use the ``\`` form of
|
||||
Doxygen commands, e.g., ``\brief`` instead of ``@brief``.
|
||||
|
||||
------
|
||||
Python
|
||||
------
|
||||
|
||||
Style for Python code should follow PEP8_.
|
||||
|
||||
Docstrings for functions and methods should follow numpydoc_ style.
|
||||
|
||||
Python code should work with Python 3.4+.
|
||||
|
||||
Use of third-party Python packages should be limited to numpy_, scipy_,
|
||||
matplotlib_, pandas_, and h5py_. Use of other third-party packages must be
|
||||
implemented as optional dependencies rather than required dependencies.
|
||||
|
||||
Prefer pathlib_ when working with filesystem paths over functions in the os_
|
||||
module or other standard-library modules. Functions that accept arguments that
|
||||
represent a filesystem path should work with both strings and Path_ objects.
|
||||
|
||||
.. _C++ Core Guidelines: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
|
||||
.. _PEP8: https://www.python.org/dev/peps/pep-0008/
|
||||
.. _numpydoc: https://numpydoc.readthedocs.io/en/latest/format.html
|
||||
.. _numpy: https://numpy.org/
|
||||
.. _scipy: https://www.scipy.org/
|
||||
.. _matplotlib: https://matplotlib.org/
|
||||
.. _pandas: https://pandas.pydata.org/
|
||||
.. _h5py: https://www.h5py.org/
|
||||
.. _pathlib: https://docs.python.org/3/library/pathlib.html
|
||||
.. _os: https://docs.python.org/3/library/os.html
|
||||
.. _Path: https://docs.python.org/3/library/pathlib.html#pathlib.Path
|
||||
89
docs/source/devguide/tests.rst
Normal file
89
docs/source/devguide/tests.rst
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
.. _devguide_tests:
|
||||
|
||||
==========
|
||||
Test Suite
|
||||
==========
|
||||
|
||||
The OpenMC test suite consists of two parts, a regression test suite and a unit
|
||||
test suite. The regression test suite is based on regression or integrated
|
||||
testing where different types of input files are configured and the full OpenMC
|
||||
code is executed. Results from simulations are compared with expected
|
||||
results. The unit tests are primarily intended to test individual
|
||||
functions/classes in the OpenMC Python API.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
- The test suite relies on the third-party `pytest <https://pytest.org>`_
|
||||
package. To run either or both the regression and unit test suites, it is
|
||||
assumed that you have OpenMC fully installed, i.e., the :ref:`scripts_openmc`
|
||||
executable is available on your :envvar:`PATH` and the :mod:`openmc` Python
|
||||
module is importable. In development where it would be onerous to continually
|
||||
install OpenMC every time a small change is made, it is recommended to install
|
||||
OpenMC in development/editable mode. With setuptools, this is accomplished by
|
||||
running::
|
||||
|
||||
python setup.py develop
|
||||
|
||||
or using pip (recommended)::
|
||||
|
||||
pip install -e .[test]
|
||||
|
||||
- The test suite requires a specific set of cross section data in order for
|
||||
tests to pass. A download URL for the data that OpenMC expects can be found
|
||||
within ``tools/ci/download-xs.sh``.
|
||||
- In addition to the HDF5 data, some tests rely on ENDF files. A download URL
|
||||
for those can also be found in ``tools/ci/download-xs.sh``.
|
||||
- Some tests require `NJOY <https://www.njoy21.io/NJOY2016>`_ to preprocess
|
||||
cross section data. The test suite assumes that you have an ``njoy``
|
||||
executable available on your :envvar:`PATH`.
|
||||
|
||||
Running Tests
|
||||
-------------
|
||||
|
||||
To execute the test suite, go to the ``tests/`` directory and run::
|
||||
|
||||
pytest
|
||||
|
||||
If you want to collect information about source line coverage in the Python API,
|
||||
you must have the `pytest-cov <https://pypi.python.org/pypi/pytest-cov>`_ plugin
|
||||
installed and run::
|
||||
|
||||
pytest --cov=../openmc --cov-report=html
|
||||
|
||||
Generating XML Inputs
|
||||
---------------------
|
||||
|
||||
Many of the regression tests rely on the Python API to build an appropriate
|
||||
model. However, it can sometimes be desirable to work directly with the XML
|
||||
input files rather than having to run a script in order to run the problem/test.
|
||||
To build the input files for a test without actually running the test, you can
|
||||
run::
|
||||
|
||||
pytest --build-inputs <name-of-test>
|
||||
|
||||
Adding Tests to the Regression Suite
|
||||
------------------------------------
|
||||
|
||||
To add a new test to the regression test suite, create a sub-directory in the
|
||||
``tests/regression_tests/`` directory. To configure a test you need to add the
|
||||
following files to your new test directory:
|
||||
|
||||
* OpenMC input XML files, if they are not generated through the Python API
|
||||
* **test.py** - Python test driver script; please refer to other tests to
|
||||
see how to construct. Any output files that are generated during testing
|
||||
must be removed at the end of this script.
|
||||
* **inputs_true.dat** - ASCII file that contains Python API-generated XML
|
||||
files concatenated together. When the test is run, inputs that are
|
||||
generated are compared to this file.
|
||||
* **results_true.dat** - ASCII file that contains the expected results from
|
||||
the test. The file *results_test.dat* is compared to this file during the
|
||||
execution of the python test driver script. When the above files have been
|
||||
created, generate a *results_test.dat* file and copy it to this name and
|
||||
commit. It should be noted that this file should be generated with basic
|
||||
compiler options during openmc configuration and build (e.g., no MPI, no
|
||||
debug/optimization).
|
||||
|
||||
In addition to this description, please see the various types of tests that are
|
||||
already included in the test suite to see how to create them. If all is
|
||||
implemented correctly, the new test will automatically be discovered by pytest.
|
||||
71
docs/source/devguide/user-input.rst
Normal file
71
docs/source/devguide/user-input.rst
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
.. _devguide_user_input:
|
||||
|
||||
=========================
|
||||
Making User Input Changes
|
||||
=========================
|
||||
|
||||
Users are encouraged to use OpenMC's :ref:`pythonapi` to build XML files that
|
||||
the OpenMC solver then reads during the initialization phase. Thus, to modify,
|
||||
add, or remove user input options, changes must be made both within the Python
|
||||
API and the C++ source that reads XML files produced by the Python API. The
|
||||
following steps should be followed to make changes to user input:
|
||||
|
||||
1. Determine the Python class you need to change. For example, if you are adding
|
||||
a new setting, you probably want to change the :class:`openmc.Settings`
|
||||
class. If you are adding a new surface type, you would need to create a
|
||||
subclass of :class:`openmc.Surface`.
|
||||
|
||||
2. To add a new option, the class will need a `property attribute`_. For
|
||||
example, if you wanted to add a "fast_mode" setting, you would need two
|
||||
methods that look like:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
@property
|
||||
def fast_mode(self):
|
||||
...
|
||||
|
||||
@fast_mode.setter
|
||||
def fast_mode(self, fast_mode):
|
||||
...
|
||||
|
||||
3. Make sure that when an instance of the class is exported to XML (usually
|
||||
through a ``export_to_xml()`` or ``to_xml_element()`` method), a new element
|
||||
is written to the appropriate file. OpenMC uses the
|
||||
:mod:`xml.etree.ElementTree` API, so refer to the documentation of that
|
||||
module for guidance on creating elements/attributes.
|
||||
|
||||
4. Make sure that your input can be categorized as one of the datatypes from
|
||||
`XML Schema Part 2`_ and that parsing of the data appropriately reflects
|
||||
this. For example, for a boolean_ value, true can be represented either by
|
||||
"true" or by "1".
|
||||
|
||||
5. Now that you're done with the Python side, you need to make modifications to
|
||||
the C++ codebase. Make appropriate changes in source files (e.g.,
|
||||
settings.cpp). You should use convenience functions defined by
|
||||
xml_interface.cpp.
|
||||
|
||||
6. If you've made changes in the geometry or materials, make sure they are
|
||||
written out to the statepoint or summary files and that the
|
||||
:class:`openmc.StatePoint` and :class:`openmc.Summary` classes read them in.
|
||||
|
||||
7. Finally, a set of `RELAX NG`_ schemas exists that enables validation of input
|
||||
files. You should modify the RELAX NG schema for the file you changed. The
|
||||
easiest way to do this is to change the `compact syntax`_ file
|
||||
(e.g. ``src/relaxng/geometry.rnc``) and then convert it to regular XML syntax
|
||||
using trang_::
|
||||
|
||||
trang geometry.rnc geometry.rng
|
||||
|
||||
For most user input additions and changes, it is simple enough to follow a
|
||||
"monkey see, monkey do" approach. When in doubt, contact your nearest OpenMC
|
||||
developer or send a message to the `developers mailing list`_.
|
||||
|
||||
|
||||
.. _property attribute: https://docs.python.org/3.6/library/functions.html#property
|
||||
.. _XML Schema Part 2: http://www.w3.org/TR/xmlschema-2/
|
||||
.. _boolean: http://www.w3.org/TR/xmlschema-2/#boolean
|
||||
.. _RELAX NG: http://relaxng.org/
|
||||
.. _compact syntax: http://relaxng.org/compact-tutorial-20030326.html
|
||||
.. _trang: http://www.thaiopensource.com/relaxng/trang.html
|
||||
.. _developers mailing list: https://groups.google.com/forum/?fromgroups=#!forum/openmc-dev
|
||||
132
docs/source/devguide/workflow.rst
Normal file
132
docs/source/devguide/workflow.rst
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
.. _devguide_workflow:
|
||||
|
||||
====================
|
||||
Development Workflow
|
||||
====================
|
||||
|
||||
Anyone wishing to make contributions to OpenMC should be fully acquianted and
|
||||
comfortable working with git_ and GitHub_. We assume here that you have git
|
||||
installed on your system, have a GitHub account, and have setup SSH keys to be
|
||||
able to create/push to repositories on GitHub.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Development of OpenMC relies heavily on branching; specifically, we use a
|
||||
branching model sometimes referred to as `git flow`_. If you plan to contribute
|
||||
to OpenMC development, we highly recommend that you read the linked blog post to
|
||||
get a sense of how the branching model works. There are two main branches that
|
||||
always exist: *master* and *develop*. The *master* branch is a stable branch
|
||||
that contains the latest release of the code. The *develop* branch is where any
|
||||
ongoing development takes place prior to a release and is not guaranteed to be
|
||||
stable. When the development team decides that a release should occur, the
|
||||
*develop* branch is merged into *master*.
|
||||
|
||||
All new features, enhancements, and bug fixes should be developed on a branch
|
||||
that branches off of *develop*. When the feature is completed, a `pull request`_
|
||||
is initiated on GitHub that is then reviewed by a committer. If the pull request
|
||||
is satisfactory, it is then merged into *develop*. Note that a committer may not
|
||||
review their own pull request (i.e., an independent code review is required).
|
||||
|
||||
Code Review Criteria
|
||||
--------------------
|
||||
|
||||
In order to be considered suitable for inclusion in the *develop* branch, the
|
||||
following criteria must be satisfied for all proposed changes:
|
||||
|
||||
- Changes have a clear purpose and are useful.
|
||||
- Compiles and passes all tests under multiple build configurations (This is
|
||||
checked by Travis CI).
|
||||
- If appropriate, test cases are added to regression or unit test suites.
|
||||
- No memory leaks (checked with valgrind_).
|
||||
- Conforms to the OpenMC `style guide`_.
|
||||
- No degradation of performance or greatly increased memory usage. This is not a
|
||||
hard rule -- in certain circumstances, a performance loss might be acceptable
|
||||
if there are compelling reasons.
|
||||
- New features/input are documented.
|
||||
- No unnecessary external software dependencies are introduced.
|
||||
|
||||
Contributing
|
||||
------------
|
||||
|
||||
Now that you understand the basic development workflow, let's discuss how an
|
||||
individual to contribute to development. Note that this would apply to both new
|
||||
features and bug fixes. The general steps for contributing are as follows:
|
||||
|
||||
1. Fork the main openmc repository from `openmc-dev/openmc`_. This will create a
|
||||
repository with the same name under your personal account. As such, you can
|
||||
commit to it as you please without disrupting other developers.
|
||||
|
||||
.. image:: ../_images/fork.png
|
||||
|
||||
2. Clone your fork of OpenMC and create a branch that branches off of *develop*:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
git clone git@github.com:yourusername/openmc.git
|
||||
cd openmc
|
||||
git checkout -b newbranch develop
|
||||
|
||||
3. Make your changes on the new branch that you intend to have included in
|
||||
*develop*. If you have made other changes that should not be merged back,
|
||||
ensure that those changes are made on a different branch.
|
||||
|
||||
4. Issue a pull request from GitHub and select the *develop* branch of
|
||||
openmc-dev/openmc as the target.
|
||||
|
||||
At a minimum, you should describe what the changes you've made are and why
|
||||
you are making them. If the changes are related to an oustanding issue, make
|
||||
sure it is cross-referenced.
|
||||
|
||||
5. A committer will review your pull request based on the criteria
|
||||
above. Any issues with the pull request can be discussed directly on the pull
|
||||
request page itself.
|
||||
|
||||
6. After the pull request has been thoroughly vetted, it is merged back into the
|
||||
*develop* branch of openmc-dev/openmc.
|
||||
|
||||
Private Development
|
||||
-------------------
|
||||
|
||||
While the process above depends on the fork of the OpenMC repository being
|
||||
publicly available on GitHub, you may also wish to do development on a private
|
||||
repository for research or commercial purposes. The proper way to do this is to
|
||||
create a complete copy of the OpenMC repository (not a fork from GitHub). The
|
||||
private repository can then either be stored just locally or in conjunction with
|
||||
a private repository on Github (this requires a `paid plan`_). Alternatively,
|
||||
`Bitbucket`_ offers private repositories for free. If you want to merge some
|
||||
changes you've made in your private repository back to openmc-dev/openmc
|
||||
repository, simply follow the steps above with an extra step of pulling a branch
|
||||
from your private repository into a public fork.
|
||||
|
||||
.. _devguide_editable:
|
||||
|
||||
Working in "Development" Mode
|
||||
-----------------------------
|
||||
|
||||
If you are making changes to the Python API during development, it is highly
|
||||
suggested to install the Python API in development/editable mode using
|
||||
pip_. From the root directory of the OpenMC repository, run:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
pip install -e .[test]
|
||||
|
||||
This installs the OpenMC Python package in `"editable" mode
|
||||
<https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs>`_ so
|
||||
that 1) it can be imported from a Python interpreter and 2) any changes made are
|
||||
immediately reflected in the installed version (that is, you don't need to keep
|
||||
reinstalling it). While the same effect can be achieved using the
|
||||
:envvar:`PYTHONPATH` environment variable, this is generally discouraged as it
|
||||
can interfere with virtual environments.
|
||||
|
||||
.. _git: http://git-scm.com/
|
||||
.. _GitHub: https://github.com/
|
||||
.. _git flow: http://nvie.com/git-model
|
||||
.. _valgrind: http://valgrind.org/
|
||||
.. _style guide: https://docs.openmc.org/en/latest/devguide/styleguide.html
|
||||
.. _pull request: https://help.github.com/articles/using-pull-requests
|
||||
.. _openmc-dev/openmc: https://github.com/openmc-dev/openmc
|
||||
.. _paid plan: https://github.com/plans
|
||||
.. _Bitbucket: https://bitbucket.org
|
||||
.. _pip: https://pip.pypa.io/en/stable/
|
||||
13
docs/source/examples/cad-geom.rst
Normal file
13
docs/source/examples/cad-geom.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_cad-geom:
|
||||
|
||||
==========================
|
||||
Using CAD-Based Geometries
|
||||
==========================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/cad-based-geometry.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/candu.rst
Normal file
13
docs/source/examples/candu.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_candu:
|
||||
|
||||
=======================
|
||||
Modeling a CANDU Bundle
|
||||
=======================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/candu.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/expansion-filters.rst
Normal file
13
docs/source/examples/expansion-filters.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_expansion:
|
||||
|
||||
=====================
|
||||
Functional Expansions
|
||||
=====================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/expansion-filters.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/hexagonal.rst
Normal file
13
docs/source/examples/hexagonal.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_hexagonal:
|
||||
|
||||
===========================
|
||||
Modeling Hexagonal Lattices
|
||||
===========================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/hexagonal-lattice.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
62
docs/source/examples/index.rst
Normal file
62
docs/source/examples/index.rst
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
.. _examples:
|
||||
|
||||
========
|
||||
Examples
|
||||
========
|
||||
|
||||
The following series of `Jupyter <https://jupyter.org/>`_ Notebooks provide
|
||||
examples for how to use various features of OpenMC by leveraging the
|
||||
:ref:`pythonapi`.
|
||||
|
||||
-------------
|
||||
General Usage
|
||||
-------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
pincell
|
||||
post-processing
|
||||
pandas-dataframes
|
||||
tally-arithmetic
|
||||
expansion-filters
|
||||
search
|
||||
nuclear-data
|
||||
nuclear-data-resonance-covariance
|
||||
cad-geom
|
||||
pincell-depletion
|
||||
|
||||
--------
|
||||
Geometry
|
||||
--------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
hexagonal
|
||||
triso
|
||||
candu
|
||||
|
||||
------------------------------------
|
||||
Multi-Group Cross Section Generation
|
||||
------------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
mgxs-part-i
|
||||
mgxs-part-ii
|
||||
mgxs-part-iii
|
||||
mdgxs-part-i
|
||||
mdgxs-part-ii
|
||||
|
||||
----------------
|
||||
Multi-Group Mode
|
||||
----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
mg-mode-part-i
|
||||
mg-mode-part-ii
|
||||
mg-mode-part-iii
|
||||
13
docs/source/examples/mdgxs-part-i.rst
Normal file
13
docs/source/examples/mdgxs-part-i.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mdgxs_part_i:
|
||||
|
||||
===================================================================
|
||||
Multi-Group (Delayed) Cross Section Generation Part I: Introduction
|
||||
===================================================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mdgxs-part-i.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mdgxs-part-ii.rst
Normal file
13
docs/source/examples/mdgxs-part-ii.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mdgxs_part_ii:
|
||||
|
||||
=========================================================================
|
||||
Multi-Group (Delayed) Cross Section Generation Part II: Advanced Features
|
||||
=========================================================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mdgxs-part-ii.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mg-mode-part-i.rst
Normal file
13
docs/source/examples/mg-mode-part-i.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mg_mode_part_i:
|
||||
|
||||
=====================================
|
||||
Multi-Group Mode Part I: Introduction
|
||||
=====================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mg-mode-part-i.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mg-mode-part-ii.rst
Normal file
13
docs/source/examples/mg-mode-part-ii.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mg_mode_part_ii:
|
||||
|
||||
=============================================================
|
||||
Multi-Group Mode Part II: MGXS Library Generation With OpenMC
|
||||
=============================================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mg-mode-part-ii.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mg-mode-part-iii.rst
Normal file
13
docs/source/examples/mg-mode-part-iii.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mg_mode_part_iii:
|
||||
|
||||
====================================================
|
||||
Multi-Group Mode Part III: Advanced Feature Showcase
|
||||
====================================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mg-mode-part-iii.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mgxs-part-i.rst
Normal file
13
docs/source/examples/mgxs-part-i.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mgxs_part_i:
|
||||
|
||||
=========================
|
||||
MGXS Part I: Introduction
|
||||
=========================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mgxs-part-i.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mgxs-part-ii.rst
Normal file
13
docs/source/examples/mgxs-part-ii.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mgxs_part_ii:
|
||||
|
||||
===============================
|
||||
MGXS Part II: Advanced Features
|
||||
===============================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mgxs-part-ii.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/mgxs-part-iii.rst
Normal file
13
docs/source/examples/mgxs-part-iii.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_mgxs_part_iii:
|
||||
|
||||
========================
|
||||
MGXS Part III: Libraries
|
||||
========================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/mgxs-part-iii.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/nuclear-data-resonance-covariance.rst
Normal file
13
docs/source/examples/nuclear-data-resonance-covariance.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_nuclear_data_resonance_covariance:
|
||||
|
||||
==================================
|
||||
Nuclear Data: Resonance Covariance
|
||||
==================================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/nuclear-data-resonance-covariance.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/nuclear-data.rst
Normal file
13
docs/source/examples/nuclear-data.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_nuclear_data:
|
||||
|
||||
============
|
||||
Nuclear Data
|
||||
============
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/nuclear-data.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/pandas-dataframes.rst
Normal file
13
docs/source/examples/pandas-dataframes.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _examples_pandas:
|
||||
|
||||
=================
|
||||
Pandas Dataframes
|
||||
=================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/pandas-dataframes.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
14
docs/source/examples/pincell-depletion.rst
Normal file
14
docs/source/examples/pincell-depletion.rst
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
.. _notebook_depletion:
|
||||
|
||||
=================
|
||||
Pincell Depletion
|
||||
=================
|
||||
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/pincell_depletion.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/pincell.rst
Normal file
13
docs/source/examples/pincell.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_pincell:
|
||||
|
||||
===================
|
||||
Modeling a Pin-Cell
|
||||
===================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/pincell.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/post-processing.rst
Normal file
13
docs/source/examples/post-processing.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_post_processing:
|
||||
|
||||
===============
|
||||
Post Processing
|
||||
===============
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/post-processing.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/search.rst
Normal file
13
docs/source/examples/search.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_search:
|
||||
|
||||
==================
|
||||
Criticality Search
|
||||
==================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/search.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
11
docs/source/examples/tally-arithmetic.rst
Normal file
11
docs/source/examples/tally-arithmetic.rst
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
================
|
||||
Tally Arithmetic
|
||||
================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/tally-arithmetic.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
13
docs/source/examples/triso.rst
Normal file
13
docs/source/examples/triso.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _notebook_triso:
|
||||
|
||||
========================
|
||||
Modeling TRISO Particles
|
||||
========================
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. notebook:: ../../../examples/jupyter/triso.ipynb
|
||||
|
||||
.. only:: latex
|
||||
|
||||
IPython notebooks must be viewed in the online HTML documentation.
|
||||
48
docs/source/index.rst
Normal file
48
docs/source/index.rst
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
===========================
|
||||
The OpenMC Monte Carlo Code
|
||||
===========================
|
||||
|
||||
OpenMC is a community-developed Monte Carlo neutron and photon transport
|
||||
simulation code. It is capable of performing fixed source, k-eigenvalue, and
|
||||
subcritical multiplication calculations on models built using either a
|
||||
constructive solid geometry or CAD representation. OpenMC supports both
|
||||
continuous-energy and multigroup transport. The continuous-energy particle
|
||||
interaction data is based on a native HDF5 format that can be generated from ACE
|
||||
files produced by NJOY. Parallelism is enabled via a hybrid MPI and OpenMP
|
||||
programming model.
|
||||
|
||||
OpenMC was originally developed by members of the `Computational Reactor Physics
|
||||
Group <http://crpg.mit.edu>`_ at the `Massachusetts Institute of Technology
|
||||
<http://web.mit.edu>`_ starting in 2011. Various universities, laboratories, and
|
||||
other organizations now contribute to the development of OpenMC. For more
|
||||
information on OpenMC, feel free to send a message to the User's Group `mailing
|
||||
list <https://groups.google.com/forum/?fromgroups=#!forum/openmc-users>`_.
|
||||
|
||||
.. admonition:: Recommended publication for citing
|
||||
:class: tip
|
||||
|
||||
Paul K. Romano, Nicholas E. Horelik, Bryan R. Herman, Adam G. Nelson, Benoit
|
||||
Forget, and Kord Smith, "`OpenMC: A State-of-the-Art Monte Carlo Code for
|
||||
Research and Development <https://doi.org/10.1016/j.anucene.2014.07.048>`_,"
|
||||
*Ann. Nucl. Energy*, **82**, 90--97 (2015).
|
||||
|
||||
.. only:: html
|
||||
|
||||
--------
|
||||
Contents
|
||||
--------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
quickinstall
|
||||
examples/index
|
||||
releasenotes/index
|
||||
methods/index
|
||||
usersguide/index
|
||||
devguide/index
|
||||
pythonapi/index
|
||||
capi/index
|
||||
io_formats/index
|
||||
publications
|
||||
license
|
||||
70
docs/source/io_formats/cross_sections.rst
Normal file
70
docs/source/io_formats/cross_sections.rst
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
.. _io_cross_sections:
|
||||
|
||||
============================================
|
||||
Cross Sections Listing -- cross_sections.xml
|
||||
============================================
|
||||
|
||||
.. _directory_element:
|
||||
|
||||
-----------------------
|
||||
``<directory>`` Element
|
||||
-----------------------
|
||||
|
||||
The ``<directory>`` element specifies a root directory to which the path for all
|
||||
files listed in a :ref:`library_element` are given relative to. This element has
|
||||
no attributes or sub-elements; the directory should be given within the text
|
||||
node. For example,
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<directory>/opt/data/cross_sections/</directory>
|
||||
|
||||
.. _library_element:
|
||||
|
||||
---------------------
|
||||
``<library>`` Element
|
||||
---------------------
|
||||
|
||||
The ``<library>`` element indicates where an HDF5 data file is located, whether
|
||||
it contains incident neutron, incident photon, thermal scattering, or windowed
|
||||
multipole data, and what materials are listed within. It has the following
|
||||
attributes:
|
||||
|
||||
:materials:
|
||||
|
||||
A space-separated list of nuclides or thermal scattering tables. For
|
||||
example,
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<library materials="U234 U235 U238" />
|
||||
<library materials="c_H_in_H2O c_D_in_G2O" />
|
||||
|
||||
Often, just a single nuclide or thermal scattering table is contained in a
|
||||
given file.
|
||||
|
||||
:path:
|
||||
Path to the HDF5 file. If the :ref:`directory_element` is specified, the
|
||||
path is relative to the directory given. Otherwise, it is relative to the
|
||||
directory containing the ``cross_sections.xml`` file.
|
||||
|
||||
:type:
|
||||
The type of data contained in the file. Accepted values are 'neutron',
|
||||
'thermal', 'photon', and 'wmp'.
|
||||
|
||||
.. _depletion_element:
|
||||
|
||||
-----------------------------
|
||||
``<depletion_chain>`` Element
|
||||
-----------------------------
|
||||
|
||||
The ``<depletion_chain>`` element indicates the location of the depletion chain file.
|
||||
This file contains information describing how nuclides decay and transmute to other
|
||||
nuclides through the depletion process. This element has a single attribute, ``path``,
|
||||
pointing to the location of the chain file.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<depletion_chain path="/opt/data/chain_endfb7.xml"/>
|
||||
|
||||
The structure of the depletion chain file is explained in :ref:`io_depletion_chain`.
|
||||
52
docs/source/io_formats/data_wmp.rst
Normal file
52
docs/source/io_formats/data_wmp.rst
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
.. _io_data_wmp:
|
||||
|
||||
=================================
|
||||
Windowed Multipole Library Format
|
||||
=================================
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file
|
||||
- **version** (*int[2]*) -- Major and minor version of the data
|
||||
|
||||
**/<nuclide name>/**
|
||||
|
||||
:Datasets:
|
||||
|
||||
- **broaden_poly** (*int[]*)
|
||||
If 1, Doppler broaden curve fit for window with corresponding index.
|
||||
If 0, do not.
|
||||
- **curvefit** (*double[][][]*)
|
||||
Curve fit coefficients. Indexed by (reaction type, coefficient index,
|
||||
window index).
|
||||
- **data** (*complex[][]*)
|
||||
Complex poles and residues. Each pole has a corresponding set of
|
||||
residues. For example, the :math:`i`-th pole and corresponding residues
|
||||
are stored as
|
||||
|
||||
.. math::
|
||||
\text{data}[:,i] = [\text{pole},~\text{residue}_1,~\text{residue}_2,
|
||||
~\ldots]
|
||||
|
||||
The residues are in the order: scattering, absorption, fission. Complex
|
||||
numbers are stored by forming a type with ":math:`r`" and ":math:`i`"
|
||||
identifiers, similar to how `h5py`_ does it.
|
||||
- **E_max** (*double*)
|
||||
Highest energy the windowed multipole part of the library is valid for.
|
||||
- **E_min** (*double*)
|
||||
Lowest energy the windowed multipole part of the library is valid for.
|
||||
- **spacing** (*double*)
|
||||
.. math::
|
||||
\frac{\sqrt{E_{max}} - \sqrt{E_{min}}}{n_w}
|
||||
|
||||
Where :math:`E_{max}` is the maximum energy the windows go up to.
|
||||
:math:`E_{min}` is the minimum energy, and :math:`n_w` is the number of
|
||||
windows, given by ``windows``.
|
||||
- **sqrtAWR** (*double*)
|
||||
Square root of the atomic weight ratio.
|
||||
- **windows** (*int[][]*)
|
||||
The poles to start from and end at for each window. windows[i, 0] and
|
||||
windows[i, 1] are, respectively, the indexes (1-based) of the first and
|
||||
last pole in window i.
|
||||
|
||||
.. _h5py: http://docs.h5py.org/en/latest/
|
||||
102
docs/source/io_formats/depletion_chain.rst
Normal file
102
docs/source/io_formats/depletion_chain.rst
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
.. _io_depletion_chain:
|
||||
|
||||
============================
|
||||
Depletion Chain -- chain.xml
|
||||
============================
|
||||
|
||||
A depletion chain file has a ``<depletion_chain>`` root element with one or more
|
||||
``<nuclide>`` child elements. The decay, reaction, and fission product data for
|
||||
each nuclide appears as child elements of ``<nuclide>``.
|
||||
|
||||
---------------------
|
||||
``<nuclide>`` Element
|
||||
---------------------
|
||||
|
||||
The ``<nuclide>`` element contains information on the decay modes, reactions,
|
||||
and fission product yields for a given nuclide in the depletion chain. This
|
||||
element may have the following attributes:
|
||||
|
||||
:name:
|
||||
Name of the nuclide
|
||||
|
||||
:half_life:
|
||||
Half-life of the nuclide in [s]
|
||||
|
||||
:decay_modes:
|
||||
Number of decay modes present
|
||||
|
||||
:decay_energy:
|
||||
Decay energy released in [eV]
|
||||
|
||||
:reactions:
|
||||
Number of reactions present
|
||||
|
||||
For each decay mode, a :ref:`io_chain_decay` appears as a child of
|
||||
``<nuclide>``. For each reaction present, a :ref:`io_chain_reaction` appears as
|
||||
a child of ``<nuclide>``. If the nuclide is fissionable, a :ref:`io_chain_nfy`
|
||||
appears as well.
|
||||
|
||||
.. _io_chain_decay:
|
||||
|
||||
-------------------
|
||||
``<decay>`` Element
|
||||
-------------------
|
||||
|
||||
The ``<decay>`` element represents a single decay mode and has the following
|
||||
attributes:
|
||||
|
||||
:type:
|
||||
The type of the decay, e.g. 'ec/beta+'
|
||||
|
||||
:target:
|
||||
The daughter nuclide produced from the decay
|
||||
|
||||
:branching_ratio:
|
||||
The branching ratio for this decay mode
|
||||
|
||||
.. _io_chain_reaction:
|
||||
|
||||
----------------------
|
||||
``<reaction>`` Element
|
||||
----------------------
|
||||
|
||||
The ``<reaction>`` element represents a single transmutation reaction. This
|
||||
element has the following attributes:
|
||||
|
||||
:type:
|
||||
The type of the reaction, e.g., '(n,gamma)'
|
||||
|
||||
:Q:
|
||||
The Q value of the reaction in [eV]
|
||||
|
||||
:target:
|
||||
The nuclide produced in the reaction (absent if the type is 'fission')
|
||||
|
||||
:branching_ratio:
|
||||
The branching ratio for the reaction
|
||||
|
||||
.. _io_chain_nfy:
|
||||
|
||||
------------------------------------
|
||||
``<neutron_fission_yields>`` Element
|
||||
------------------------------------
|
||||
|
||||
The ``<neutron_fission_yields>`` element provides yields of fission products for
|
||||
fissionable nuclides. It has the follow sub-elements:
|
||||
|
||||
:energies:
|
||||
Energies in [eV] at which yields for products are tabulated
|
||||
|
||||
:fission_yields:
|
||||
|
||||
Fission product yields for a single energy point. This element itself has a
|
||||
number of attributes/sub-elements:
|
||||
|
||||
:energy:
|
||||
Energy in [eV] at which yields are tabulated
|
||||
|
||||
:products:
|
||||
Names of fission products
|
||||
|
||||
:data:
|
||||
Independent yields for each fission product
|
||||
53
docs/source/io_formats/depletion_results.rst
Normal file
53
docs/source/io_formats/depletion_results.rst
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
.. _io_depletion_results:
|
||||
|
||||
=============================
|
||||
Depletion Results File Format
|
||||
=============================
|
||||
|
||||
The current version of the depletion results file format is 1.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the
|
||||
statepoint file format.
|
||||
|
||||
:Datasets: - **eigenvalues** (*double[][][2]*) -- k-eigenvalues at each
|
||||
time/stage. This array has shape (number of timesteps, number of
|
||||
stages, value). The last axis contains the eigenvalue and the
|
||||
associated uncertainty
|
||||
- **number** (*double[][][][]*) -- Total number of atoms. This array
|
||||
has shape (number of timesteps, number of stages, number of
|
||||
materials, number of nuclides).
|
||||
- **reaction rates** (*double[][][][][]*) -- Reaction rates used to
|
||||
build depletion matrices. This array has shape (number of
|
||||
timesteps, number of stages, number of materials, number of
|
||||
nuclides, number of reactions).
|
||||
- **time** (*double[][2]*) -- Time in [s] at beginning/end of each
|
||||
step.
|
||||
- **depletion time** (*double[]*) -- Average process time in [s]
|
||||
spent depleting a material across all burnable materials and,
|
||||
if applicable, MPI processes.
|
||||
|
||||
**/materials/<id>/**
|
||||
|
||||
:Attributes: - **index** (*int*) -- Index used in results for this material
|
||||
- **volume** (*double*) -- Volume of this material in [cm^3]
|
||||
|
||||
**/nuclides/<name>/**
|
||||
|
||||
:Attributes: - **atom number index** (*int*) -- Index in array of total atoms
|
||||
for this nuclide
|
||||
- **reaction rate index** (*int*) -- Index in array of reaction
|
||||
rates for this nuclide
|
||||
|
||||
**/reactions/<name>/**
|
||||
|
||||
:Attributes: - **index** (*int*) -- Index user in results for this reaction
|
||||
|
||||
.. note::
|
||||
|
||||
The reaction rates for some isotopes not originally present may
|
||||
be non-zero, but should be negligible compared to other atoms.
|
||||
This can be controlled by changing the
|
||||
:class:`openmc.deplete.Operator` ``dilute_initial`` attribute.
|
||||
372
docs/source/io_formats/geometry.rst
Normal file
372
docs/source/io_formats/geometry.rst
Normal file
|
|
@ -0,0 +1,372 @@
|
|||
.. _io_geometry:
|
||||
|
||||
======================================
|
||||
Geometry Specification -- geometry.xml
|
||||
======================================
|
||||
|
||||
.. _surface_element:
|
||||
|
||||
---------------------
|
||||
``<surface>`` Element
|
||||
---------------------
|
||||
|
||||
Each ``<surface>`` element can have the following attributes or sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the surface.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:name:
|
||||
An optional string name to identify the surface in summary output
|
||||
files. This string is limited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:type:
|
||||
The type of the surfaces. This can be "x-plane", "y-plane", "z-plane",
|
||||
"plane", "x-cylinder", "y-cylinder", "z-cylinder", "sphere", "x-cone",
|
||||
"y-cone", "z-cone", or "quadric".
|
||||
|
||||
*Default*: None
|
||||
|
||||
:coeffs:
|
||||
The corresponding coefficients for the given type of surface. See below for
|
||||
a list a what coefficients to specify for a given surface
|
||||
|
||||
*Default*: None
|
||||
|
||||
:boundary:
|
||||
The boundary condition for the surface. This can be "transmission",
|
||||
"vacuum", "reflective", or "periodic". Periodic boundary conditions can
|
||||
only be applied to x-, y-, and z-planes. Only axis-aligned periodicity is
|
||||
supported, i.e., x-planes can only be paired with x-planes. Specify which
|
||||
planes are periodic and the code will automatically identify which planes
|
||||
are paired together.
|
||||
|
||||
*Default*: "transmission"
|
||||
|
||||
:periodic_surface_id:
|
||||
If a periodic boundary condition is applied, this attribute identifies the
|
||||
``id`` of the corresponding periodic sufrace.
|
||||
|
||||
The following quadratic surfaces can be modeled:
|
||||
|
||||
:x-plane:
|
||||
A plane perpendicular to the x axis, i.e. a surface of the form :math:`x -
|
||||
x_0 = 0`. The coefficients specified are ":math:`x_0`".
|
||||
|
||||
:y-plane:
|
||||
A plane perpendicular to the y axis, i.e. a surface of the form :math:`y -
|
||||
y_0 = 0`. The coefficients specified are ":math:`y_0`".
|
||||
|
||||
:z-plane:
|
||||
A plane perpendicular to the z axis, i.e. a surface of the form :math:`z -
|
||||
z_0 = 0`. The coefficients specified are ":math:`z_0`".
|
||||
|
||||
:plane:
|
||||
An arbitrary plane of the form :math:`Ax + By + Cz = D`. The coefficients
|
||||
specified are ":math:`A \: B \: C \: D`".
|
||||
|
||||
:x-cylinder:
|
||||
An infinite cylinder whose length is parallel to the x-axis. This is a
|
||||
quadratic surface of the form :math:`(y - y_0)^2 + (z - z_0)^2 = R^2`. The
|
||||
coefficients specified are ":math:`y_0 \: z_0 \: R`".
|
||||
|
||||
:y-cylinder:
|
||||
An infinite cylinder whose length is parallel to the y-axis. This is a
|
||||
quadratic surface of the form :math:`(x - x_0)^2 + (z - z_0)^2 = R^2`. The
|
||||
coefficients specified are ":math:`x_0 \: z_0 \: R`".
|
||||
|
||||
:z-cylinder:
|
||||
An infinite cylinder whose length is parallel to the z-axis. This is a
|
||||
quadratic surface of the form :math:`(x - x_0)^2 + (y - y_0)^2 = R^2`. The
|
||||
coefficients specified are ":math:`x_0 \: y_0 \: R`".
|
||||
|
||||
:sphere:
|
||||
A sphere of the form :math:`(x - x_0)^2 + (y - y_0)^2 + (z - z_0)^2 =
|
||||
R^2`. The coefficients specified are ":math:`x_0 \: y_0 \: z_0 \: R`".
|
||||
|
||||
:x-cone:
|
||||
A cone parallel to the x-axis of the form :math:`(y - y_0)^2 + (z - z_0)^2 =
|
||||
R^2 (x - x_0)^2`. The coefficients specified are ":math:`x_0 \: y_0 \: z_0
|
||||
\: R^2`".
|
||||
|
||||
:y-cone:
|
||||
A cone parallel to the y-axis of the form :math:`(x - x_0)^2 + (z - z_0)^2 =
|
||||
R^2 (y - y_0)^2`. The coefficients specified are ":math:`x_0 \: y_0 \: z_0
|
||||
\: R^2`".
|
||||
|
||||
:z-cone:
|
||||
A cone parallel to the x-axis of the form :math:`(x - x_0)^2 + (y - y_0)^2 =
|
||||
R^2 (z - z_0)^2`. The coefficients specified are ":math:`x_0 \: y_0 \: z_0
|
||||
\: R^2`".
|
||||
|
||||
:quadric:
|
||||
A general quadric surface of the form :math:`Ax^2 + By^2 + Cz^2 + Dxy +
|
||||
Eyz + Fxz + Gx + Hy + Jz + K = 0` The coefficients specified are ":math:`A
|
||||
\: B \: C \: D \: E \: F \: G \: H \: J \: K`".
|
||||
|
||||
.. _cell_element:
|
||||
|
||||
------------------
|
||||
``<cell>`` Element
|
||||
------------------
|
||||
|
||||
Each ``<cell>`` element can have the following attributes or sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the cell.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:name:
|
||||
An optional string name to identify the cell in summary output files.
|
||||
This string is limmited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:universe:
|
||||
The ``id`` of the universe that this cell is contained in.
|
||||
|
||||
*Default*: 0
|
||||
|
||||
:fill:
|
||||
The ``id`` of the universe that fills this cell.
|
||||
|
||||
.. note:: If a fill is specified, no material should be given.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:material:
|
||||
The ``id`` of the material that this cell contains. If the cell should
|
||||
contain no material, this can also be set to "void". A list of materials
|
||||
can be specified for the "distributed material" feature. This will give each
|
||||
unique instance of the cell its own material.
|
||||
|
||||
.. note:: If a material is specified, no fill should be given.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:region:
|
||||
A Boolean expression of half-spaces that defines the spatial region which
|
||||
the cell occupies. Each half-space is identified by the unique ID of the
|
||||
surface prefixed by `-` or `+` to indicate that it is the negative or
|
||||
positive half-space, respectively. The `+` sign for a positive half-space
|
||||
can be omitted. Valid Boolean operators are parentheses, union `|`,
|
||||
complement `~`, and intersection. Intersection is implicit and indicated by
|
||||
the presence of whitespace. The order of operator precedence is parentheses,
|
||||
complement, intersection, and then union.
|
||||
|
||||
As an example, the following code gives a cell that is the union of the
|
||||
negative half-space of surface 3 and the complement of the intersection of
|
||||
the positive half-space of surface 5 and the negative half-space of surface
|
||||
2:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<cell id="1" material="1" region="-3 | ~(5 -2)" />
|
||||
|
||||
.. note:: The ``region`` attribute/element can be omitted to make a cell
|
||||
fill its entire universe.
|
||||
|
||||
*Default*: A region filling all space.
|
||||
|
||||
:temperature:
|
||||
The temperature of the cell in Kelvin. If windowed-multipole data is
|
||||
avalable, this temperature will be used to Doppler broaden some cross
|
||||
sections in the resolved resonance region. A list of temperatures can be
|
||||
specified for the "distributed temperature" feature. This will give each
|
||||
unique instance of the cell its own temperature.
|
||||
|
||||
*Default*: If a material default temperature is supplied, it is used. In the
|
||||
absence of a material default temperature, the :ref:`global default
|
||||
temperature <temperature_default>` is used.
|
||||
|
||||
:rotation:
|
||||
If the cell is filled with a universe, this element specifies the angles in
|
||||
degrees about the x, y, and z axes that the filled universe should be
|
||||
rotated. Should be given as three real numbers. For example, if you wanted
|
||||
to rotate the filled universe by 90 degrees about the z-axis, the cell
|
||||
element would look something like:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<cell fill="..." rotation="0 0 90" />
|
||||
|
||||
The rotation applied is an intrinsic rotation whose Tait-Bryan angles are
|
||||
given as those specified about the x, y, and z axes respectively. That is to
|
||||
say, if the angles are :math:`(\phi, \theta, \psi)`, then the rotation
|
||||
matrix applied is :math:`R_z(\psi) R_y(\theta) R_x(\phi)` or
|
||||
|
||||
.. math::
|
||||
|
||||
\left [ \begin{array}{ccc} \cos\theta \cos\psi & -\cos\phi \sin\psi +
|
||||
\sin\phi \sin\theta \cos\psi & \sin\phi \sin\psi + \cos\phi \sin\theta
|
||||
\cos\psi \\ \cos\theta \sin\psi & \cos\phi \cos\psi + \sin\phi \sin\theta
|
||||
\sin\psi & -\sin\phi \cos\psi + \cos\phi \sin\theta \sin\psi \\
|
||||
-\sin\theta & \sin\phi \cos\theta & \cos\phi \cos\theta \end{array}
|
||||
\right ]
|
||||
|
||||
*Default*: None
|
||||
|
||||
:translation:
|
||||
If the cell is filled with a universe, this element specifies a vector that
|
||||
is used to translate (shift) the universe. Should be given as three real
|
||||
numbers.
|
||||
|
||||
.. note:: Any translation operation is applied after a rotation, if also
|
||||
specified.
|
||||
|
||||
*Default*: None
|
||||
|
||||
|
||||
---------------------
|
||||
``<lattice>`` Element
|
||||
---------------------
|
||||
|
||||
The ``<lattice>`` can be used to represent repeating structures (e.g. fuel pins
|
||||
in an assembly) or other geometry which fits onto a rectilinear grid. Each cell
|
||||
within the lattice is filled with a specified universe. A ``<lattice>`` accepts
|
||||
the following attributes or sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the lattice.
|
||||
|
||||
:name:
|
||||
An optional string name to identify the lattice in summary output
|
||||
files. This string is limited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:dimension:
|
||||
Two or three integers representing the number of lattice cells in the x- and
|
||||
y- (and z-) directions, respectively.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:lower_left:
|
||||
The coordinates of the lower-left corner of the lattice. If the lattice is
|
||||
two-dimensional, only the x- and y-coordinates are specified.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:pitch:
|
||||
If the lattice is 3D, then three real numbers that express the distance
|
||||
between the centers of lattice cells in the x-, y-, and z- directions. If
|
||||
the lattice is 2D, then omit the third value.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:outer:
|
||||
The unique integer identifier of a universe that will be used to fill all
|
||||
space outside of the lattice. The universe will be tiled repeatedly as if
|
||||
it were placed in a lattice of infinite size. This element is optional.
|
||||
|
||||
*Default*: An error will be raised if a particle leaves a lattice with no
|
||||
outer universe.
|
||||
|
||||
:universes:
|
||||
A list of the universe numbers that fill each cell of the lattice.
|
||||
|
||||
*Default*: None
|
||||
|
||||
Here is an example of a properly defined 2d rectangular lattice:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<lattice id="10" dimension="3 3" outer="1">
|
||||
<lower_left> -1.5 -1.5 </lower_left>
|
||||
<pitch> 1.0 1.0 </pitch>
|
||||
<universes>
|
||||
2 2 2
|
||||
2 1 2
|
||||
2 2 2
|
||||
</universes>
|
||||
</lattice>
|
||||
|
||||
-------------------------
|
||||
``<hex_lattice>`` Element
|
||||
-------------------------
|
||||
|
||||
The ``<hex_lattice>`` can be used to represent repeating structures (e.g. fuel
|
||||
pins in an assembly) or other geometry which naturally fits onto a hexagonal
|
||||
grid or hexagonal prism grid. Each cell within the lattice is filled with a
|
||||
specified universe. This lattice uses the "flat-topped hexagon" scheme where two
|
||||
of the six edges are perpendicular to the y-axis. A ``<hex_lattice>`` accepts
|
||||
the following attributes or sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the lattice.
|
||||
|
||||
:name:
|
||||
An optional string name to identify the hex_lattice in summary output
|
||||
files. This string is limited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:n_rings:
|
||||
An integer representing the number of radial ring positions in the xy-plane.
|
||||
Note that this number includes the degenerate center ring which only has one
|
||||
element.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:n_axial:
|
||||
An integer representing the number of positions along the z-axis. This
|
||||
element is optional.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:orientation:
|
||||
The orientation of the hexagonal lattice. The string "x" indicates that two
|
||||
sides of the lattice are parallel to the x-axis, whereas the string "y"
|
||||
indicates that two sides are parallel to the y-axis.
|
||||
|
||||
*Default*: "y"
|
||||
|
||||
:center:
|
||||
The coordinates of the center of the lattice. If the lattice does not have
|
||||
axial sections then only the x- and y-coordinates are specified.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:pitch:
|
||||
If the lattice is 3D, then two real numbers that express the distance
|
||||
between the centers of lattice cells in the xy-plane and along the z-axis,
|
||||
respectively. If the lattice is 2D, then omit the second value.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:outer:
|
||||
The unique integer identifier of a universe that will be used to fill all
|
||||
space outside of the lattice. The universe will be tiled repeatedly as if
|
||||
it were placed in a lattice of infinite size. This element is optional.
|
||||
|
||||
*Default*: An error will be raised if a particle leaves a lattice with no
|
||||
outer universe.
|
||||
|
||||
:universes:
|
||||
A list of the universe numbers that fill each cell of the lattice.
|
||||
|
||||
*Default*: None
|
||||
|
||||
Here is an example of a properly defined 2d hexagonal lattice:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<hex_lattice id="10" n_rings="3" outer="1">
|
||||
<center> 0.0 0.0 </center>
|
||||
<pitch> 1.0 </pitch>
|
||||
<universes>
|
||||
202
|
||||
202 202
|
||||
202 202 202
|
||||
202 202
|
||||
202 101 202
|
||||
202 202
|
||||
202 202 202
|
||||
202 202
|
||||
202
|
||||
</universes>
|
||||
</hex_lattice>
|
||||
52
docs/source/io_formats/index.rst
Normal file
52
docs/source/io_formats/index.rst
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
.. _io_file_formats:
|
||||
|
||||
==========================
|
||||
File Format Specifications
|
||||
==========================
|
||||
|
||||
.. _io_file_formats_input:
|
||||
|
||||
-----------
|
||||
Input Files
|
||||
-----------
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 1
|
||||
|
||||
geometry
|
||||
materials
|
||||
settings
|
||||
tallies
|
||||
plots
|
||||
|
||||
----------
|
||||
Data Files
|
||||
----------
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 1
|
||||
|
||||
cross_sections
|
||||
depletion_chain
|
||||
nuclear_data
|
||||
mgxs_library
|
||||
data_wmp
|
||||
|
||||
------------
|
||||
Output Files
|
||||
------------
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 1
|
||||
|
||||
statepoint
|
||||
source
|
||||
summary
|
||||
depletion_results
|
||||
particle_restart
|
||||
track
|
||||
voxel
|
||||
volume
|
||||
126
docs/source/io_formats/materials.rst
Normal file
126
docs/source/io_formats/materials.rst
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
.. _io_materials:
|
||||
|
||||
========================================
|
||||
Materials Specification -- materials.xml
|
||||
========================================
|
||||
|
||||
.. _cross_sections:
|
||||
|
||||
----------------------------
|
||||
``<cross_sections>`` Element
|
||||
----------------------------
|
||||
|
||||
The ``<cross_sections>`` element has no attributes and simply indicates the path
|
||||
to an XML cross section listing file (usually named cross_sections.xml). If this
|
||||
element is absent from the settings.xml file, the
|
||||
:envvar:`OPENMC_CROSS_SECTIONS` environment variable will be used to find the
|
||||
path to the XML cross section listing when in continuous-energy mode, and the
|
||||
:envvar:`OPENMC_MG_CROSS_SECTIONS` environment variable will be used in
|
||||
multi-group mode.
|
||||
|
||||
.. _material:
|
||||
|
||||
----------------------
|
||||
``<material>`` Element
|
||||
----------------------
|
||||
|
||||
Each ``material`` element can have the following attributes or sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the material.
|
||||
|
||||
:name:
|
||||
An optional string name to identify the material in summary output
|
||||
files. This string is limited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:depletable:
|
||||
Boolean value indicating whether the material is depletable.
|
||||
|
||||
:volume:
|
||||
Volume of the material in cm^3.
|
||||
|
||||
:temperature:
|
||||
Temperature of the material in Kelvin.
|
||||
|
||||
*Default*: If a material default temperature is not given and a cell
|
||||
temperature is not specified, the :ref:`global default temperature
|
||||
<temperature_default>` is used.
|
||||
|
||||
:density:
|
||||
An element with attributes/sub-elements called ``value`` and ``units``. The
|
||||
``value`` attribute is the numeric value of the density while the ``units``
|
||||
can be "g/cm3", "kg/m3", "atom/b-cm", "atom/cm3", or "sum". The "sum" unit
|
||||
indicates that values appearing in ``ao`` or ``wo`` attributes for ``<nuclide>``
|
||||
and ``<element>`` sub-elements are to be interpreted as absolute nuclide/element
|
||||
densities in atom/b-cm or g/cm3, and the total density of the material is
|
||||
taken as the sum of all nuclides/elements. The "macro" unit is used with
|
||||
a ``macroscopic`` quantity to indicate that the density is already included
|
||||
in the library and thus not needed here. However, if a value is provided
|
||||
for the ``value``, then this is treated as a number density multiplier on
|
||||
the macroscopic cross sections in the multi-group data. This can be used,
|
||||
for example, when perturbing the density slightly.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. note:: A ``macroscopic`` quantity can not be used in conjunction with a
|
||||
``nuclide``, ``element``, or ``sab`` quantity.
|
||||
|
||||
:nuclide:
|
||||
An element with attributes/sub-elements called ``name``, and ``ao``
|
||||
or ``wo``. The ``name`` attribute is the name of the cross-section for a
|
||||
desired nuclide. Finally, the ``ao`` and ``wo`` attributes specify the atom or
|
||||
weight percent of that nuclide within the material, respectively. One
|
||||
example would be as follows:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<nuclide name="H1" ao="2.0" />
|
||||
<nuclide name="O16" ao="1.0" />
|
||||
|
||||
.. note:: If one nuclide is specified in atom percent, all others must also
|
||||
be given in atom percent. The same applies for weight percentages.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:sab:
|
||||
Associates an S(a,b) table with the material. This element has an
|
||||
attribute/sub-element called ``name``. The ``name`` attribute
|
||||
is the name of the S(a,b) table that should be associated with the material.
|
||||
There is also an optional ``fraction`` element which indicates what fraction
|
||||
of the relevant nuclides will be affected by the S(a,b) table (e.g. which
|
||||
fraction of a material is crystalline versus amorphous). ``fraction``
|
||||
defaults to unity.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. note:: This element is not used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
:isotropic:
|
||||
The ``isotropic`` element indicates a list of nuclides for which elastic
|
||||
scattering should be treated as though it were isotropic in the laboratory
|
||||
system. This element may be most useful when using OpenMC to compute
|
||||
multi-group cross-sections for deterministic transport codes and to quantify
|
||||
the effects of anisotropic scattering.
|
||||
|
||||
*Default*: No nuclides are treated as have isotropic elastic scattering.
|
||||
|
||||
.. note:: This element is not used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
:macroscopic:
|
||||
The ``macroscopic`` element is similar to the ``nuclide`` element, but,
|
||||
recognizes that some multi-group libraries may be providing material
|
||||
specific macroscopic cross sections instead of always providing nuclide
|
||||
specific data like in the continuous-energy case. To that end, the
|
||||
macroscopic element has one attribute/sub-element called ``name``.
|
||||
The ``name`` attribute is the name of the cross-section for a
|
||||
desired nuclide. One example would be as follows:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<macroscopic name="UO2" />
|
||||
|
||||
.. note:: This element is only used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
*Default*: None
|
||||
175
docs/source/io_formats/mgxs_library.rst
Normal file
175
docs/source/io_formats/mgxs_library.rst
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
.. _io_mgxs_library:
|
||||
|
||||
========================================
|
||||
Multi-Group Cross Section Library Format
|
||||
========================================
|
||||
|
||||
OpenMC can be run in continuous-energy mode or multi-group mode, provided the
|
||||
nuclear data is available. In continuous-energy mode, the
|
||||
``cross_sections.xml`` file contains necessary meta-data for each dataset,
|
||||
including the name and a file system location where the complete library
|
||||
can be found. In multi-group mode, the multi-group meta-data and the
|
||||
nuclear data itself is contained within an ``mgxs.h5`` file. This portion of
|
||||
the manual describes the format of the multi-group data library required
|
||||
to be used in the ``mgxs.h5`` file.
|
||||
|
||||
The multi-group library is provided in the HDF5_ format. This library must
|
||||
provide some meta-data about the library itself (such as the number of
|
||||
energy groups, delayed groups, and the energy group structure, etc.) as
|
||||
well as the actual cross section data itself for each of the necessary
|
||||
nuclides or materials.
|
||||
|
||||
The current version of the multi-group library file format is 1.0.
|
||||
|
||||
.. _HDF5: http://www.hdfgroup.org/HDF5/
|
||||
|
||||
.. _mgxs_lib_spec:
|
||||
|
||||
--------------------------
|
||||
MGXS Library Specification
|
||||
--------------------------
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file;
|
||||
for this library it will be 'mgxs'.
|
||||
- **version** (*int[2]*) -- Major and minor version of the
|
||||
multi-group library file format.
|
||||
- **energy_groups** (*int*) -- Number of energy groups
|
||||
- **delayed_groups** (*int*) -- Number of delayed groups (optional)
|
||||
- **group structure** (*double[]*) -- Monotonically increasing
|
||||
list of group boundaries, in units of eV. The length of this
|
||||
array should be the number of groups plus 1.
|
||||
|
||||
**/<library name>/**
|
||||
|
||||
The data within <library name> contains the temperature-dependent multi-group
|
||||
data for the nuclide or material that it represents.
|
||||
|
||||
:Attributes: - **atomic_weight_ratio** (*double*) -- The atomic weight ratio
|
||||
(optional, i.e. it is not meaningful for material-wise data).
|
||||
- **fissionable** (*bool*) -- Whether the dataset is fissionable
|
||||
(True) or not (False).
|
||||
- **representation** (*char[]*) -- The method used to generate and
|
||||
represent the multi-group cross sections. That is, whether they
|
||||
were generated with scalar flux weighting (or reduced to a
|
||||
similar representation) and thus are angle-independent, or if the
|
||||
data was generated with angular dependent fluxes and thus the
|
||||
data is angle-dependent. Valid values are either "isotropic" or
|
||||
"angle".
|
||||
- **num_azimuthal** (*int*) -- Number of equal width angular bins
|
||||
that the azimuthal angular domain is subdivided if the
|
||||
`representation` attribute is "angle". This parameter is
|
||||
ignored otherwise.
|
||||
- **num_polar** (*int*) -- Number of equal width angular bins
|
||||
that the polar angular domain is subdivided if the
|
||||
`representation` attribute is "angle". This parameter is
|
||||
ignored otherwise.
|
||||
- **scatter_format** (*char[]*) -- The representation of the
|
||||
scattering angular distribution. The options are either
|
||||
"legendre", "histogram", or "tabular". If not provided, the
|
||||
default of "legendre" will be assumed.
|
||||
- **order** (*int*) -- Either the Legendre order, number of bins,
|
||||
or number of points (depending on the value of `scatter_format`)
|
||||
used to describe the angular distribution associated with each
|
||||
group-to-group transfer probability.
|
||||
- **scatter_shape** (*char[]*) -- The shape of the provided
|
||||
scatter and multiplicity matrix. The values provided are strings
|
||||
describing the ordering the scattering array is provided in
|
||||
row-major (i.e., C/C++ and Python) indexing. Valid values are
|
||||
"[Order][G][G']" or "[Order][G'][G]" where "G'" denotes the
|
||||
secondary/outgoing energy groups, "G" denotes the incoming
|
||||
energy groups, and "Order" is the angular distribution index.
|
||||
This value is not required; if not the default value of
|
||||
"[Order][G][G']" will be assumed.
|
||||
|
||||
**/<library name>/kTs/**
|
||||
|
||||
:Datasets:
|
||||
- **<TTT>K** (*double*) -- kT values (in eV) for each temperature
|
||||
TTT (in Kelvin), rounded to the nearest integer
|
||||
|
||||
**/<library name>/<TTT>K/**
|
||||
|
||||
Temperature-dependent data, provided for temperature <TTT>K.
|
||||
|
||||
:Datasets: - **total** (*double[]* or *double[][][]*) -- Total cross section.
|
||||
This is a 1-D vector if `representation` is "isotropic", or a 3-D
|
||||
vector if `representation` is "angle" with dimensions of
|
||||
[polar][azimuthal][groups].
|
||||
- **absorption** (*double[]* or *double[][][]*) -- Absorption
|
||||
cross section.
|
||||
This is a 1-D vector if `representation` is "isotropic", or a 3-D
|
||||
vector if `representation` is "angle" with dimensions of
|
||||
[groups][azimuthal][polar].
|
||||
- **fission** (*double[]* or *double[][][]*) -- Fission
|
||||
cross section.
|
||||
This is a 1-D vector if `representation` is "isotropic", or a 3-D
|
||||
vector if `representation` is "angle" with dimensions of
|
||||
[polar][azimuthal][groups]. This is only required if the dataset
|
||||
is fissionable and fission-tallies are expected to be used.
|
||||
- **kappa-fission** (*double[]* or *double[][][]*) -- Kappa-Fission
|
||||
(energy-release from fission) cross section.
|
||||
This is a 1-D vector if `representation` is "isotropic", or a 3-D
|
||||
vector if `representation` is "angle" with dimensions of
|
||||
[polar][azimuthal][groups]. This is only required if the dataset
|
||||
is fissionable and fission-tallies are expected to be used.
|
||||
- **chi** (*double[]* or *double[][][]*) -- Fission neutron energy
|
||||
spectra.
|
||||
This is a 1-D vector if `representation` is "isotropic", or a 3-D
|
||||
vector if `representation` is "angle" with dimensions of
|
||||
[polar][azimuthal][groups]. This is only required if the dataset
|
||||
is fissionable and fission-tallies are expected to be used.
|
||||
- **nu-fission** (*double[]* to *double[][][][]*) -- Nu-Fission
|
||||
cross section.
|
||||
If **chi** is provided, then `nu-fission` has the same
|
||||
dimensionality as `fission`. If **chi** is not provided, then
|
||||
the `nu-fission` data must represent the fission neutron energy
|
||||
spectra as well and thus will have one additional dimension
|
||||
for the outgoing energy group. In this case, `nu-fission` has the
|
||||
same dimensionality as `multiplicity matrix`.
|
||||
- **inverse-velocity** (*double[]* or *double[][][]*) --
|
||||
Average inverse velocity for each of the groups in the library.
|
||||
This dataset is optional. This is a 1-D vector if `representation`
|
||||
is "isotropic", or a 3-D vector if `representation` is "angle"
|
||||
with dimensions of [polar][azimuthal][groups].
|
||||
|
||||
**/<library name>/<TTT>K/scatter_data/**
|
||||
|
||||
Data specific to neutron scattering for the temperature <TTT>K
|
||||
|
||||
:Datasets: - **g_min** (*int[]* or *int[][][]*) --
|
||||
Minimum (most energetic) groups with non-zero values of
|
||||
the scattering matrix provided. If `scatter_shape` is
|
||||
"[Order][G][G']" then `g_min` will describe the minimum values
|
||||
of "G'" for each "G"; if `scatter_shape` is "[Order][G'][G]"
|
||||
then `g_min` will describe the minimum values of "G" for each "G'".
|
||||
These group numbers use the standard
|
||||
ordering where the fastest neutron energy group is group 1 while
|
||||
the slowest neutron energy group is group G.
|
||||
The dimensionality of `g_min` is:
|
||||
`g_min[g]`, or `g_min[num_polar][num_azimuthal][g]`.
|
||||
The former is used when `representation` is "isotropic", and the
|
||||
latter when `representation` is "angle".
|
||||
- **g_max** (*int[]* or *int[][][]*) --
|
||||
Similar to `g_min`, except this dataset describes the maximum
|
||||
(least energetic) groups with non-zero values of
|
||||
the scattering matrix.
|
||||
- **scatter_matrix** (*double[]*) -- Flattened representation of the
|
||||
scattering moment matrices. The pre-flattened array corresponds to
|
||||
the shape provied in `scatter_shape`, but if `representation` is
|
||||
"angle" the dimensionality in `scatter_shape` is prepended by
|
||||
"[num_polar][num_azimuthal]" dimensions. The right-most energy
|
||||
group dimension will only include the entries between `g_min` and
|
||||
`g_max`.
|
||||
dimension has a dimensionality of `g_min` to `g_max`.
|
||||
- **multiplicity_matrix** (*double[]*) -- Flattened representation of
|
||||
the scattering moment matrices. This dataset provides the code with
|
||||
a scaling factor to account for neutrons being produced in (n,xn)
|
||||
reactions. This is assumed isotropic and therefore is not repeated
|
||||
for every Legendre moment or histogram/tabular bin. This dataset is
|
||||
optional, if it is not provided no multiplication (i.e., values of
|
||||
1.0) will be assumed.
|
||||
The pre-flattened array is shapes consistent with `scatter_matrix`
|
||||
except the "[Order]" dimension in `scatter_shape` is ignored since
|
||||
this data is assumed isotropic.
|
||||
592
docs/source/io_formats/nuclear_data.rst
Normal file
592
docs/source/io_formats/nuclear_data.rst
Normal file
|
|
@ -0,0 +1,592 @@
|
|||
.. _io_nuclear_data:
|
||||
|
||||
=========================
|
||||
Nuclear Data File Formats
|
||||
=========================
|
||||
|
||||
---------------------
|
||||
Incident Neutron Data
|
||||
---------------------
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file
|
||||
- **version** (*int[2]*) -- Major and minor version of the data
|
||||
|
||||
**/<nuclide name>/**
|
||||
|
||||
:Attributes: - **Z** (*int*) -- Atomic number
|
||||
- **A** (*int*) -- Mass number. For a natural element, A=0 is given.
|
||||
- **metastable** (*int*) -- Metastable state (0=ground, 1=first
|
||||
excited, etc.)
|
||||
- **atomic_weight_ratio** (*double*) -- Mass in units of neutron masses
|
||||
- **n_reaction** (*int*) -- Number of reactions
|
||||
|
||||
:Datasets:
|
||||
- **energy** (*double[]*) -- Energies in [eV] at which cross sections
|
||||
are tabulated
|
||||
|
||||
**/<nuclide name>/kTs/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Datasets:
|
||||
- **<TTT>K** (*double*) -- kT values in [eV] for each temperature
|
||||
TTT (in Kelvin)
|
||||
|
||||
**/<nuclide name>/reactions/reaction_<mt>/**
|
||||
|
||||
:Attributes: - **mt** (*int*) -- ENDF MT reaction number
|
||||
- **label** (*char[]*) -- Name of the reaction
|
||||
- **Q_value** (*double*) -- Q value in eV
|
||||
- **center_of_mass** (*int*) -- Whether the reference frame for
|
||||
scattering is center-of-mass (1) or laboratory (0)
|
||||
- **n_product** (*int*) -- Number of reaction products
|
||||
- **redundant** (*int*) -- Whether reaction is redundant
|
||||
|
||||
**/<nuclide name>/reactions/reaction_<mt>/<TTT>K/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Datasets:
|
||||
- **xs** (*double[]*) -- Cross section values tabulated against the
|
||||
nuclide energy grid for temperature TTT (in Kelvin)
|
||||
|
||||
:Attributes:
|
||||
- **threshold_idx** (*int*) -- Index on the energy
|
||||
grid that the reaction threshold corresponds to for
|
||||
temperature TTT (in Kelvin)
|
||||
|
||||
**/<nuclide name>/reactions/reaction_<mt>/product_<j>/**
|
||||
|
||||
Reaction product data is described in :ref:`product`.
|
||||
|
||||
**/<nuclide name>/urr/<TTT>K/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Attributes: - **interpolation** (*int*) -- interpolation scheme
|
||||
- **inelastic** (*int*) -- flag indicating inelastic scattering
|
||||
- **other_absorb** (*int*) -- flag indicating other absorption
|
||||
- **factors** (*int*) -- flag indicating whether tables are
|
||||
absolute or multipliers
|
||||
|
||||
:Datasets: - **energy** (*double[]*) -- Energy at which probability tables exist
|
||||
- **table** (*double[][][]*) -- Probability tables
|
||||
|
||||
**/<nuclide name>/total_nu/**
|
||||
|
||||
This special product is used to define the total number of neutrons produced
|
||||
from fission. It is formatted as a reaction product, described in
|
||||
:ref:`product`.
|
||||
|
||||
**/<nuclide name>/fission_energy_release/**
|
||||
|
||||
:Datasets: - **fragments** (:ref:`function <1d_functions>`) -- Energy
|
||||
released in the form of fragments as a function of incident
|
||||
neutron energy.
|
||||
- **prompt_neutrons** (:ref:`function <1d_functions>`) -- Energy
|
||||
released in the form of prompt neutrons as a function of incident
|
||||
neutron energy.
|
||||
- **delayed_neutrons** (:ref:`function <1d_functions>`) -- Energy
|
||||
released in the form of delayed neutrons as a function of incident
|
||||
neutron energy.
|
||||
- **prompt_photons** (:ref:`function <1d_functions>`) -- Energy
|
||||
released in the form of prompt photons as a function of incident
|
||||
neutron energy.
|
||||
- **delayed_photons** (:ref:`function <1d_functions>`) -- Energy
|
||||
released in the form of delayed photons as a function of incident
|
||||
neutron energy.
|
||||
- **betas** (:ref:`function <1d_functions>`) -- Energy released in
|
||||
the form of betas as a function of incident neutron energy.
|
||||
- **neutrinos** (:ref:`function <1d_functions>`) -- Energy released
|
||||
in the form of neutrinos as a function of incident neutron energy.
|
||||
- **q_prompt** (:ref:`function <1d_functions>`) -- The prompt fission
|
||||
Q-value (fragments + prompt neutrons + prompt photons - incident
|
||||
energy)
|
||||
- **q_recoverable** (:ref:`function <1d_functions>`) -- The
|
||||
recoverable fission Q-value (Q_prompt + delayed neutrons + delayed
|
||||
photons + betas)
|
||||
|
||||
--------------------
|
||||
Incident Photon Data
|
||||
--------------------
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file
|
||||
- **version** (*int[2]*) -- Major and minor version of the data
|
||||
|
||||
**/<element>/**
|
||||
|
||||
:Attributes: - **Z** (*int*) -- Atomic number
|
||||
|
||||
:Datasets:
|
||||
- **energy** (*double[]*) -- Energies in [eV] at which cross sections
|
||||
are tabulated
|
||||
|
||||
**/<element>/bremsstrahlung/**
|
||||
|
||||
:Attributes: - **I** (*double*) -- Mean excitation energy in [eV]
|
||||
|
||||
:Datasets: - **electron_energy** (*double[]*) -- Incident electron energy in [eV]
|
||||
- **photon_energy** (*double[]*) -- Outgoing photon energy as
|
||||
fraction of incident electron energy
|
||||
- **dcs** (*double[][]*) -- Bremsstrahlung differential cross section
|
||||
at each incident energy in [mb/eV]
|
||||
- **ionization_energy** (*double[]*) -- Ionization potential of each
|
||||
subshell in [eV]
|
||||
- **num_electrons** (*int[]*) -- Number of electrons per subshell,
|
||||
with conduction electrons indicated by a negative value
|
||||
|
||||
**/<element>/coherent/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Coherent scattering cross section in [b]
|
||||
- **integrated_scattering_factor** (:ref:`tabulated <1d_tabulated>`)
|
||||
-- Integrated coherent scattering form factor
|
||||
- **anomalous_real** (:ref:`tabulated <1d_tabulated>`) -- Real part
|
||||
of the anomalous scattering factor
|
||||
- **anomalous_imag** (:ref:`tabulated <1d_tabulated>`) -- Imaginary
|
||||
part of the anomalous scattering factor
|
||||
|
||||
**/<element>/compton_profiles/**
|
||||
|
||||
:Datasets: - **binding_energy** (*double[]*) -- Binding energy for each subshell in [eV]
|
||||
- **num_electrons** (*double[]*) -- Number of electrons in each subshell
|
||||
- **pz** (*double[]*) -- Projection of the electron momentum on the
|
||||
scattering vector in units of :math:`me^2 / \hbar` where :math:`m`
|
||||
is the electron rest mass and :math:`e` is the electron charge
|
||||
- **J** (*double[][]*) -- Compton profile for each subshell in units
|
||||
of :math:`\hbar / (me^2)`
|
||||
|
||||
**/<element>/heating/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Total heating cross section in [b-eV]
|
||||
|
||||
**/<element>/incoherent/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Incoherent scattering cross section in [b]
|
||||
- **scattering_factor** (:ref:`tabulated <1d_tabulated>`) --
|
||||
|
||||
**/<element>/pair_production_electron/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Pair production (electron field) cross section in [b]
|
||||
|
||||
**/<element>/pair_production_nuclear/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Pair production (nuclear field) cross section in [b]
|
||||
|
||||
**/<element>/photoelectric/**
|
||||
|
||||
:Datasets: - **xs** (*double[]*) -- Total photoionization cross section in [b]
|
||||
|
||||
**/<element>/subshells/**
|
||||
|
||||
:Attributes: - **designators** (*char[][]*) -- Designator for each shell, e.g. 'M2'
|
||||
|
||||
**/<element>/subshells/<designator>/**
|
||||
|
||||
:Attributes: - **binding_energy** (*double*) -- Binding energy of the subshell in [eV]
|
||||
- **num_electrons** (*double*) -- Number of electrons in the subshell
|
||||
|
||||
:Datasets: - **transitions** (*double[][]*) -- Atomic relaxation data
|
||||
- **xs** (*double[]*) -- Photoionization cross section for subshell
|
||||
in [b] tabulated against the main energy grid
|
||||
|
||||
:Attributes:
|
||||
- **threshold_idx** (*int*) -- Index on the energy
|
||||
grid of the reaction threshold
|
||||
|
||||
-------------------------------
|
||||
Thermal Neutron Scattering Data
|
||||
-------------------------------
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes:
|
||||
- **version** (*int[2]*) -- Major and minor version of the data
|
||||
|
||||
**/<thermal name>/**
|
||||
|
||||
:Attributes: - **atomic_weight_ratio** (*double*) -- Mass in units of neutron masses
|
||||
- **energy_max** (*double*) -- Maximum energy in [eV]
|
||||
- **nuclides** (*char[][]*) -- Names of nuclides for which the
|
||||
thermal scattering data applies to
|
||||
|
||||
**/<thermal name>/kTs/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Datasets:
|
||||
- **<TTT>K** (*double*) -- kT values (in eV) for each temperature
|
||||
TTT (in Kelvin)
|
||||
|
||||
**/<thermal name>/elastic/<TTT>K/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Datasets:
|
||||
- **xs** (:ref:`function <1d_functions>`) -- Thermal elastic
|
||||
scattering cross section for temperature TTT (in Kelvin)
|
||||
|
||||
:Groups:
|
||||
- **distribution** -- Format for angle-energy distributions are
|
||||
detailed in :ref:`angle_energy`.
|
||||
|
||||
**/<thermal name>/inelastic/<TTT>K/**
|
||||
|
||||
<TTT>K is the temperature in Kelvin, rounded to the nearest integer, of the
|
||||
temperature-dependent data set. For example, the data set corresponding to
|
||||
300 Kelvin would be located at `300K`.
|
||||
|
||||
:Datasets:
|
||||
- **xs** (:ref:`function <1d_functions>`) -- Thermal inelastic
|
||||
scattering cross section for temperature TTT (in Kelvin)
|
||||
|
||||
:Groups:
|
||||
- **distribution** -- Format for angle-energy distributions are
|
||||
detailed in :ref:`angle_energy`.
|
||||
|
||||
.. _product:
|
||||
|
||||
-----------------
|
||||
Reaction Products
|
||||
-----------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **particle** (*char[]*) -- Type of particle
|
||||
- **emission_mode** (*char[]*) -- Emission mode (prompt, delayed,
|
||||
total)
|
||||
- **decay_rate** (*double*) -- Rate of decay in inverse seconds
|
||||
- **n_distribution** (*int*) -- Number of angle/energy
|
||||
distributions
|
||||
:Datasets:
|
||||
- **yield** (:ref:`function <1d_functions>`) -- Energy-dependent
|
||||
yield of the product.
|
||||
|
||||
:Groups:
|
||||
- **distribution_<k>** -- Formats for angle-energy distributions are
|
||||
detailed in :ref:`angle_energy`. When multiple angle-energy
|
||||
distributions occur, one dataset also may appear for each
|
||||
distribution:
|
||||
|
||||
:Datasets:
|
||||
- **applicability** (:ref:`function <1d_functions>`) --
|
||||
Probability of selecting this distribution as a function
|
||||
of incident energy
|
||||
|
||||
.. _1d_functions:
|
||||
|
||||
-------------------------
|
||||
One-dimensional Functions
|
||||
-------------------------
|
||||
|
||||
Scalar
|
||||
------
|
||||
|
||||
:Object type: Dataset
|
||||
:Datatype: *double*
|
||||
:Attributes: - **type** (*char[]*) -- 'constant'
|
||||
|
||||
.. _1d_tabulated:
|
||||
|
||||
Tabulated
|
||||
---------
|
||||
|
||||
:Object type: Dataset
|
||||
:Datatype: *double[2][]*
|
||||
:Description: x-values are listed first followed by corresponding y-values
|
||||
:Attributes: - **type** (*char[]*) -- 'Tabulated1D'
|
||||
- **breakpoints** (*int[]*) -- Region breakpoints
|
||||
- **interpolation** (*int[]*) -- Region interpolation codes
|
||||
|
||||
.. _1d_polynomial:
|
||||
|
||||
Polynomial
|
||||
----------
|
||||
|
||||
:Object type: Dataset
|
||||
:Datatype: *double[]*
|
||||
:Description: Polynomial coefficients listed in order of increasing power
|
||||
:Attributes: - **type** (*char[]*) -- 'Polynomial'
|
||||
|
||||
Coherent elastic scattering
|
||||
---------------------------
|
||||
|
||||
:Object type: Dataset
|
||||
:Datatype: *double[2][]*
|
||||
:Description: The first row lists Bragg edges and the second row lists structure
|
||||
factor cumulative sums.
|
||||
:Attributes: - **type** (*char[]*) -- 'CoherentElastic'
|
||||
|
||||
Incoherent elastic scattering
|
||||
-----------------------------
|
||||
|
||||
:Object type: Dataset
|
||||
:Datatype: *double[2]*
|
||||
:Description: The first value is the characteristic bound cross section in [b]
|
||||
and the second value is the Debye-Waller integral in
|
||||
[eV\ :math:`^{-1}`].
|
||||
:Attributes: - **type** (*char[]*) -- 'IncoherentElastic'
|
||||
|
||||
.. _angle_energy:
|
||||
|
||||
--------------------------
|
||||
Angle-Energy Distributions
|
||||
--------------------------
|
||||
|
||||
Uncorrelated Angle-Energy
|
||||
-------------------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'uncorrelated'
|
||||
:Datasets: - **angle/energy** (*double[]*) -- energies at which angle distributions exist
|
||||
- **angle/mu** (*double[3][]*) -- tabulated angular distributions for
|
||||
each energy. The first row gives :math:`\mu` values, the second row
|
||||
gives the probability density, and the third row gives the
|
||||
cumulative distribution.
|
||||
|
||||
:Attributes: - **offsets** (*int[]*) -- indices indicating where
|
||||
each angular distribution starts
|
||||
- **interpolation** (*int[]*) -- interpolation code
|
||||
for each angular distribution
|
||||
|
||||
:Groups: - **energy/** (:ref:`energy distribution <energy_distribution>`)
|
||||
|
||||
.. _correlated_angle_energy:
|
||||
|
||||
Correlated Angle-Energy
|
||||
-----------------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'correlated'
|
||||
:Datasets: - **energy** (*double[]*) -- Incoming energies at which distributions exist
|
||||
|
||||
:Attributes:
|
||||
- **interpolation** (*double[2][]*) -- Breakpoints and
|
||||
interpolation codes for incoming energy regions
|
||||
|
||||
- **energy_out** (*double[5][]*) -- Distribution of outgoing energies
|
||||
corresponding to each incoming energy. The distributions are
|
||||
flattened into a single array; the start of a given distribution
|
||||
can be determined using the ``offsets`` attribute. The first row
|
||||
gives outgoing energies, the second row gives the probability
|
||||
density, the third row gives the cumulative distribution, the
|
||||
fourth row gives interpolation codes for angular distributions, and
|
||||
the fifth row gives offsets for angular distributions.
|
||||
|
||||
:Attributes: - **offsets** (*double[]*) -- Offset for each
|
||||
distribution
|
||||
- **interpolation** (*int[]*) -- Interpolation code
|
||||
for each distribution
|
||||
- **n_discrete_lines** (*int[]*) -- Number of discrete
|
||||
lines in each distribution
|
||||
|
||||
- **mu** (*double[3][]*) -- Distribution of angular cosines
|
||||
corresponding to each pair of incoming and outgoing energies. The
|
||||
distributions are flattened into a single array; the start of a
|
||||
given distribution can be determined using offsets in the fifth row
|
||||
of the ``energy_out`` dataset. The first row gives angular cosines,
|
||||
the second row gives the probability density, and the third row
|
||||
gives the cumulative distribution.
|
||||
|
||||
Kalbach-Mann
|
||||
------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'kalbach-mann'
|
||||
:Datasets: - **energy** (*double[]*) -- Incoming energies at which distributions exist
|
||||
|
||||
:Attributes:
|
||||
- **interpolation** (*double[2][]*) -- Breakpoints and
|
||||
interpolation codes for incoming energy regions
|
||||
|
||||
- **distribution** (*double[5][]*) -- Distribution of outgoing
|
||||
energies and angles corresponding to each incoming energy. The
|
||||
distributions are flattened into a single array; the start of a
|
||||
given distribution can be determined using the ``offsets``
|
||||
attribute. The first row gives outgoing energies, the second row
|
||||
gives the probability density, the third row gives the cumulative
|
||||
distribution, the fourth row gives Kalbach-Mann precompound
|
||||
factors, and the fifth row gives Kalbach-Mann angular distribution
|
||||
slopes.
|
||||
|
||||
:Attributes: - **offsets** (*double[]*) -- Offset for each
|
||||
distribution
|
||||
- **interpolation** (*int[]*) -- Interpolation code
|
||||
for each distribution
|
||||
- **n_discrete_lines** (*int[]*) -- Number of discrete
|
||||
lines in each distribution
|
||||
|
||||
N-Body Phase Space
|
||||
------------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'nbody'
|
||||
- **total_mass** (*double*) -- Total mass of product particles
|
||||
- **n_particles** (*int*) -- Number of product particles
|
||||
- **atomic_weight_ratio** (*double*) -- Atomic weight ratio of the
|
||||
target nuclide in neutron masses
|
||||
- **q_value** (*double*) -- Q value for the reaction in eV
|
||||
|
||||
Coherent Elastic
|
||||
----------------
|
||||
|
||||
This angle-energy distribution is used specifically for coherent elastic thermal
|
||||
neutron scattering.
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- "coherent_elastic"
|
||||
:Hard link: - **xs** -- Link to the coherent elastic scattering cross section
|
||||
|
||||
Incoherent Elastic
|
||||
------------------
|
||||
|
||||
This angle-energy distribution is used specifically for incoherent elastic
|
||||
thermal neutron scattering (derived from an ENDF file directly).
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- "incoherent_elastic"
|
||||
:Datasets:
|
||||
- **debye_waller** (*double*) -- Debye-Waller integral in
|
||||
[eV\ :math:`^{-1}`]
|
||||
|
||||
Incoherent Elastic (Discrete)
|
||||
-----------------------------
|
||||
|
||||
This angle-energy distribution is used for discretized incoherent elastic
|
||||
thermal neutron scattering distributions that are present in ACE files.
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- "incoherent_elastic_discrete"
|
||||
:Datasets:
|
||||
- **mu_out** (*double[][]*) -- Equiprobable discrete outgoing
|
||||
angles for each incident neutron energy tabulated
|
||||
|
||||
Incoherent Inelastic
|
||||
--------------------
|
||||
|
||||
This angle-energy distribution is used specifically for (continuous) incoherent
|
||||
inelastic thermal neutron scattering.
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- "incoherent_inelastic"
|
||||
:Datasets: The datasets for this angle-energy distribution are the same as for
|
||||
:ref:`correlated angle-energy distributions
|
||||
<correlated_angle_energy>`.
|
||||
|
||||
Incoherent Inelastic (Discrete)
|
||||
-------------------------------
|
||||
|
||||
This angle-energy distribution is used specifically for incoherent inelastic
|
||||
thermal neutron scattering where the distributions have been discretized into
|
||||
equiprobable bins.
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- "incoherent_inelastic_discrete"
|
||||
:Datasets: - **energy_out** (*double[][]*) -- Distribution of outgoing
|
||||
energies for each incoming energy.
|
||||
- **mu_out** (*double[][][]*) -- Distribution of scattering cosines
|
||||
for each pair of incoming and outgoing energies.
|
||||
- **skewed** (*int8_t*) -- Whether discrete angles are equi-probable
|
||||
(0) or have a skewed distribution (1).
|
||||
|
||||
.. _energy_distribution:
|
||||
|
||||
--------------------
|
||||
Energy Distributions
|
||||
--------------------
|
||||
|
||||
Maxwell
|
||||
-------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'maxwell'
|
||||
- **u** (*double*) -- Restriction energy in eV
|
||||
:Datasets:
|
||||
- **theta** (:ref:`tabulated <1d_tabulated>`) -- Maxwellian
|
||||
temperature as a function of energy
|
||||
|
||||
Evaporation
|
||||
-----------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'evaporation'
|
||||
- **u** (*double*) -- Restriction energy in eV
|
||||
:Datasets:
|
||||
- **theta** (:ref:`tabulated <1d_tabulated>`) -- Evaporation
|
||||
temperature as a function of energy
|
||||
|
||||
Watt Fission Spectrum
|
||||
---------------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'watt'
|
||||
- **u** (*double*) -- Restriction energy in eV
|
||||
:Datasets: - **a** (:ref:`tabulated <1d_tabulated>`) -- Watt parameter :math:`a`
|
||||
as a function of incident energy
|
||||
- **b** (:ref:`tabulated <1d_tabulated>`) -- Watt parameter :math:`b`
|
||||
as a function of incident energy
|
||||
|
||||
Madland-Nix
|
||||
-----------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'watt'
|
||||
- **efl** (*double*) -- Average energy of light fragment in eV
|
||||
- **efh** (*double*) -- Average energy of heavy fragment in eV
|
||||
|
||||
Discrete Photon
|
||||
---------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'discrete_photon'
|
||||
- **primary_flag** (*int*) -- Whether photon is a primary
|
||||
- **energy** (*double*) -- Photon energy in eV
|
||||
- **atomic_weight_ratio** (*double*) -- Atomic weight ratio of
|
||||
target nuclide in neutron masses
|
||||
|
||||
Level Inelastic
|
||||
---------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'level'
|
||||
- **threshold** (*double*) -- Energy threshold in the laboratory
|
||||
system in eV
|
||||
- **mass_ratio** (*double*) -- :math:`(A/(A + 1))^2`
|
||||
|
||||
Continuous Tabular
|
||||
------------------
|
||||
|
||||
:Object type: Group
|
||||
:Attributes: - **type** (*char[]*) -- 'continuous'
|
||||
:Datasets: - **energy** (*double[]*) -- Incoming energies at which distributions exist
|
||||
|
||||
:Attributes:
|
||||
- **interpolation** (*double[2][]*) -- Breakpoints and
|
||||
interpolation codes for incoming energy regions
|
||||
|
||||
- **distribution** (*double[3][]*) -- Distribution of outgoing
|
||||
energies corresponding to each incoming energy. The distributions
|
||||
are flattened into a single array; the start of a given
|
||||
distribution can be determined using the ``offsets`` attribute. The
|
||||
first row gives outgoing energies, the second row gives the
|
||||
probability density, and the third row gives the cumulative
|
||||
distribution.
|
||||
|
||||
:Attributes: - **offsets** (*double[]*) -- Offset for each
|
||||
distribution
|
||||
- **interpolation** (*int[]*) -- Interpolation code
|
||||
for each distribution
|
||||
- **n_discrete_lines** (*int[]*) -- Number of discrete
|
||||
lines in each distribution
|
||||
34
docs/source/io_formats/particle_restart.rst
Normal file
34
docs/source/io_formats/particle_restart.rst
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
.. _io_particle_restart:
|
||||
|
||||
============================
|
||||
Particle Restart File Format
|
||||
============================
|
||||
|
||||
The current version of the particle restart file format is 2.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the particle
|
||||
restart file format.
|
||||
- **openmc_version** (*int[3]*) -- Major, minor, and release
|
||||
version number for OpenMC.
|
||||
- **git_sha1** (*char[40]*) -- Git commit SHA-1 hash.
|
||||
|
||||
:Datasets: - **current_batch** (*int*) -- The number of batches already
|
||||
simulated.
|
||||
- **generations_per_batch** (*int*) -- Number of generations per
|
||||
batch.
|
||||
- **current_generation** (*int*) -- The number of generations already
|
||||
simulated.
|
||||
- **n_particles** (*int8_t*) -- Number of particles used per
|
||||
generation.
|
||||
- **run_mode** (*char[]*) -- Run mode used, either 'fixed source',
|
||||
'eigenvalue', or 'particle restart'.
|
||||
- **id** (*int8_t*) -- Unique identifier of the particle.
|
||||
- **weight** (*double*) -- Weight of the particle.
|
||||
- **energy** (*double*) -- Energy of the particle in eV for
|
||||
continuous-energy mode, or the energy group of the particle for
|
||||
multi-group mode.
|
||||
- **xyz** (*double[3]*) -- Position of the particle.
|
||||
- **uvw** (*double[3]*) -- Direction of the particle.
|
||||
192
docs/source/io_formats/plots.rst
Normal file
192
docs/source/io_formats/plots.rst
Normal file
|
|
@ -0,0 +1,192 @@
|
|||
.. _io_plots:
|
||||
|
||||
============================================
|
||||
Geometry Plotting Specification -- plots.xml
|
||||
============================================
|
||||
|
||||
Basic plotting capabilities are available in OpenMC by creating a plots.xml file
|
||||
and subsequently running with the ``--plot`` command-line flag. The root element
|
||||
of the plots.xml is simply ``<plots>`` and any number output plots can be
|
||||
defined with ``<plot>`` sub-elements. Two plot types are currently implemented
|
||||
in openMC:
|
||||
|
||||
* ``slice`` 2D pixel plot along one of the major axes. Produces a PPM image
|
||||
file.
|
||||
* ``voxel`` 3D voxel data dump. Produces a binary file containing voxel xyz
|
||||
position and cell or material id.
|
||||
|
||||
|
||||
------------------
|
||||
``<plot>`` Element
|
||||
------------------
|
||||
|
||||
Each plot is specified by a combination of the following attributes or
|
||||
sub-elements:
|
||||
|
||||
:id:
|
||||
The unique ``id`` of the plot.
|
||||
|
||||
*Default*: None - Required entry
|
||||
|
||||
:filename:
|
||||
Filename for the output plot file.
|
||||
|
||||
*Default*: "plot"
|
||||
|
||||
:color_by:
|
||||
Keyword for plot coloring. This can be either "cell" or "material", which
|
||||
colors regions by cells and materials, respectively. For voxel plots, this
|
||||
determines which id (cell or material) is associated with each position.
|
||||
|
||||
*Default*: "cell"
|
||||
|
||||
:level:
|
||||
Universe depth to plot at (optional). This parameter controls how many
|
||||
universe levels deep to pull cell and material ids from when setting plot
|
||||
colors. If a given location does not have as many levels as specified,
|
||||
colors will be taken from the lowest level at that location. For example, if
|
||||
``level`` is set to zero colors will be taken from top-level (universe zero)
|
||||
cells only. However, if ``level`` is set to 1 colors will be taken from
|
||||
cells in universes that fill top-level fill-cells, and from top-level cells
|
||||
that contain materials.
|
||||
|
||||
*Default*: Whatever the deepest universe is in the model
|
||||
|
||||
:origin:
|
||||
Specifies the (x,y,z) coordinate of the center of the plot. Should be three
|
||||
floats separated by spaces.
|
||||
|
||||
*Default*: None - Required entry
|
||||
|
||||
:width:
|
||||
Specifies the width of the plot along each of the basis directions. Should
|
||||
be two or three floats separated by spaces for 2D plots and 3D plots,
|
||||
respectively.
|
||||
|
||||
*Default*: None - Required entry
|
||||
|
||||
:type:
|
||||
Keyword for type of plot to be produced. Currently only "slice" and "voxel"
|
||||
plots are implemented. The "slice" plot type creates 2D pixel maps saved in
|
||||
the PPM file format. PPM files can be displayed in most viewers (e.g. the
|
||||
default Gnome viewer, IrfanView, etc.). The "voxel" plot type produces a
|
||||
binary datafile containing voxel grid positioning and the cell or material
|
||||
(specified by the ``color`` tag) at the center of each voxel. These
|
||||
datafiles can be processed into VTK files using the :ref:`scripts_voxel`
|
||||
script provided with OpenMC, and subsequently viewed with a 3D viewer such
|
||||
as VISIT or Paraview. See the :ref:`io_voxel` for information about the
|
||||
datafile structure.
|
||||
|
||||
.. note:: Since the PPM format is saved without any kind of compression,
|
||||
the resulting file sizes can be quite large. Saving the image in
|
||||
the PNG format can often times reduce the file size by orders of
|
||||
magnitude without any loss of image quality. Likewise,
|
||||
high-resolution voxel files produced by OpenMC can be quite large,
|
||||
but the equivalent VTK files will be significantly smaller.
|
||||
|
||||
*Default*: "slice"
|
||||
|
||||
``<plot>`` elements of ``type`` "slice" and "voxel" must contain the ``pixels``
|
||||
attribute or sub-element:
|
||||
|
||||
:pixels:
|
||||
Specifies the number of pixels or voxels to be used along each of the basis
|
||||
directions for "slice" and "voxel" plots, respectively. Should be two or
|
||||
three integers separated by spaces.
|
||||
|
||||
.. warning:: The ``pixels`` input determines the output file size. For the
|
||||
PPM format, 10 million pixels will result in a file just under
|
||||
30 MB in size. A 10 million voxel binary file will be around
|
||||
40 MB.
|
||||
|
||||
.. warning:: If the aspect ratio defined in ``pixels`` does not match the
|
||||
aspect ratio defined in ``width`` the plot may appear stretched
|
||||
or squeezed.
|
||||
|
||||
.. warning:: Geometry features along a basis direction smaller than
|
||||
``width``/``pixels`` along that basis direction may not appear
|
||||
in the plot.
|
||||
|
||||
*Default*: None - Required entry for "slice" and "voxel" plots
|
||||
|
||||
``<plot>`` elements of ``type`` "slice" can also contain the following
|
||||
attributes or sub-elements. These are not used in "voxel" plots:
|
||||
|
||||
:basis:
|
||||
Keyword specifying the plane of the plot for "slice" type plots. Can be
|
||||
one of: "xy", "xz", "yz".
|
||||
|
||||
*Default*: "xy"
|
||||
|
||||
:background:
|
||||
Specifies the RGB color of the regions where no OpenMC cell can be found.
|
||||
Should be three integers separated by spaces.
|
||||
|
||||
*Default*: 0 0 0 (black)
|
||||
|
||||
:color:
|
||||
Any number of this optional tag may be included in each ``<plot>`` element,
|
||||
which can override the default random colors for cells or materials. Each
|
||||
``color`` element must contain ``id`` and ``rgb`` sub-elements.
|
||||
|
||||
:id:
|
||||
Specifies the cell or material unique id for the color specification.
|
||||
|
||||
:rgb:
|
||||
Specifies the custom color for the cell or material. Should be 3 integers
|
||||
separated by spaces.
|
||||
|
||||
As an example, if your plot is colored by material and you want material 23
|
||||
to be blue, the corresponding ``color`` element would look like:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<color id="23" rgb="0 0 255" />
|
||||
|
||||
*Default*: None
|
||||
|
||||
:mask:
|
||||
The special ``mask`` sub-element allows for the selective plotting of *only*
|
||||
user-specified cells or materials. Only one ``mask`` element is allowed per
|
||||
``plot`` element, and it must contain as attributes or sub-elements a
|
||||
background masking color and a list of cells or materials to plot:
|
||||
|
||||
:components:
|
||||
List of unique ``id`` numbers of the cells or materials to plot. Should be
|
||||
any number of integers separated by spaces.
|
||||
|
||||
:background:
|
||||
Color to apply to all cells or materials not in the ``components`` list of
|
||||
cells or materials to plot. This overrides any ``color`` color
|
||||
specifications.
|
||||
|
||||
*Default*: 255 255 255 (white)
|
||||
|
||||
:meshlines:
|
||||
The ``meshlines`` sub-element allows for plotting the boundaries of a
|
||||
regular mesh on top of a plot. Only one ``meshlines`` element is allowed per
|
||||
``plot`` element, and it must contain as attributes or sub-elements a mesh
|
||||
type and a linewidth. Optionally, a color may be specified for the overlay:
|
||||
|
||||
:meshtype:
|
||||
The type of the mesh to be plotted. Valid options are "tally", "entropy",
|
||||
"ufs", and "cmfd". If plotting "tally" meshes, the id of the mesh to plot
|
||||
must be specified with the ``id`` sub-element.
|
||||
|
||||
:id:
|
||||
A single integer id number for the mesh specified on ``tallies.xml`` that
|
||||
should be plotted. This element is only required for ``meshtype="tally"``.
|
||||
|
||||
:linewidth:
|
||||
A single integer number of pixels of linewidth to specify for the mesh
|
||||
boundaries. Specifying this as 0 indicates that lines will be 1 pixel
|
||||
thick, specifying 1 indicates 3 pixels thick, specifying 2 indicates
|
||||
5 pixels thick, etc.
|
||||
|
||||
:color:
|
||||
Specifies the custom color for the meshlines boundaries. Should be 3
|
||||
integers separated by whitespace. This element is optional.
|
||||
|
||||
*Default*: 0 0 0 (black)
|
||||
|
||||
*Default*: None
|
||||
864
docs/source/io_formats/settings.rst
Normal file
864
docs/source/io_formats/settings.rst
Normal file
|
|
@ -0,0 +1,864 @@
|
|||
.. _io_settings:
|
||||
|
||||
======================================
|
||||
Settings Specification -- settings.xml
|
||||
======================================
|
||||
|
||||
All simulation parameters and miscellaneous options are specified in the
|
||||
settings.xml file.
|
||||
|
||||
---------------------
|
||||
``<batches>`` Element
|
||||
---------------------
|
||||
|
||||
The ``<batches>`` element indicates the total number of batches to execute,
|
||||
where each batch corresponds to a tally realization. In a fixed source
|
||||
calculation, each batch consists of a number of source particles. In an
|
||||
eigenvalue calculation, each batch consists of one or many fission source
|
||||
iterations (generations), where each generation itself consists of a number of
|
||||
source neutrons.
|
||||
|
||||
*Default*: None
|
||||
|
||||
----------------------------------
|
||||
``<confidence_intervals>`` Element
|
||||
----------------------------------
|
||||
|
||||
The ``<confidence_intervals>`` element has no attributes and has an accepted
|
||||
value of "true" or "false". If set to "true", uncertainties on tally results
|
||||
will be reported as the half-width of the 95% two-sided confidence interval. If
|
||||
set to "false", uncertainties on tally results will be reported as the sample
|
||||
standard deviation.
|
||||
|
||||
*Default*: false
|
||||
|
||||
-------------------------------------
|
||||
``<create_fission_neutrons>`` Element
|
||||
-------------------------------------
|
||||
|
||||
The ``<create_fission_neutrons>`` element indicates whether fission neutrons
|
||||
should be created or not. If this element is set to "true", fission neutrons
|
||||
will be created; otherwise the fission is treated as capture and no fission
|
||||
neutron will be created. Note that this option is only applied to fixed source
|
||||
calculation. For eigenvalue calculation, fission will always be treated as real
|
||||
fission.
|
||||
|
||||
*Default*: true
|
||||
|
||||
--------------------
|
||||
``<cutoff>`` Element
|
||||
--------------------
|
||||
|
||||
The ``<cutoff>`` element indicates two kinds of cutoffs. The first is the weight
|
||||
cutoff used below which particles undergo Russian roulette. Surviving particles
|
||||
are assigned a user-determined weight. Note that weight cutoffs and Russian
|
||||
rouletting are not turned on by default. The second is the energy cutoff which
|
||||
is used to kill particles under certain energy. The energy cutoff should not be
|
||||
used unless you know particles under the energy are of no importance to results
|
||||
you care. This element has the following attributes/sub-elements:
|
||||
|
||||
:weight:
|
||||
The weight below which particles undergo Russian roulette.
|
||||
|
||||
*Default*: 0.25
|
||||
|
||||
:weight_avg:
|
||||
The weight that is assigned to particles that are not killed after Russian
|
||||
roulette.
|
||||
|
||||
*Default*: 1.0
|
||||
|
||||
:energy_neutron:
|
||||
The energy under which neutrons will be killed.
|
||||
|
||||
*Default*: 0.0
|
||||
|
||||
:energy_photon:
|
||||
The energy under which photons will be killed.
|
||||
|
||||
*Default*: 1000.0
|
||||
|
||||
:energy_electron:
|
||||
The energy under which electrons will be killed.
|
||||
|
||||
*Default*: 0.0
|
||||
|
||||
:energy_positron:
|
||||
The energy under which positrons will be killed.
|
||||
|
||||
*Default*: 0.0
|
||||
|
||||
--------------------------------
|
||||
``<dagmc>`` Element
|
||||
--------------------------------
|
||||
|
||||
When the DAGMC mode is enabled, the OpenMC geometry will be read from the file
|
||||
``dagmc.h5m``. If a :ref:`geometry.xml <io_geometry>` file is present with
|
||||
``dagmc`` set to ``true``, it will be ignored.
|
||||
|
||||
--------------------------------
|
||||
``<electron_treatment>`` Element
|
||||
--------------------------------
|
||||
|
||||
When photon transport is enabled, the ``<electron_treatment>`` element tells
|
||||
OpenMC whether to deposit all energy from electrons locally (``led``) or create
|
||||
secondary bremsstrahlung photons (``ttb``).
|
||||
|
||||
*Default*: ttb
|
||||
|
||||
.. _energy_mode:
|
||||
|
||||
-------------------------
|
||||
``<energy_mode>`` Element
|
||||
-------------------------
|
||||
|
||||
The ``<energy_mode>`` element tells OpenMC if the run-mode should be
|
||||
continuous-energy or multi-group. Options for entry are: ``continuous-energy``
|
||||
or ``multi-group``.
|
||||
|
||||
*Default*: continuous-energy
|
||||
|
||||
--------------------------
|
||||
``<entropy_mesh>`` Element
|
||||
--------------------------
|
||||
|
||||
The ``<entropy_mesh>`` element indicates the ID of a mesh that is to be used for
|
||||
calculating Shannon entropy. The mesh should cover all possible fissionable
|
||||
materials in the problem and is specified using a :ref:`mesh_element`.
|
||||
|
||||
-----------------------------------
|
||||
``<generations_per_batch>`` Element
|
||||
-----------------------------------
|
||||
|
||||
The ``<generations_per_batch>`` element indicates the number of total fission
|
||||
source iterations per batch for an eigenvalue calculation. This element is
|
||||
ignored for all run modes other than "eigenvalue".
|
||||
|
||||
*Default*: 1
|
||||
|
||||
----------------------
|
||||
``<inactive>`` Element
|
||||
----------------------
|
||||
|
||||
The ``<inactive>`` element indicates the number of inactive batches used in a
|
||||
k-eigenvalue calculation. In general, the starting fission source iterations in
|
||||
an eigenvalue calculation can not be used to contribute to tallies since the
|
||||
fission source distribution and eigenvalue are generally not converged
|
||||
immediately. This element is ignored for all run modes other than "eigenvalue".
|
||||
|
||||
*Default*: 0
|
||||
|
||||
--------------------------
|
||||
``<keff_trigger>`` Element
|
||||
--------------------------
|
||||
|
||||
The ``<keff_trigger>`` element (ignored for all run modes other than
|
||||
"eigenvalue".) specifies a precision trigger on the combined
|
||||
:math:`k_{eff}`. The trigger is a convergence criterion on the uncertainty of
|
||||
the estimated eigenvalue. It has the following attributes/sub-elements:
|
||||
|
||||
:type:
|
||||
The type of precision trigger. Accepted options are "variance", "std_dev",
|
||||
and "rel_err".
|
||||
|
||||
:variance:
|
||||
Variance of the batch mean :math:`\sigma^2`
|
||||
|
||||
:std_dev:
|
||||
Standard deviation of the batch mean :math:`\sigma`
|
||||
|
||||
:rel_err:
|
||||
Relative error of the batch mean :math:`\frac{\sigma}{\mu}`
|
||||
|
||||
*Default*: None
|
||||
|
||||
:threshold:
|
||||
The precision trigger's convergence criterion for the
|
||||
combined :math:`k_{eff}`.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. note:: See section on the :ref:`trigger` for more information.
|
||||
|
||||
---------------------------
|
||||
``<log_grid_bins>`` Element
|
||||
---------------------------
|
||||
|
||||
The ``<log_grid_bins>`` element indicates the number of bins to use for the
|
||||
logarithmic-mapped energy grid. Using more bins will result in energy grid
|
||||
searches over a smaller range at the expense of more memory. The default is
|
||||
based on the recommended value in LA-UR-14-24530_.
|
||||
|
||||
*Default*: 8000
|
||||
|
||||
.. note:: This element is not used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
.. _LA-UR-14-24530: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-14-24530.pdf
|
||||
|
||||
---------------------------
|
||||
``<max_order>`` Element
|
||||
---------------------------
|
||||
|
||||
The ``<max_order>`` element allows the user to set a maximum scattering order
|
||||
to apply to every nuclide/material in the problem. That is, if the data
|
||||
library has :math:`P_3` data available, but ``<max_order>`` was set to ``1``,
|
||||
then, OpenMC will only use up to the :math:`P_1` data.
|
||||
|
||||
*Default*: Use the maximum order in the data library
|
||||
|
||||
.. note:: This element is not used in the continuous-energy
|
||||
:ref:`energy_mode`.
|
||||
|
||||
.. _mesh_element:
|
||||
|
||||
------------------
|
||||
``<mesh>`` Element
|
||||
------------------
|
||||
|
||||
The ``<mesh>`` element describes a mesh that is used either for calculating
|
||||
Shannon entropy, applying the uniform fission site method, or in tallies. For
|
||||
Shannon entropy meshes, the mesh should cover all possible fissionable materials
|
||||
in the problem. It has the following attributes/sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that is used to identify the mesh.
|
||||
|
||||
:dimension:
|
||||
The number of mesh cells in the x, y, and z directions, respectively.
|
||||
|
||||
*Default*: If this tag is not present, the number of mesh cells is
|
||||
automatically determined by the code.
|
||||
|
||||
:lower_left:
|
||||
The Cartesian coordinates of the lower-left corner of the mesh.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:upper_right:
|
||||
The Cartesian coordinates of the upper-right corner of the mesh.
|
||||
|
||||
*Default*: None
|
||||
|
||||
-----------------------
|
||||
``<no_reduce>`` Element
|
||||
-----------------------
|
||||
|
||||
The ``<no_reduce>`` element has no attributes and has an accepted value of
|
||||
"true" or "false". If set to "true", all user-defined tallies and global tallies
|
||||
will not be reduced across processors in a parallel calculation. This means that
|
||||
the accumulate score in one batch on a single processor is considered as an
|
||||
independent realization for the tally random variable. For a problem with large
|
||||
tally data, this option can significantly improve the parallel efficiency.
|
||||
|
||||
*Default*: false
|
||||
|
||||
--------------------
|
||||
``<output>`` Element
|
||||
--------------------
|
||||
|
||||
The ``<output>`` element determines what output files should be written to disk
|
||||
during the run. The sub-elements are described below, where "true" will write
|
||||
out the file and "false" will not.
|
||||
|
||||
:summary:
|
||||
Writes out an HDF5 summary file describing all of the user input files that
|
||||
were read in.
|
||||
|
||||
*Default*: true
|
||||
|
||||
:tallies:
|
||||
Write out an ASCII file of tally results.
|
||||
|
||||
*Default*: true
|
||||
|
||||
.. note:: The tally results will always be written to a binary/HDF5 state
|
||||
point file.
|
||||
|
||||
:path:
|
||||
Absolute or relative path where all output files should be written to. The
|
||||
specified path must exist or else OpenMC will abort.
|
||||
|
||||
*Default*: Current working directory
|
||||
|
||||
-----------------------
|
||||
``<particles>`` Element
|
||||
-----------------------
|
||||
|
||||
This element indicates the number of neutrons to simulate per fission source
|
||||
iteration when a k-eigenvalue calculation is performed or the number of
|
||||
particles per batch for a fixed source simulation.
|
||||
|
||||
*Default*: None
|
||||
|
||||
------------------------------
|
||||
``<photon_transport>`` Element
|
||||
------------------------------
|
||||
|
||||
The ``<photon_transport>`` element determines whether photon transport is
|
||||
enabled. This element has no attributes or sub-elements and can be set to
|
||||
either "false" or "true".
|
||||
|
||||
*Default*: false
|
||||
|
||||
---------------------
|
||||
``<ptables>`` Element
|
||||
---------------------
|
||||
|
||||
The ``<ptables>`` element determines whether probability tables should be used
|
||||
in the unresolved resonance range if available. This element has no attributes
|
||||
or sub-elements and can be set to either "false" or "true".
|
||||
|
||||
*Default*: true
|
||||
|
||||
.. note:: This element is not used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
----------------------------------
|
||||
``<resonance_scattering>`` Element
|
||||
----------------------------------
|
||||
|
||||
The ``resonance_scattering`` element indicates to OpenMC that a method be used
|
||||
to properly account for resonance elastic scattering (typically for nuclides
|
||||
with Z > 40). This element can contain one or more of the following attributes
|
||||
or sub-elements:
|
||||
|
||||
:enable:
|
||||
Indicates whether a resonance elastic scattering method should be turned
|
||||
on. Accepts values of "true" or "false".
|
||||
|
||||
*Default*: If the ``<resonance_scattering>`` element is present, "true".
|
||||
|
||||
:method:
|
||||
|
||||
Which resonance elastic scattering method is to be applied: "rvs" (relative
|
||||
velocity sampling) or "dbrc" (Doppler broadening rejection correction).
|
||||
Descriptions of each of these methods are documented here_.
|
||||
|
||||
.. _here: https://doi.org/10.1016/j.anucene.2017.12.044
|
||||
|
||||
*Default*: "rvs"
|
||||
|
||||
:energy_min:
|
||||
The energy in eV above which the resonance elastic scattering method should
|
||||
be applied.
|
||||
|
||||
*Default*: 0.01 eV
|
||||
|
||||
:energy_max:
|
||||
The energy in eV below which the resonance elastic scattering method should
|
||||
be applied.
|
||||
|
||||
*Default*: 1000.0 eV
|
||||
|
||||
:nuclides:
|
||||
|
||||
A list of nuclides to which the resonance elastic scattering method should
|
||||
be applied.
|
||||
|
||||
*Default*: If ``<resonance_scattering>`` is present but the ``<nuclides>``
|
||||
sub-element is not given, the method is applied to all nuclides with 0 K
|
||||
elastic scattering data present.
|
||||
|
||||
.. note:: If the ``resonance_scattering`` element is not given, the free gas,
|
||||
constant cross section scattering model, which has historically been
|
||||
used by Monte Carlo codes to sample target velocities, is used to
|
||||
treat the target motion of all nuclides. If
|
||||
``resonance_scattering`` is present, the constant cross section
|
||||
method is applied below ``energy_min`` and the target-at-rest
|
||||
(asymptotic) kernel is used above ``energy_max``.
|
||||
|
||||
.. note:: This element is not used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
----------------------
|
||||
``<run_mode>`` Element
|
||||
----------------------
|
||||
|
||||
The ``<run_mode>`` element indicates which run mode should be used when OpenMC
|
||||
is executed. This element has no attributes or sub-elements and can be set to
|
||||
"eigenvalue", "fixed source", "plot", "volume", or "particle restart".
|
||||
|
||||
*Default*: None
|
||||
|
||||
------------------
|
||||
``<seed>`` Element
|
||||
------------------
|
||||
|
||||
The ``seed`` element is used to set the seed used for the linear congruential
|
||||
pseudo-random number generator.
|
||||
|
||||
*Default*: 1
|
||||
|
||||
--------------------
|
||||
``<source>`` Element
|
||||
--------------------
|
||||
|
||||
The ``source`` element gives information on an external source distribution to
|
||||
be used either as the source for a fixed source calculation or the initial
|
||||
source guess for criticality calculations. Multiple ``<source>`` elements may be
|
||||
specified to define different source distributions. Each one takes the following
|
||||
attributes/sub-elements:
|
||||
|
||||
:strength:
|
||||
The strength of the source. If multiple sources are present, the source
|
||||
strength indicates the relative probability of choosing one source over the
|
||||
other.
|
||||
|
||||
*Default*: 1.0
|
||||
|
||||
:particle:
|
||||
The source particle type, either ``neutron`` or ``photon``.
|
||||
|
||||
*Default*: neutron
|
||||
|
||||
:file:
|
||||
If this attribute is given, it indicates that the source is to be read from
|
||||
a binary source file whose path is given by the value of this element. Note,
|
||||
the number of source sites needs to be the same as the number of particles
|
||||
simulated in a fission source generation.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:space:
|
||||
An element specifying the spatial distribution of source sites. This element
|
||||
has the following attributes:
|
||||
|
||||
:type:
|
||||
The type of spatial distribution. Valid options are "box", "fission",
|
||||
"point", and "cartesian". A "box" spatial distribution has coordinates
|
||||
sampled uniformly in a parallelepiped. A "fission" spatial distribution
|
||||
samples locations from a "box" distribution but only locations in
|
||||
fissionable materials are accepted. A "point" spatial distribution has
|
||||
coordinates specified by a triplet. An "cartesian" spatial distribution
|
||||
specifies independent distributions of x-, y-, and z-coordinates.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:parameters:
|
||||
For a "box" or "fission" spatial distribution, ``parameters`` should be
|
||||
given as six real numbers, the first three of which specify the lower-left
|
||||
corner of a parallelepiped and the last three of which specify the
|
||||
upper-right corner. Source sites are sampled uniformly through that
|
||||
parallelepiped.
|
||||
|
||||
For a "point" spatial distribution, ``parameters`` should be given as
|
||||
three real numbers which specify the (x,y,z) location of an isotropic
|
||||
point source.
|
||||
|
||||
For an "cartesian" distribution, no parameters are specified. Instead,
|
||||
the ``x``, ``y``, and ``z`` elements must be specified.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:x:
|
||||
For an "cartesian" distribution, this element specifies the distribution
|
||||
of x-coordinates. The necessary sub-elements/attributes are those of a
|
||||
univariate probability distribution (see the description in
|
||||
:ref:`univariate`).
|
||||
|
||||
:y:
|
||||
For an "cartesian" distribution, this element specifies the distribution
|
||||
of y-coordinates. The necessary sub-elements/attributes are those of a
|
||||
univariate probability distribution (see the description in
|
||||
:ref:`univariate`).
|
||||
|
||||
:z:
|
||||
For an "cartesian" distribution, this element specifies the distribution
|
||||
of z-coordinates. The necessary sub-elements/attributes are those of a
|
||||
univariate probability distribution (see the description in
|
||||
:ref:`univariate`).
|
||||
|
||||
:angle:
|
||||
An element specifying the angular distribution of source sites. This element
|
||||
has the following attributes:
|
||||
|
||||
:type:
|
||||
The type of angular distribution. Valid options are "isotropic",
|
||||
"monodirectional", and "mu-phi". The angle of the particle emitted from a
|
||||
source site is isotropic if the "isotropic" option is given. The angle of
|
||||
the particle emitted from a source site is the direction specified in the
|
||||
``reference_uvw`` element/attribute if "monodirectional" option is
|
||||
given. The "mu-phi" option produces directions with the cosine of the
|
||||
polar angle and the azimuthal angle explicitly specified.
|
||||
|
||||
*Default*: isotropic
|
||||
|
||||
:reference_uvw:
|
||||
The direction from which the polar angle is measured. Represented by the
|
||||
x-, y-, and z-components of a unit vector. For a monodirectional
|
||||
distribution, this defines the direction of all sampled particles.
|
||||
|
||||
:mu:
|
||||
An element specifying the distribution of the cosine of the polar
|
||||
angle. Only relevant when the type is "mu-phi". The necessary
|
||||
sub-elements/attributes are those of a univariate probability distribution
|
||||
(see the description in :ref:`univariate`).
|
||||
|
||||
:phi:
|
||||
An element specifying the distribution of the azimuthal angle. Only
|
||||
relevant when the type is "mu-phi". The necessary sub-elements/attributes
|
||||
are those of a univariate probability distribution (see the description in
|
||||
:ref:`univariate`).
|
||||
|
||||
:energy:
|
||||
An element specifying the energy distribution of source sites. The necessary
|
||||
sub-elements/attributes are those of a univariate probability distribution
|
||||
(see the description in :ref:`univariate`).
|
||||
|
||||
*Default*: Watt spectrum with :math:`a` = 0.988 MeV and :math:`b` =
|
||||
2.249 MeV :sup:`-1`
|
||||
|
||||
:write_initial:
|
||||
An element specifying whether to write out the initial source bank used at
|
||||
the beginning of the first batch. The output file is named
|
||||
"initial_source.h5"
|
||||
|
||||
*Default*: false
|
||||
|
||||
.. _univariate:
|
||||
|
||||
Univariate Probability Distributions
|
||||
++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Various components of a source distribution involve probability distributions of
|
||||
a single random variable, e.g. the distribution of the energy, the distribution
|
||||
of the polar angle, and the distribution of x-coordinates. Each of these
|
||||
components supports the same syntax with an element whose tag signifies the
|
||||
variable and whose sub-elements/attributes are as follows:
|
||||
|
||||
:type:
|
||||
The type of the distribution. Valid options are "uniform", "discrete",
|
||||
"tabular", "maxwell", and "watt". The "uniform" option produces variates
|
||||
sampled from a uniform distribution over a finite interval. The "discrete"
|
||||
option produces random variates that can assume a finite number of values
|
||||
(i.e., a distribution characterized by a probability mass function). The
|
||||
"tabular" option produces random variates sampled from a tabulated
|
||||
distribution where the density function is either a histogram or
|
||||
linearly-interpolated between tabulated points. The "watt" option produces
|
||||
random variates is sampled from a Watt fission spectrum (only used for
|
||||
energies). The "maxwell" option produce variates sampled from a Maxwell
|
||||
fission spectrum (only used for energies).
|
||||
|
||||
*Default*: None
|
||||
|
||||
:parameters:
|
||||
For a "uniform" distribution, ``parameters`` should be given as two real
|
||||
numbers :math:`a` and :math:`b` that define the interval :math:`[a,b]` over
|
||||
which random variates are sampled.
|
||||
|
||||
For a "discrete" or "tabular" distribution, ``parameters`` provides the
|
||||
:math:`(x,p)` pairs defining the discrete/tabular distribution. All :math:`x`
|
||||
points are given first followed by corresponding :math:`p` points.
|
||||
|
||||
For a "watt" distribution, ``parameters`` should be given as two real numbers
|
||||
:math:`a` and :math:`b` that parameterize the distribution :math:`p(x) dx = c
|
||||
e^{-x/a} \sinh \sqrt{b \, x} dx`.
|
||||
|
||||
For a "maxwell" distribution, ``parameters`` should be given as one real
|
||||
number :math:`a` that parameterizes the distribution :math:`p(x) dx = c x
|
||||
e^{-x/a} dx`.
|
||||
|
||||
.. note:: The above format should be used even when using the multi-group
|
||||
:ref:`energy_mode`.
|
||||
:interpolation:
|
||||
For a "tabular" distribution, ``interpolation`` can be set to "histogram" or
|
||||
"linear-linear" thereby specifying how tabular points are to be interpolated.
|
||||
|
||||
*Default*: histogram
|
||||
|
||||
-------------------------
|
||||
``<state_point>`` Element
|
||||
-------------------------
|
||||
|
||||
The ``<state_point>`` element indicates at what batches a state point file
|
||||
should be written. A state point file can be used to restart a run or to get
|
||||
tally results at any batch. The default behavior when using this tag is to
|
||||
write out the source bank in the state_point file. This behavior can be
|
||||
customized by using the ``<source_point>`` element. This element has the
|
||||
following attributes/sub-elements:
|
||||
|
||||
:batches:
|
||||
A list of integers separated by spaces indicating at what batches a state
|
||||
point file should be written.
|
||||
|
||||
*Default*: Last batch only
|
||||
|
||||
--------------------------
|
||||
``<source_point>`` Element
|
||||
--------------------------
|
||||
|
||||
The ``<source_point>`` element indicates at what batches the source bank
|
||||
should be written. The source bank can be either written out within a state
|
||||
point file or separately in a source point file. This element has the following
|
||||
attributes/sub-elements:
|
||||
|
||||
:batches:
|
||||
A list of integers separated by spaces indicating at what batches a state
|
||||
point file should be written. It should be noted that if the ``separate``
|
||||
attribute is not set to "true", this list must be a subset of state point
|
||||
batches.
|
||||
|
||||
*Default*: Last batch only
|
||||
|
||||
:separate:
|
||||
If this element is set to "true", a separate binary source point file will
|
||||
be written. Otherwise, the source sites will be written in the state point
|
||||
directly.
|
||||
|
||||
*Default*: false
|
||||
|
||||
:write:
|
||||
If this element is set to "false", source sites are not written
|
||||
to the state point or source point file. This can substantially reduce the
|
||||
size of state points if large numbers of particles per batch are used.
|
||||
|
||||
*Default*: true
|
||||
|
||||
:overwrite_latest:
|
||||
If this element is set to "true", a source point file containing
|
||||
the source bank will be written out to a separate file named
|
||||
``source.binary`` or ``source.h5`` depending on if HDF5 is enabled.
|
||||
This file will be overwritten at every single batch so that the latest
|
||||
source bank will be available. It should be noted that a user can set both
|
||||
this element to "true" and specify batches to write a permanent source bank.
|
||||
|
||||
*Default*: false
|
||||
|
||||
------------------------------
|
||||
``<survival_biasing>`` Element
|
||||
------------------------------
|
||||
|
||||
The ``<survival_biasing>`` element has no attributes and has an accepted value
|
||||
of "true" or "false". If set to "true", this option will enable the use of
|
||||
survival biasing, otherwise known as implicit capture or absorption.
|
||||
|
||||
*Default*: false
|
||||
|
||||
.. _tabular_legendre:
|
||||
|
||||
---------------------------------
|
||||
``<tabular_legendre>`` Element
|
||||
---------------------------------
|
||||
|
||||
The optional ``<tabular_legendre>`` element specifies how the multi-group
|
||||
Legendre scattering kernel is represented if encountered in a multi-group
|
||||
problem. Specifically, the options are to either convert the Legendre
|
||||
expansion to a tabular representation or leave it as a set of Legendre
|
||||
coefficients. Converting to a tabular representation will cost memory but can
|
||||
allow for a decrease in runtime compared to leaving as a set of Legendre
|
||||
coefficients. This element has the following attributes/sub-elements:
|
||||
|
||||
:enable:
|
||||
This attribute/sub-element denotes whether or not the conversion of a
|
||||
Legendre scattering expansion to the tabular format should be performed or
|
||||
not. A value of “true” means the conversion should be performed, “false”
|
||||
means it will not.
|
||||
|
||||
*Default*: true
|
||||
|
||||
:num_points:
|
||||
If the conversion is to take place the number of tabular points is
|
||||
required. This attribute/sub-element allows the user to set the desired
|
||||
number of points.
|
||||
|
||||
*Default*: 33
|
||||
|
||||
.. note:: This element is only used in the multi-group :ref:`energy_mode`.
|
||||
|
||||
.. _temperature_default:
|
||||
|
||||
---------------------------------
|
||||
``<temperature_default>`` Element
|
||||
---------------------------------
|
||||
|
||||
The ``<temperature_default>`` element specifies a default temperature in Kelvin
|
||||
that is to be applied to cells in the absence of an explicit cell temperature or
|
||||
a material default temperature.
|
||||
|
||||
*Default*: 293.6 K
|
||||
|
||||
.. _temperature_method:
|
||||
|
||||
--------------------------------
|
||||
``<temperature_method>`` Element
|
||||
--------------------------------
|
||||
|
||||
The ``<temperature_method>`` element has an accepted value of "nearest" or
|
||||
"interpolation". A value of "nearest" indicates that for each
|
||||
cell, the nearest temperature at which cross sections are given is to be
|
||||
applied, within a given tolerance (see :ref:`temperature_tolerance`). A value of
|
||||
"interpolation" indicates that cross sections are to be linear-linear
|
||||
interpolated between temperatures at which nuclear data are present (see
|
||||
:ref:`temperature_treatment`).
|
||||
|
||||
*Default*: "nearest"
|
||||
|
||||
.. _temperature_multipole:
|
||||
|
||||
-----------------------------------
|
||||
``<temperature_multipole>`` Element
|
||||
-----------------------------------
|
||||
|
||||
The ``<temperature_multipole>`` element toggles the windowed multipole
|
||||
capability on or off. If this element is set to "True" and the relevant data is
|
||||
available, OpenMC will use the windowed multipole method to evaluate and Doppler
|
||||
broaden cross sections in the resolved resonance range. This override other
|
||||
methods like "nearest" and "interpolation" in the resolved resonance range.
|
||||
|
||||
*Default*: False
|
||||
|
||||
-------------------------------
|
||||
``<temperature_range>`` Element
|
||||
-------------------------------
|
||||
|
||||
The ``<temperature_range>`` element specifies a minimum and maximum temperature
|
||||
in Kelvin above and below which cross sections should be loaded for all nuclides
|
||||
and thermal scattering tables. This can be used for multi-physics simulations
|
||||
where the temperatures might change from one iteration to the next.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. _temperature_tolerance:
|
||||
|
||||
-----------------------------------
|
||||
``<temperature_tolerance>`` Element
|
||||
-----------------------------------
|
||||
|
||||
The ``<temperature_tolerance>`` element specifies a tolerance in Kelvin that is
|
||||
to be applied when the "nearest" temperature method is used. For example, if a
|
||||
cell temperature is 340 K and the tolerance is 15 K, then the closest
|
||||
temperature in the range of 325 K to 355 K will be used to evaluate cross
|
||||
sections.
|
||||
|
||||
*Default*: 10 K
|
||||
|
||||
.. _trace:
|
||||
|
||||
-------------------
|
||||
``<trace>`` Element
|
||||
-------------------
|
||||
|
||||
The ``<trace>`` element can be used to print out detailed information about a
|
||||
single particle during a simulation. This element should be followed by three
|
||||
integers: the batch number, generation number, and particle number.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. _track:
|
||||
|
||||
-------------------
|
||||
``<track>`` Element
|
||||
-------------------
|
||||
|
||||
The ``<track>`` element specifies particles for which OpenMC will output binary
|
||||
files describing particle position at every step of its transport. This element
|
||||
should be followed by triplets of integers. Each triplet describes one
|
||||
particle. The integers in each triplet specify the batch number, generation
|
||||
number, and particle number, respectively.
|
||||
|
||||
*Default*: None
|
||||
|
||||
.. _trigger:
|
||||
|
||||
-------------------------
|
||||
``<trigger>`` Element
|
||||
-------------------------
|
||||
|
||||
OpenMC includes tally precision triggers which allow the user to define
|
||||
uncertainty thresholds on :math:`k_{eff}` in the ``<keff_trigger>`` subelement
|
||||
of ``settings.xml``, and/or tallies in ``tallies.xml``. When using triggers,
|
||||
OpenMC will run until it completes as many batches as defined by ``<batches>``.
|
||||
At this point, the uncertainties on all tallied values are computed and compared
|
||||
with their corresponding trigger thresholds. If any triggers have not been met,
|
||||
OpenMC will continue until either all trigger thresholds have been satisfied or
|
||||
``<max_batches>`` has been reached.
|
||||
|
||||
The ``<trigger>`` element provides an active "toggle switch" for tally
|
||||
precision trigger(s), the maximum number of batches and the batch interval. It
|
||||
has the following attributes/sub-elements:
|
||||
|
||||
:active:
|
||||
This determines whether or not to use trigger(s). Trigger(s) are used when
|
||||
this tag is set to "true".
|
||||
|
||||
:max_batches:
|
||||
This describes the maximum number of batches allowed when using trigger(s).
|
||||
|
||||
.. note:: When max_batches is set, the number of ``batches`` shown in the
|
||||
``<batches>`` element represents minimum number of batches to
|
||||
simulate when using the trigger(s).
|
||||
|
||||
:batch_interval:
|
||||
This tag describes the number of batches in between convergence checks.
|
||||
OpenMC will check if the trigger has been reached at each batch defined
|
||||
by ``batch_interval`` after the minimum number of batches is reached.
|
||||
|
||||
.. note:: If this tag is not present, the ``batch_interval`` is predicted
|
||||
dynamically by OpenMC for each convergence check. The predictive
|
||||
model assumes no correlation between fission sources
|
||||
distributions from batch-to-batch. This assumption is reasonable
|
||||
for fixed source and small criticality calculations, but is very
|
||||
optimistic for highly coupled full-core reactor problems.
|
||||
|
||||
|
||||
------------------------
|
||||
``<ufs_mesh>`` Element
|
||||
------------------------
|
||||
|
||||
The ``<ufs_mesh>`` element indicates the ID of a mesh that is used for
|
||||
re-weighting source sites at every generation based on the uniform fission site
|
||||
methodology described in Kelly et al., "MC21 Analysis of the Nuclear Energy
|
||||
Agency Monte Carlo Performance Benchmark Problem," Proceedings of *Physor 2012*,
|
||||
Knoxville, TN (2012). The mesh should cover all possible fissionable materials
|
||||
in the problem and is specified using a :ref:`mesh_element`.
|
||||
|
||||
.. _verbosity:
|
||||
|
||||
-----------------------
|
||||
``<verbosity>`` Element
|
||||
-----------------------
|
||||
|
||||
The ``<verbosity>`` element tells the code how much information to display to
|
||||
the standard output. A higher verbosity corresponds to more information being
|
||||
displayed. The text of this element should be an integer between between 1
|
||||
and 10. The verbosity levels are defined as follows:
|
||||
|
||||
:1: don't display any output
|
||||
:2: only show OpenMC logo
|
||||
:3: all of the above + headers
|
||||
:4: all of the above + results
|
||||
:5: all of the above + file I/O
|
||||
:6: all of the above + timing statistics and initialization messages
|
||||
:7: all of the above + :math:`k` by generation
|
||||
:9: all of the above + indicate when each particle starts
|
||||
:10: all of the above + event information
|
||||
|
||||
*Default*: 7
|
||||
|
||||
-------------------------
|
||||
``<volume_calc>`` Element
|
||||
-------------------------
|
||||
|
||||
The ``<volume_calc>`` element indicates that a stochastic volume calculation
|
||||
should be run at the beginning of the simulation. This element has the following
|
||||
sub-elements/attributes:
|
||||
|
||||
:cells:
|
||||
The unique IDs of cells for which the volume should be estimated.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:samples:
|
||||
The number of samples used to estimate volumes.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:lower_left:
|
||||
The lower-left Cartesian coordinates of a bounding box that is used to
|
||||
sample points within.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:upper_right:
|
||||
The upper-right Cartesian coordinates of a bounding box that is used to
|
||||
sample points within.
|
||||
|
||||
*Default*: None
|
||||
21
docs/source/io_formats/source.rst
Normal file
21
docs/source/io_formats/source.rst
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
.. _io_source:
|
||||
|
||||
==================
|
||||
Source File Format
|
||||
==================
|
||||
|
||||
Normally, source data is stored in a state point file. However, it is possible
|
||||
to request that the source be written separately, in which case the format used
|
||||
is that documented here.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
|
||||
:Datasets:
|
||||
|
||||
- **source_bank** (Compound type) -- Source bank information for each
|
||||
particle. The compound type has fields ``wgt``, ``xyz``, ``uvw``,
|
||||
``E``, ``delayed_group``, and ``particle``, which represent the
|
||||
weight, position, direction, energy, energy group, delayed group,
|
||||
and type of the source particle, respectively.
|
||||
159
docs/source/io_formats/statepoint.rst
Normal file
159
docs/source/io_formats/statepoint.rst
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
.. _io_statepoint:
|
||||
|
||||
=======================
|
||||
State Point File Format
|
||||
=======================
|
||||
|
||||
The current version of the statepoint file format is 17.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the
|
||||
statepoint file format.
|
||||
- **openmc_version** (*int[3]*) -- Major, minor, and release
|
||||
version number for OpenMC.
|
||||
- **git_sha1** (*char[40]*) -- Git commit SHA-1 hash.
|
||||
- **date_and_time** (*char[]*) -- Date and time the summary was
|
||||
written.
|
||||
- **path** (*char[]*) -- Path to directory containing input files.
|
||||
- **tallies_present** (*int*) -- Flag indicating whether tallies
|
||||
are present (1) or not (0).
|
||||
- **source_present** (*int*) -- Flag indicating whether the source
|
||||
bank is present (1) or not (0).
|
||||
|
||||
:Datasets: - **seed** (*int8_t*) -- Pseudo-random number generator seed.
|
||||
- **energy_mode** (*char[]*) -- Energy mode of the run, either
|
||||
'continuous-energy' or 'multi-group'.
|
||||
- **run_mode** (*char[]*) -- Run mode used, either 'eigenvalue' or
|
||||
'fixed source'.
|
||||
- **n_particles** (*int8_t*) -- Number of particles used per generation.
|
||||
- **n_batches** (*int*) -- Number of batches to simulate.
|
||||
- **current_batch** (*int*) -- The number of batches already simulated.
|
||||
- **n_inactive** (*int*) -- Number of inactive batches. Only present
|
||||
when `run_mode` is 'eigenvalue'.
|
||||
- **generations_per_batch** (*int*) -- Number of generations per
|
||||
batch. Only present when `run_mode` is 'eigenvalue'.
|
||||
- **k_generation** (*double[]*) -- k-effective for each generation
|
||||
simulated.
|
||||
- **entropy** (*double[]*) -- Shannon entropy for each generation
|
||||
simulated.
|
||||
- **k_col_abs** (*double*) -- Sum of product of collision/absorption
|
||||
estimates of k-effective.
|
||||
- **k_col_tra** (*double*) -- Sum of product of
|
||||
collision/track-length estimates of k-effective.
|
||||
- **k_abs_tra** (*double*) -- Sum of product of
|
||||
absorption/track-length estimates of k-effective.
|
||||
- **k_combined** (*double[2]*) -- Mean and standard deviation of a
|
||||
combined estimate of k-effective.
|
||||
- **n_realizations** (*int*) -- Number of realizations for global
|
||||
tallies.
|
||||
- **global_tallies** (*double[][2]*) -- Accumulated sum and
|
||||
sum-of-squares for each global tally.
|
||||
- **source_bank** (Compound type) -- Source bank information for each
|
||||
particle. The compound type has fields ``wgt``, ``xyz``, ``uvw``,
|
||||
``E``, ``g``, and ``delayed_group``, which represent the weight,
|
||||
position, direction, energy, energy group, and delayed_group of the
|
||||
source particle, respectively. Only present when `run_mode` is
|
||||
'eigenvalue'.
|
||||
|
||||
**/tallies/**
|
||||
|
||||
:Attributes: - **n_tallies** (*int*) -- Number of user-defined tallies.
|
||||
- **ids** (*int[]*) -- User-defined unique ID of each tally.
|
||||
|
||||
**/tallies/meshes/**
|
||||
|
||||
:Attributes: - **n_meshes** (*int*) -- Number of meshes in the problem.
|
||||
- **ids** (*int[]*) -- User-defined unique ID of each mesh.
|
||||
|
||||
**/tallies/meshes/mesh <uid>/**
|
||||
|
||||
:Datasets: - **type** (*char[]*) -- Type of mesh.
|
||||
- **dimension** (*int*) -- Number of mesh cells in each dimension.
|
||||
- **lower_left** (*double[]*) -- Coordinates of lower-left corner of
|
||||
mesh.
|
||||
- **upper_right** (*double[]*) -- Coordinates of upper-right corner
|
||||
of mesh.
|
||||
- **width** (*double[]*) -- Width of each mesh cell in each
|
||||
dimension.
|
||||
|
||||
**/tallies/filters/**
|
||||
|
||||
:Attributes: - **n_filters** (*int*) -- Number of filters in the problem.
|
||||
- **ids** (*int[]*) -- User-defined unique ID of each filter.
|
||||
|
||||
**/tallies/filters/filter <uid>/**
|
||||
|
||||
:Datasets: - **type** (*char[]*) -- Type of the j-th filter. Can be 'universe',
|
||||
'material', 'cell', 'cellborn', 'surface', 'mesh', 'energy',
|
||||
'energyout', 'distribcell', 'mu', 'polar', 'azimuthal',
|
||||
'delayedgroup', or 'energyfunction'.
|
||||
- **n_bins** (*int*) -- Number of bins for the j-th filter. Not
|
||||
present for 'energyfunction' filters.
|
||||
- **bins** (*int[]* or *double[]*) -- Value for each filter bin of
|
||||
this type. Not present for 'energyfunction' filters.
|
||||
- **energy** (*double[]*) -- Energy grid points for energyfunction
|
||||
interpolation. Only used for 'energyfunction' filters.
|
||||
- **y** (*double[]*) -- Interpolant values for energyfunction
|
||||
interpolation. Only used for 'energyfunction' filters.
|
||||
|
||||
**/tallies/derivatives/derivative <id>/**
|
||||
|
||||
:Datasets: - **independent variable** (*char[]*) -- Independent variable of
|
||||
tally derivative.
|
||||
- **material** (*int*) -- ID of the perturbed material.
|
||||
- **nuclide** (*char[]*) -- Alias of the perturbed nuclide.
|
||||
- **estimator** (*char[]*) -- Type of tally estimator, either
|
||||
'analog', 'tracklength', or 'collision'.
|
||||
|
||||
**/tallies/tally <uid>/**
|
||||
|
||||
:Attributes:
|
||||
- **internal** (*int*) -- Flag indicating the presence of tally
|
||||
data (0) or absence of tally data (1). All user defined
|
||||
tallies will have a value of 0 unless otherwise instructed.
|
||||
|
||||
:Datasets: - **n_realizations** (*int*) -- Number of realizations.
|
||||
- **n_filters** (*int*) -- Number of filters used.
|
||||
- **filters** (*int[]*) -- User-defined unique IDs of the filters on
|
||||
the tally
|
||||
- **nuclides** (*char[][]*) -- Array of nuclides to tally. Note that
|
||||
if no nuclide is specified in the user input, a single 'total'
|
||||
nuclide appears here.
|
||||
- **derivative** (*int*) -- ID of the derivative applied to the
|
||||
tally.
|
||||
- **n_score_bins** (*int*) -- Number of scoring bins for a single
|
||||
nuclide.
|
||||
- **score_bins** (*char[][]*) -- Values of specified scores.
|
||||
- **results** (*double[][][2]*) -- Accumulated sum and sum-of-squares
|
||||
for each bin of the i-th tally. The first dimension represents
|
||||
combinations of filter bins, the second dimensions represents
|
||||
scoring bins, and the third dimension has two entries for the sum
|
||||
and the sum-of-squares.
|
||||
|
||||
**/runtime/**
|
||||
|
||||
All values are given in seconds and are measured on the master process.
|
||||
|
||||
:Datasets: - **total initialization** (*double*) -- Time spent reading inputs,
|
||||
allocating arrays, etc.
|
||||
- **reading cross sections** (*double*) -- Time spent loading cross
|
||||
section libraries (this is a subset of initialization).
|
||||
- **simulation** (*double*) -- Time spent between initialization and
|
||||
finalization.
|
||||
- **transport** (*double*) -- Time spent transporting particles.
|
||||
- **inactive batches** (*double*) -- Time spent in the inactive
|
||||
batches (including non-transport activities like communcating
|
||||
sites).
|
||||
- **active batches** (*double*) -- Time spent in the active batches
|
||||
(including non-transport activities like communicating sites).
|
||||
- **synchronizing fission bank** (*double*) -- Time spent sampling
|
||||
source particles from fission sites and communicating them to other
|
||||
processes for load balancing.
|
||||
- **sampling source sites** (*double*) -- Time spent sampling source
|
||||
particles from fission sites.
|
||||
- **SEND-RECV source sites** (*double*) -- Time spent communicating
|
||||
source sites between processes for load balancing.
|
||||
- **accumulating tallies** (*double*) -- Time spent communicating
|
||||
tally results and evaluating their statistics.
|
||||
143
docs/source/io_formats/summary.rst
Normal file
143
docs/source/io_formats/summary.rst
Normal file
|
|
@ -0,0 +1,143 @@
|
|||
.. _io_summary:
|
||||
|
||||
===================
|
||||
Summary File Format
|
||||
===================
|
||||
|
||||
The current version of the summary file format is 6.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the summary
|
||||
file format.
|
||||
- **openmc_version** (*int[3]*) -- Major, minor, and release
|
||||
version number for OpenMC.
|
||||
- **git_sha1** (*char[40]*) -- Git commit SHA-1 hash.
|
||||
- **date_and_time** (*char[]*) -- Date and time the summary was
|
||||
written.
|
||||
|
||||
**/geometry/**
|
||||
|
||||
:Attributes: - **n_cells** (*int*) -- Number of cells in the problem.
|
||||
- **n_surfaces** (*int*) -- Number of surfaces in the problem.
|
||||
- **n_universes** (*int*) -- Number of unique universes in the
|
||||
problem.
|
||||
- **n_lattices** (*int*) -- Number of lattices in the problem.
|
||||
- **dagmc** (*int*) -- Indicates that a DAGMC geometry was used
|
||||
if present.
|
||||
|
||||
**/geometry/cells/cell <uid>/**
|
||||
|
||||
:Datasets: - **name** (*char[]*) -- User-defined name of the cell.
|
||||
- **universe** (*int*) -- Universe assigned to the cell. If none is
|
||||
specified, the default universe (0) is assigned.
|
||||
- **fill_type** (*char[]*) -- Type of fill for the cell. Can be
|
||||
'material', 'universe', or 'lattice'.
|
||||
- **material** (*int* or *int[]*) -- Unique ID of the material(s)
|
||||
assigned to the cell. This dataset is present only if fill_type is
|
||||
set to 'normal'. The value '-1' signifies void material. The data
|
||||
is an array if the cell uses distributed materials, otherwise it is
|
||||
a scalar.
|
||||
- **temperature** (*double[]*) -- Temperature of the cell in Kelvin.
|
||||
- **translation** (*double[3]*) -- Translation applied to the fill
|
||||
universe. This dataset is present only if fill_type is set to
|
||||
'universe'.
|
||||
- **rotation** (*double[3]*) -- Angles in degrees about the x-, y-,
|
||||
and z-axes for which the fill universe should be rotated. This
|
||||
dataset is present only if fill_type is set to 'universe'.
|
||||
- **lattice** (*int*) -- Unique ID of the lattice which fills the
|
||||
cell. Only present if fill_type is set to 'lattice'.
|
||||
- **region** (*char[]*) -- Region specification for the cell.
|
||||
|
||||
**/geometry/surfaces/surface <uid>/**
|
||||
|
||||
:Datasets: - **name** (*char[]*) -- Name of the surface.
|
||||
- **type** (*char[]*) -- Type of the surface. Can be 'x-plane',
|
||||
'y-plane', 'z-plane', 'plane', 'x-cylinder', 'y-cylinder',
|
||||
'z-cylinder', 'sphere', 'x-cone', 'y-cone', 'z-cone', or 'quadric'.
|
||||
- **coefficients** (*double[]*) -- Array of coefficients that define
|
||||
the surface. See :ref:`surface_element` for what coefficients are
|
||||
defined for each surface type.
|
||||
- **boundary_condition** (*char[]*) -- Boundary condition applied to
|
||||
the surface. Can be 'transmission', 'vacuum', 'reflective', or
|
||||
'periodic'.
|
||||
|
||||
**/geometry/universes/universe <uid>/**
|
||||
|
||||
:Datasets:
|
||||
- **cells** (*int[]*) -- Array of unique IDs of cells that appear in
|
||||
the universe.
|
||||
|
||||
**/geometry/lattices/lattice <uid>/**
|
||||
|
||||
:Datasets: - **name** (*char[]*) -- Name of the lattice.
|
||||
- **type** (*char[]*) -- Type of the lattice, either 'rectangular' or
|
||||
'hexagonal'.
|
||||
- **pitch** (*double[]*) -- Pitch of the lattice in centimeters.
|
||||
- **outer** (*int*) -- Outer universe assigned to lattice cells
|
||||
outside the defined range.
|
||||
- **universes** (*int[][][]*) -- Three-dimensional array of universes
|
||||
assigned to each cell of the lattice.
|
||||
- **dimension** (*int[]*) -- The number of lattice cells in each
|
||||
direction. This dataset is present only when the 'type' dataset is
|
||||
set to 'rectangular'.
|
||||
- **lower_left** (*double[]*) -- The coordinates of the lower-left
|
||||
corner of the lattice. This dataset is present only when the 'type'
|
||||
dataset is set to 'rectangular'.
|
||||
- **n_rings** (*int*) -- Number of radial ring positions in the
|
||||
xy-plane. This dataset is present only when the 'type' dataset is
|
||||
set to 'hexagonal'.
|
||||
- **n_axial** (*int*) -- Number of lattice positions along the
|
||||
z-axis. This dataset is present only when the 'type' dataset is set
|
||||
to 'hexagonal'.
|
||||
- **center** (*double[]*) -- Coordinates of the center of the
|
||||
lattice. This dataset is present only when the 'type' dataset is
|
||||
set to 'hexagonal'.
|
||||
|
||||
**/materials/**
|
||||
|
||||
:Attributes: - **n_materials** (*int*) -- Number of materials in the problem.
|
||||
|
||||
|
||||
**/materials/material <uid>/**
|
||||
|
||||
:Datasets: - **name** (*char[]*) -- Name of the material.
|
||||
- **atom_density** (*double[]*) -- Total atom density of the material
|
||||
in atom/b-cm.
|
||||
- **nuclides** (*char[][]*) -- Array of nuclides present in the
|
||||
material, e.g., 'U235'. This data set is only present if nuclides
|
||||
are used.
|
||||
- **nuclide_densities** (*double[]*) -- Atom density of each nuclide.
|
||||
This data set is only present if 'nuclides' data set is present.
|
||||
- **macroscopics** (*char[][]*) -- Array of macroscopic data sets
|
||||
present in the material. This dataset is only present if
|
||||
macroscopic data sets are used in multi-group mode.
|
||||
- **sab_names** (*char[][]*) -- Names of
|
||||
S(:math:`\alpha,\beta`) tables assigned to the material.
|
||||
|
||||
:Attributes: - **volume** (*double[]*) -- Volume of this material [cm^3]. Only
|
||||
present if ``volume`` supplied
|
||||
- **temperature** (*double[]*) -- Temperature of this material [K].
|
||||
Only present in ``temperature`` supplied
|
||||
- **depletable** (*int[]*) -- ``1`` if the material can be depleted,
|
||||
``0`` otherwise. Always present
|
||||
|
||||
**/nuclides/**
|
||||
|
||||
:Attributes: - **n_nuclides** (*int*) -- Number of nuclides in the problem.
|
||||
|
||||
:Datasets: - **names** (*char[][]*) -- Names of nuclides.
|
||||
- **awrs** (*float[]*) -- Atomic weight ratio of each nuclide.
|
||||
|
||||
**/macroscopics/**
|
||||
|
||||
:Attributes:
|
||||
- **n_macroscopics** (*int*) -- Number of macroscopic data sets
|
||||
in the problem.
|
||||
|
||||
:Datasets: - **names** (*char[][]*) -- Names of the macroscopic data sets.
|
||||
|
||||
**/tallies/tally <uid>/**
|
||||
|
||||
:Datasets: - **name** (*char[]*) -- Name of the tally.
|
||||
391
docs/source/io_formats/tallies.rst
Normal file
391
docs/source/io_formats/tallies.rst
Normal file
|
|
@ -0,0 +1,391 @@
|
|||
.. _io_tallies:
|
||||
|
||||
====================================
|
||||
Tallies Specification -- tallies.xml
|
||||
====================================
|
||||
|
||||
The tallies.xml file allows the user to tell the code what results he/she is
|
||||
interested in, e.g. the fission rate in a given cell or the current across a
|
||||
given surface. There are two pieces of information that determine what
|
||||
quantities should be scored. First, one needs to specify what region of phase
|
||||
space should count towards the tally and secondly, the actual quantity to be
|
||||
scored also needs to be specified. The first set of parameters we call *filters*
|
||||
since they effectively serve to filter events, allowing some to score and
|
||||
preventing others from scoring to the tally.
|
||||
|
||||
The structure of tallies in OpenMC is flexible in that any combination of
|
||||
filters can be used for a tally. The following types of filter are available:
|
||||
cell, universe, material, surface, birth region, pre-collision energy,
|
||||
post-collision energy, and an arbitrary structured mesh.
|
||||
|
||||
The five valid elements in the tallies.xml file are ``<tally>``, ``<filter>``,
|
||||
``<mesh>``, ``<derivative>``, and ``<assume_separate>``.
|
||||
|
||||
.. _tally:
|
||||
|
||||
-------------------
|
||||
``<tally>`` Element
|
||||
-------------------
|
||||
|
||||
The ``<tally>`` element accepts the following sub-elements:
|
||||
|
||||
:name:
|
||||
An optional string name to identify the tally in summary output
|
||||
files. This string is limited to 52 characters for formatting purposes.
|
||||
|
||||
*Default*: ""
|
||||
|
||||
:filters:
|
||||
A space-separated list of the IDs of ``filter`` elements.
|
||||
|
||||
:nuclides:
|
||||
If specified, the scores listed will be for particular nuclides, not the
|
||||
summation of reactions from all nuclides. The format for nuclides should be
|
||||
[Atomic symbol]-[Mass number], e.g. "U-235". The reaction rate for all
|
||||
nuclides can be obtained with "total". For example, to obtain the reaction
|
||||
rates for U-235, Pu-239, and all nuclides in a material, this element should
|
||||
be:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<nuclides>U-235 Pu-239 total</nuclides>
|
||||
|
||||
*Default*: total
|
||||
|
||||
:estimator:
|
||||
The estimator element is used to force the use of either ``analog``,
|
||||
``collision``, or ``tracklength`` tally estimation. ``analog`` is generally
|
||||
the least efficient though it can be used with every score type.
|
||||
``tracklength`` is generally the most efficient, but neither ``tracklength``
|
||||
nor ``collision`` can be used to score a tally that requires post-collision
|
||||
information. For example, a scattering tally with outgoing energy filters
|
||||
cannot be used with ``tracklength`` or ``collision`` because the code will
|
||||
not know the outgoing energy distribution.
|
||||
|
||||
*Default*: ``tracklength`` but will revert to ``analog`` if necessary.
|
||||
|
||||
:scores:
|
||||
A space-separated list of the desired responses to be accumulated. A full
|
||||
list of valid scores can be found in the :ref:`user's guide
|
||||
<usersguide_scores>`.
|
||||
|
||||
:trigger:
|
||||
Precision trigger applied to all filter bins and nuclides for this tally.
|
||||
It must specify the trigger's type, threshold and scores to which it will
|
||||
be applied. It has the following attributes/sub-elements:
|
||||
|
||||
:type:
|
||||
The type of the trigger. Accepted options are "variance", "std_dev",
|
||||
and "rel_err".
|
||||
|
||||
:variance:
|
||||
Variance of the batch mean :math:`\sigma^2`
|
||||
|
||||
:std_dev:
|
||||
Standard deviation of the batch mean :math:`\sigma`
|
||||
|
||||
:rel_err:
|
||||
Relative error of the batch mean :math:`\frac{\sigma}{\mu}`
|
||||
|
||||
*Default*: None
|
||||
|
||||
:threshold:
|
||||
The precision trigger's convergence criterion for tallied values.
|
||||
|
||||
*Default*: None
|
||||
|
||||
:scores:
|
||||
The score(s) in this tally to which the trigger should be applied.
|
||||
|
||||
.. note:: The ``scores`` in ``trigger`` must have been defined in
|
||||
``scores`` in ``tally``. An optional "all" may be used to
|
||||
select all scores in this tally.
|
||||
|
||||
*Default*: "all"
|
||||
|
||||
:derivative:
|
||||
The id of a ``derivative`` element. This derivative will be applied to all
|
||||
scores in the tally. Differential tallies are currently only implemented
|
||||
for collision and analog estimators.
|
||||
|
||||
*Default*: None
|
||||
|
||||
|
||||
--------------------
|
||||
``<filter>`` Element
|
||||
--------------------
|
||||
|
||||
Filters can be used to modify tally behavior. Most tallies (e.g. ``cell``,
|
||||
``energy``, and ``material``) restrict the tally so that only particles
|
||||
within certain regions of phase space contribute to the tally. Others
|
||||
(e.g. ``delayedgroup`` and ``energyfunction``) can apply some other function
|
||||
to the scored values. The ``filter`` element has the following
|
||||
attributes/sub-elements:
|
||||
|
||||
:type:
|
||||
The type of the filter. Accepted options are "cell", "cellfrom",
|
||||
"cellborn", "surface", "material", "universe", "energy", "energyout", "mu",
|
||||
"polar", "azimuthal", "mesh", "distribcell", "delayedgroup",
|
||||
"energyfunction", and "particle".
|
||||
|
||||
:bins:
|
||||
A description of the bins for each type of filter can be found in
|
||||
:ref:`filter_types`.
|
||||
|
||||
:energy:
|
||||
``energyfunction`` filters multiply tally scores by an arbitrary
|
||||
function. The function is described by a piecewise linear-linear set of
|
||||
(energy, y) values. This entry specifies the energy values. The function
|
||||
will be evaluated as zero outside of the bounds of this energy grid.
|
||||
(Only used for ``energyfunction`` filters)
|
||||
|
||||
:y:
|
||||
``energyfunction`` filters multiply tally scores by an arbitrary
|
||||
function. The function is described by a piecewise linear-linear set of
|
||||
(energy, y) values. This entry specifies the y values. (Only used
|
||||
for ``energyfunction`` filters)
|
||||
|
||||
.. _filter_types:
|
||||
|
||||
Filter Types
|
||||
++++++++++++
|
||||
|
||||
For each filter type, the following table describes what the ``bins`` attribute
|
||||
should be set to:
|
||||
|
||||
:cell:
|
||||
A list of unique IDs for cells in which the tally should be
|
||||
accumulated.
|
||||
|
||||
:surface:
|
||||
This filter allows the tally to be scored when crossing a surface. A list of
|
||||
surface IDs should be given. By default, net currents are tallied, and to
|
||||
tally a partial current from one cell to another, this should be used in
|
||||
combination with a cell or cell_from filter that defines the other cell.
|
||||
This filter should not be used in combination with a meshfilter.
|
||||
|
||||
:cellfrom:
|
||||
This filter allows the tally to be scored when crossing a surface and the
|
||||
particle came from a specified cell. A list of cell IDs should be
|
||||
given.
|
||||
To tally a partial current from a cell to another, this filter should be
|
||||
used in combination with a cell filter, to define the other cell.
|
||||
This filter should not be used in combination with a meshfilter.
|
||||
|
||||
:cellborn:
|
||||
This filter allows the tally to be scored to only when particles were
|
||||
originally born in a specified cell. A list of cell IDs should be
|
||||
given.
|
||||
|
||||
:material:
|
||||
A list of unique IDs for materials in which the tally should be accumulated.
|
||||
|
||||
:universe:
|
||||
A list of unique IDs for universes in which the tally should be accumulated.
|
||||
|
||||
:energy:
|
||||
In continuous-energy mode, this filter should be provided as a
|
||||
monotonically increasing list of bounding **pre-collision** energies
|
||||
for a number of groups. For example, if this filter is specified as
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="energy" bins="0.0 1.0e6 20.0e6" />
|
||||
|
||||
then two energy bins will be created, one with energies between 0 and
|
||||
1 MeV and the other with energies between 1 and 20 MeV.
|
||||
|
||||
In multi-group mode the bins provided must match group edges
|
||||
defined in the multi-group library.
|
||||
|
||||
:energyout:
|
||||
In continuous-energy mode, this filter should be provided as a
|
||||
monotonically increasing list of bounding **post-collision** energies
|
||||
for a number of groups. For example, if this filter is specified as
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="energyout" bins="0.0 1.0e6 20.0e6" />
|
||||
|
||||
then two post-collision energy bins will be created, one with
|
||||
energies between 0 and 1 MeV and the other with energies between
|
||||
1 and 20 MeV.
|
||||
|
||||
In multi-group mode the bins provided must match group edges
|
||||
defined in the multi-group library.
|
||||
|
||||
:mu:
|
||||
A monotonically increasing list of bounding **post-collision** cosines
|
||||
of the change in a particle's angle (i.e., :math:`\mu = \hat{\Omega}
|
||||
\cdot \hat{\Omega}'`), which represents a portion of the possible
|
||||
values of :math:`[-1,1]`. For example, spanning all of :math:`[-1,1]`
|
||||
with five equi-width bins can be specified as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="mu" bins="-1.0 -0.6 -0.2 0.2 0.6 1.0" />
|
||||
|
||||
Alternatively, if only one value is provided as a bin, OpenMC will
|
||||
interpret this to mean the complete range of :math:`[-1,1]` should
|
||||
be automatically subdivided in to the provided value for the bin.
|
||||
That is, the above example of five equi-width bins spanning
|
||||
:math:`[-1,1]` can be instead written as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="mu" bins="5" />
|
||||
|
||||
:polar:
|
||||
A monotonically increasing list of bounding particle polar angles
|
||||
which represents a portion of the possible values of :math:`[0,\pi]`.
|
||||
For example, spanning all of :math:`[0,\pi]` with five equi-width
|
||||
bins can be specified as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="polar" bins="0.0 0.6283 1.2566 1.8850 2.5132 3.1416"/>
|
||||
|
||||
Alternatively, if only one value is provided as a bin, OpenMC will
|
||||
interpret this to mean the complete range of :math:`[0,\pi]` should
|
||||
be automatically subdivided in to the provided value for the bin.
|
||||
That is, the above example of five equi-width bins spanning
|
||||
:math:`[0,\pi]` can be instead written as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="polar" bins="5" />
|
||||
|
||||
:azimuthal:
|
||||
A monotonically increasing list of bounding particle azimuthal angles
|
||||
which represents a portion of the possible values of :math:`[-\pi,\pi)`.
|
||||
For example, spanning all of :math:`[-\pi,\pi)` with two equi-width
|
||||
bins can be specified as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="azimuthal" bins="0.0 3.1416 6.2832" />
|
||||
|
||||
Alternatively, if only one value is provided as a bin, OpenMC will
|
||||
interpret this to mean the complete range of :math:`[-\pi,\pi)` should
|
||||
be automatically subdivided in to the provided value for the bin.
|
||||
That is, the above example of five equi-width bins spanning
|
||||
:math:`[-\pi,\pi)` can be instead written as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="azimuthal" bins="2" />
|
||||
|
||||
:mesh:
|
||||
The unique ID of a structured mesh to be tallied over.
|
||||
|
||||
:distribcell:
|
||||
The single cell which should be tallied uniquely for all instances.
|
||||
|
||||
.. note:: The distribcell filter will take a single cell ID and will tally
|
||||
each unique occurrence of that cell separately. This filter will not
|
||||
accept more than one cell ID. It is not recommended to combine this
|
||||
filter with a cell or mesh filter.
|
||||
|
||||
:delayedgroup:
|
||||
A list of delayed neutron precursor groups for which the tally should
|
||||
be accumulated. For instance, to tally to all 6 delayed groups in the
|
||||
ENDF/B-VII.1 library the filter is specified as:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<filter type="delayedgroup" bins="1 2 3 4 5 6" />
|
||||
|
||||
:energyfunction:
|
||||
``energyfunction`` filters do not use the ``bins`` entry. Instead
|
||||
they use ``energy`` and ``y``.
|
||||
|
||||
:particle:
|
||||
A list of integers indicating the type of particles to tally ('neutron' = 1,
|
||||
'photon' = 2, 'electron' = 3, 'positron' = 4).
|
||||
|
||||
------------------
|
||||
``<mesh>`` Element
|
||||
------------------
|
||||
|
||||
If a structured mesh is desired as a filter for a tally, it must be specified in
|
||||
a separate element with the tag name ``<mesh>``. This element has the following
|
||||
attributes/sub-elements:
|
||||
|
||||
:type:
|
||||
The type of structured mesh. This can be either "regular" or "rectilinear".
|
||||
|
||||
:dimension:
|
||||
The number of mesh cells in each direction. (For regular mesh only.)
|
||||
|
||||
:lower_left:
|
||||
The lower-left corner of the structured mesh. If only two coordinates are
|
||||
given, it is assumed that the mesh is an x-y mesh. (For regular mesh only.)
|
||||
|
||||
:upper_right:
|
||||
The upper-right corner of the structured mesh. If only two coordinates are
|
||||
given, it is assumed that the mesh is an x-y mesh. (For regular mesh only.)
|
||||
|
||||
:width:
|
||||
The width of mesh cells in each direction. (For regular mesh only.)
|
||||
|
||||
:x_grid:
|
||||
The mesh divisions along the x-axis. (For rectilinear mesh only.)
|
||||
|
||||
:y_grid:
|
||||
The mesh divisions along the y-axis. (For rectilinear mesh only.)
|
||||
|
||||
:z_grid:
|
||||
The mesh divisions along the z-axis. (For rectilinear mesh only.)
|
||||
|
||||
.. note::
|
||||
One of ``<upper_right>`` or ``<width>`` must be specified, but not both
|
||||
(even if they are consistent with one another).
|
||||
|
||||
------------------------
|
||||
``<derivative>`` Element
|
||||
------------------------
|
||||
|
||||
OpenMC can take the first-order derivative of many tallies with respect to
|
||||
material perturbations. It works by propagating a derivative through the
|
||||
transport equation. Essentially, OpenMC keeps track of how each particle's
|
||||
weight would change as materials are perturbed, and then accounts for that
|
||||
weight change in the tallies. Note that this assumes material perturbations are
|
||||
small enough not to change the distribution of fission sites. This element has
|
||||
the following attributes/sub-elements:
|
||||
|
||||
:id:
|
||||
A unique integer that can be used to identify the derivative.
|
||||
|
||||
:variable:
|
||||
The independent variable of the derivative. Accepted options are "density",
|
||||
"nuclide_density", and "temperature". A "density" derivative will give the
|
||||
derivative with respect to the density of the material in [g / cm^3]. A
|
||||
"nuclide_density" derivative will give the derivative with respect to the
|
||||
density of a particular nuclide in units of [atom / b / cm]. A
|
||||
"temperature" derivative is with respect to a material temperature in units
|
||||
of [K]. The temperature derivative requires windowed multipole to be
|
||||
turned on. Note also that the temperature derivative only accounts for
|
||||
resolved resonance Doppler broadening. It does not account for thermal
|
||||
expansion, S(a, b) scattering, resonance scattering, or unresolved Doppler
|
||||
broadening.
|
||||
|
||||
:material:
|
||||
The perturbed material. (Necessary for all derivative types)
|
||||
|
||||
:nuclide:
|
||||
The perturbed nuclide. (Necessary only for "nuclide_density")
|
||||
|
||||
-----------------------------
|
||||
``<assume_separate>`` Element
|
||||
-----------------------------
|
||||
|
||||
In cases where the user needs to specify many different tallies each of which
|
||||
are spatially separate, this tag can be used to cut down on some of the tally
|
||||
overhead. The effect of assuming all tallies are spatially separate is that once
|
||||
one tally is scored to, the same event is assumed not to score to any other
|
||||
tallies. This element should be followed by "true" or "false".
|
||||
|
||||
.. warning:: If used incorrectly, the assumption that all tallies are
|
||||
spatially separate can lead to incorrect results.
|
||||
|
||||
*Default*: false
|
||||
21
docs/source/io_formats/track.rst
Normal file
21
docs/source/io_formats/track.rst
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
.. _io_track:
|
||||
|
||||
=================
|
||||
Track File Format
|
||||
=================
|
||||
|
||||
The current revision of the particle track file format is 2.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the track
|
||||
file format.
|
||||
- **n_particles** (*int*) -- Number of particles for which tracks
|
||||
are recorded.
|
||||
- **n_coords** (*int[]*) -- Number of coordinates for each
|
||||
particle.
|
||||
|
||||
:Datasets:
|
||||
- **coordinates_<i>** (*double[][3]*) -- (x,y,z) coordinates for the
|
||||
*i*-th particle.
|
||||
34
docs/source/io_formats/volume.rst
Normal file
34
docs/source/io_formats/volume.rst
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
.. _io_volume:
|
||||
|
||||
==================
|
||||
Volume File Format
|
||||
==================
|
||||
|
||||
The current version of the volume file format is 1.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the summary
|
||||
file format.
|
||||
- **openmc_version** (*int[3]*) -- Major, minor, and release
|
||||
version number for OpenMC.
|
||||
- **git_sha1** (*char[40]*) -- Git commit SHA-1 hash.
|
||||
- **date_and_time** (*char[]*) -- Date and time the summary was
|
||||
written.
|
||||
- **domain_type** (*char[]*) -- The type of domain for which
|
||||
volumes are calculated, either 'cell', 'material', or 'universe'.
|
||||
- **samples** (*int*) -- Number of samples
|
||||
- **lower_left** (*double[3]*) -- Lower-left coordinates of
|
||||
bounding box
|
||||
- **upper_right** (*double[3]*) -- Upper-right coordinates of
|
||||
bounding box
|
||||
|
||||
**/domain_<id>/**
|
||||
|
||||
:Datasets: - **volume** (*double[2]*) -- Calculated volume and its uncertainty
|
||||
in cubic centimeters
|
||||
- **nuclides** (*char[][]*) -- Names of nuclides identified in the
|
||||
domain
|
||||
- **atoms** (*double[][2]*) -- Total number of atoms of each nuclide
|
||||
and its uncertainty
|
||||
27
docs/source/io_formats/voxel.rst
Normal file
27
docs/source/io_formats/voxel.rst
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
.. _io_voxel:
|
||||
|
||||
======================
|
||||
Voxel Plot File Format
|
||||
======================
|
||||
|
||||
The current version of the voxel file format is 1.0.
|
||||
|
||||
**/**
|
||||
|
||||
:Attributes: - **filetype** (*char[]*) -- String indicating the type of file.
|
||||
- **version** (*int[2]*) -- Major and minor version of the voxel
|
||||
file format.
|
||||
- **openmc_version** (*int[3]*) -- Major, minor, and release
|
||||
version number for OpenMC.
|
||||
- **git_sha1** (*char[40]*) -- Git commit SHA-1 hash.
|
||||
- **date_and_time** (*char[]*) -- Date and time the summary was
|
||||
written.
|
||||
- **num_voxels** (*int[3]*) -- Number of voxels in the x-, y-, and
|
||||
z- directions.
|
||||
- **voxel_width** (*double[3]*) -- Width of a voxel in centimeters.
|
||||
- **lower_left** (*double[3]*) -- Cartesian coordinates of the
|
||||
lower-left corner of the plot.
|
||||
|
||||
:Datasets:
|
||||
- **data** (*int[][][]*) -- Data for each voxel that represents a
|
||||
material or cell ID.
|
||||
24
docs/source/license.rst
Normal file
24
docs/source/license.rst
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
.. _license:
|
||||
|
||||
=================
|
||||
License Agreement
|
||||
=================
|
||||
|
||||
Copyright © 2011-2019 Massachusetts Institute of Technology and OpenMC contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
|
||||
the Software, and to permit persons to whom the Software is furnished to do so,
|
||||
subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
|
||||
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
|
||||
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
|
||||
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
||||
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
569
docs/source/methods/cmfd.rst
Normal file
569
docs/source/methods/cmfd.rst
Normal file
|
|
@ -0,0 +1,569 @@
|
|||
.. _methods_cmfd:
|
||||
|
||||
================================================================
|
||||
Nonlinear Diffusion Acceleration - Coarse Mesh Finite Difference
|
||||
================================================================
|
||||
|
||||
This page section discusses how nonlinear diffusion acceleration (NDA) using
|
||||
coarse mesh finite difference (CMFD) is implemented into OpenMC. Before we get
|
||||
into the theory, general notation for this section is discussed.
|
||||
|
||||
Note that the methods discussed in this section are written specifically for
|
||||
continuous-energy mode but equivalent apply to the multi-group mode if the
|
||||
particle's energy is replaced with the particle's group
|
||||
|
||||
--------
|
||||
Notation
|
||||
--------
|
||||
|
||||
Before deriving NDA relationships, notation is explained. If a parameter has a
|
||||
:math:`\overline{\cdot}`, it is surface area-averaged and if it has a
|
||||
:math:`\overline{\overline\cdot}`, it is volume-averaged. When describing a
|
||||
specific cell in the geometry, indices :math:`(i,j,k)` are used which correspond
|
||||
to directions :math:`(x,y,z)`. In most cases, the same operation is performed in
|
||||
all three directions. To compactly write this, an arbitrary direction set
|
||||
:math:`(u,v,w)` that corresponds to cell indices :math:`(l,m,n)` is used. Note
|
||||
that :math:`u` and :math:`l` do not have to correspond to :math:`x` and
|
||||
:math:`i`. However, if :math:`u` and :math:`l` correspond to :math:`y` and
|
||||
:math:`j`, :math:`v` and :math:`w` correspond to :math:`x` and :math:`z`
|
||||
directions. An example of this is shown in the following expression:
|
||||
|
||||
.. math::
|
||||
:label: not1
|
||||
|
||||
\sum\limits_{u\in(x,y,z)}\left\langle\overline{J}^{u,g}_{l+1/2,m,n}
|
||||
\Delta_m^v\Delta_n^w\right\rangle
|
||||
|
||||
Here, :math:`u` takes on each direction one at a time. The parameter :math:`J`
|
||||
is surface area-averaged over the transverse indices :math:`m` and :math:`n`
|
||||
located at :math:`l+1/2`. Usually, spatial indices are listed as subscripts and
|
||||
the direction as a superscript. Energy group indices represented by :math:`g`
|
||||
and :math:`h` are also listed as superscripts here. The group :math:`g` is the
|
||||
group of interest and, if present, :math:`h` is all groups. Finally, any
|
||||
parameter surrounded by :math:`\left\langle\cdot\right\rangle` represents a
|
||||
tally quantity that can be edited from a Monte Carlo (MC) solution.
|
||||
|
||||
------
|
||||
Theory
|
||||
------
|
||||
|
||||
NDA is a diffusion model that has equivalent physics to a transport model. There
|
||||
are many different methods that can be classified as NDA. The CMFD method is a
|
||||
type of NDA that represents second order multigroup diffusion equations on a
|
||||
coarse spatial mesh. Whether a transport model or diffusion model is used to
|
||||
represent the distribution of neutrons, these models must satisfy the *neutron
|
||||
balance equation*. This balance is represented by the following formula for a
|
||||
specific energy group :math:`g` in cell :math:`(l,m,n)`:
|
||||
|
||||
.. math::
|
||||
:label: eq_neut_bal
|
||||
|
||||
\sum\limits_{u\in(x,y,z)}\left(\left\langle\overline{J}^{u,g}_{l+1/2,m,n}
|
||||
\Delta_m^v\Delta_n^w\right\rangle -
|
||||
\left\langle\overline{J}^{u,g}_{l-1/2,m,n}
|
||||
\Delta_m^v\Delta_n^w\right\rangle\right)
|
||||
+
|
||||
\left\langle\overline{\overline\Sigma}_{t_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle
|
||||
= \\
|
||||
\sum\limits_{h=1}^G\left\langle
|
||||
\overline{\overline{\nu_s\Sigma}}_{s_{l,m,n}}^{h\rightarrow
|
||||
g}\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w
|
||||
\right\rangle
|
||||
+
|
||||
\frac{1}{k_{eff}}\sum\limits_{h=1}^G
|
||||
\left\langle\overline{\overline{\nu_f\Sigma}}_{f_{l,m,n}}^{h\rightarrow
|
||||
g}\overline{\overline\phi}_{l,m,n}^h
|
||||
\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle.
|
||||
|
||||
In eq. :eq:`eq_neut_bal` the parameters are defined as:
|
||||
|
||||
* :math:`\left\langle\overline{J}^{u,g}_{l\pm
|
||||
1/2,m,n}\Delta_m^v\Delta_n^w\right\rangle` --- surface area-integrated net
|
||||
current over surface :math:`(l\pm 1/2,m,n)` with surface normal in direction
|
||||
:math:`u` in energy group :math:`g`. By dividing this quantity by the transverse
|
||||
area, :math:`\Delta_m^v\Delta_n^w`, the surface area-averaged net current can
|
||||
be computed.
|
||||
* :math:`\left\langle\overline{\overline\Sigma}_{t_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle`
|
||||
--- volume-integrated total reaction rate over energy group :math:`g`.
|
||||
* :math:`\left\langle\overline{\overline{\nu_s\Sigma}}_{s_{l,m,n}}^{h\rightarrow
|
||||
g}
|
||||
\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle`
|
||||
--- volume-integrated scattering production rate of neutrons that begin with
|
||||
energy in group :math:`h` and exit reaction in group :math:`g`. This reaction
|
||||
rate also includes the energy transfer of reactions (except fission) that
|
||||
produce multiple neutrons such as (n, 2n); hence, the need for :math:`\nu_s`
|
||||
to represent neutron multiplicity.
|
||||
* :math:`k_{eff}` --- core multiplication factor.
|
||||
* :math:`\left\langle\overline{\overline{\nu_f\Sigma}}_{f_{l,m,n}}^{h\rightarrow
|
||||
g}\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle`
|
||||
--- volume-integrated fission production rate of neutrons from fissions in
|
||||
group :math:`h` that exit in group :math:`g`.
|
||||
|
||||
Each quantity in :math:`\left\langle\cdot\right\rangle` represents a scalar value that
|
||||
is obtained from an MC tally. A good verification step when using an MC code is
|
||||
to make sure that tallies satisfy this balance equation within statistics. No
|
||||
NDA acceleration can be performed if the balance equation is not satisfied.
|
||||
|
||||
There are three major steps to consider when performing NDA: (1) calculation of
|
||||
macroscopic cross sections and nonlinear parameters, (2) solving an eigenvalue
|
||||
problem with a system of linear equations, and (3) modifying MC source
|
||||
distribution to align with the NDA solution on a chosen mesh. This process is
|
||||
illustrated as a flow chart below. After a batch of neutrons
|
||||
is simulated, NDA can take place. Each of the steps described above is described
|
||||
in detail in the following sections.
|
||||
|
||||
.. figure:: ../_images/cmfd_flow.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Flow chart of NDA process. Note "XS" is used for cross section and "DC" is
|
||||
used for diffusion coefficient.
|
||||
|
||||
Calculation of Macroscopic Cross Sections
|
||||
-----------------------------------------
|
||||
|
||||
A diffusion model needs macroscopic cross sections and diffusion coefficients to
|
||||
solve for multigroup fluxes. Cross sections are derived by conserving reaction
|
||||
rates predicted by MC tallies. From Eq. :eq:`eq_neut_bal`, total, scattering
|
||||
production and fission production macroscopic cross sections are needed. They are
|
||||
defined from MC tallies as follows:
|
||||
|
||||
.. math::
|
||||
:label: xs1
|
||||
|
||||
\overline{\overline\Sigma}_{t_{l,m,n}}^g \equiv
|
||||
\frac{\left\langle\overline{\overline\Sigma}_{t_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}
|
||||
{\left\langle\overline{\overline\phi}_{l,m,n}^g
|
||||
\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle},
|
||||
|
||||
.. math::
|
||||
:label: xs2
|
||||
|
||||
\overline{\overline{\nu_s\Sigma}}_{s_{l,m,n}}^{h\rightarrow g} \equiv
|
||||
\frac{\left\langle\overline{\overline{\nu_s\Sigma}}_{s_{l,m,n}}^{h\rightarrow
|
||||
g}\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}
|
||||
{\left\langle\overline{\overline\phi}_{l,m,n}^h
|
||||
\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}
|
||||
|
||||
and
|
||||
|
||||
.. math::
|
||||
:label: xs3
|
||||
|
||||
\overline{\overline{\nu_f\Sigma}}_{f_{l,m,n}}^{h\rightarrow g} \equiv
|
||||
\frac{\left\langle\overline{\overline{\nu_f\Sigma}}_{f_{l,m,n}}^{h\rightarrow
|
||||
g}\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}
|
||||
{\left\langle\overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}.
|
||||
|
||||
In order to fully conserve neutron balance, leakage rates also need to be
|
||||
preserved. In standard diffusion theory, leakage rates are represented by
|
||||
diffusion coefficients. Unfortunately, it is not easy in MC to calculate a
|
||||
single diffusion coefficient for a cell that describes leakage out of each
|
||||
surface. Luckily, it does not matter what definition of diffusion coefficient is
|
||||
used because nonlinear equivalence parameters will correct for this
|
||||
inconsistency. However, depending on the diffusion coefficient definition
|
||||
chosen, different convergence properties of NDA equations are observed.
|
||||
Here, we introduce a diffusion coefficient that is derived for a coarse energy
|
||||
transport reaction rate. This definition can easily be constructed from
|
||||
MC tallies provided that angular moments of scattering reaction rates can
|
||||
be obtained. The diffusion coefficient is defined as follows:
|
||||
|
||||
.. math::
|
||||
:label: eq_transD
|
||||
|
||||
\overline{\overline D}_{l,m,n}^g =
|
||||
\frac{\left\langle\overline{\overline\phi}_{l,m,n}^g
|
||||
\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle}{3
|
||||
\left\langle\overline{\overline\Sigma}_{tr_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g
|
||||
\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle},
|
||||
|
||||
where
|
||||
|
||||
.. math::
|
||||
:label: xs4
|
||||
|
||||
\left\langle\overline{\overline\Sigma}_{tr_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle
|
||||
=
|
||||
\left\langle\overline{\overline\Sigma}_{t_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle
|
||||
\\ -
|
||||
\left\langle\overline{\overline{\nu_s\Sigma}}_{s1_{l,m,n}}^g
|
||||
\overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle.
|
||||
|
||||
Note that the transport reaction rate is calculated from the total reaction rate
|
||||
reduced by the :math:`P_1` scattering production reaction rate. Equation :eq:`eq_transD`
|
||||
does not represent the best definition of diffusion coefficients from MC;
|
||||
however, it is very simple and usually fits into MC tally frameworks
|
||||
easily. Different methods to calculate more accurate diffusion coefficients can
|
||||
found in [Herman]_.
|
||||
|
||||
CMFD Equations
|
||||
--------------
|
||||
|
||||
The first part of this section is devoted to discussing second-order finite
|
||||
volume discretization of multigroup diffusion equations. This will be followed
|
||||
up by the formulation of CMFD equations that are used in this NDA
|
||||
scheme. When performing second-order finite volume discretization of the
|
||||
diffusion equation, we need information that relates current to flux. In this
|
||||
numerical scheme, each cell is coupled only to its direct neighbors. Therefore,
|
||||
only two types of coupling exist: (1) cell-to-cell coupling and (2)
|
||||
cell-to-boundary coupling. The derivation of this procedure is referred to as
|
||||
finite difference diffusion equations and can be found in literature such
|
||||
as [Hebert]_. These current/flux relationships are as follows:
|
||||
|
||||
* cell-to-cell coupling
|
||||
|
||||
.. math::
|
||||
:label: eq_cell_cell
|
||||
|
||||
\overline{J}^{u,g}_{l\pm1/2,m,n} = -\frac{2\overline{\overline
|
||||
D}_{l\pm1,m,n}^g\overline{\overline
|
||||
D}_{l,m,n}^g}{\overline{\overline D}_{l\pm1,m,n}^g\Delta_l^u +
|
||||
\overline{\overline
|
||||
D}_{l,m,n}^g\Delta_{l\pm1}^u}
|
||||
\left(\pm\overline{\overline{\phi}}_{l\pm1,m,n}^g\mp
|
||||
\overline{\overline{\phi}}_{l,m,n}^g\right),
|
||||
|
||||
* cell-to-boundary coupling
|
||||
|
||||
.. math::
|
||||
:label: eq_cell_bound
|
||||
|
||||
\overline{J}^{u,g}_{l\pm1/2,m,n} = \pm\frac{2\overline{\overline
|
||||
D}_{l,m,n}^g\left(1 -
|
||||
\beta_{l\pm1/2,m,n}^{u,g}\right)}{4\overline{\overline
|
||||
D}_{l,m,n}^g\left(1 + \beta_{l\pm1/2,m,n}^{u,g}\right) + \left(1 -
|
||||
\beta_{l\pm1/2,m,n}^{u,g}\right)\Delta_l^u}\overline{\overline{\phi}}_{l,m,n}^{g}.
|
||||
|
||||
In Eqs. :eq:`eq_cell_cell` and :eq:`eq_cell_bound`, the :math:`\pm` refers to
|
||||
left (:math:`-x`) or right (:math:`+x`) surface in the :math:`x` direction,
|
||||
back (:math:`-y`) or front (:math:`+y`) surface in the :math:`y` direction and
|
||||
bottom (:math:`-z`) or top (:math:`+z`) surface in the :math:`z` direction. For
|
||||
cell-to-boundary coupling, a general albedo, :math:`\beta_{l\pm1/2,m,n}^{u,g}`,
|
||||
is used. The albedo is defined as the ratio of incoming (:math:`-` superscript)
|
||||
to outgoing (:math:`+` superscript) partial current on any surface represented
|
||||
as
|
||||
|
||||
.. math::
|
||||
:label: eq_albedo
|
||||
|
||||
\beta_{l\pm1/2,m,n}^{u,g} =
|
||||
\frac{\overline{J}^{u,g-}_{l\pm1/2,m,n}}{\overline{J}^{u,g+}_{l\pm1/2,m,n}}.
|
||||
|
||||
Common boundary conditions are: vacuum (:math:`\beta=0`), reflective
|
||||
(:math:`\beta=1`) and zero flux (:math:`\beta=-1`). Both eq. :eq:`eq_cell_cell`
|
||||
and eq. :eq:`eq_cell_bound` can be written in this generic form,
|
||||
|
||||
.. math::
|
||||
:label: eq_dtilde
|
||||
|
||||
\overline{J}^{u,g}_{l\pm1/2,m,n} = \widetilde{D}_{l,m,n}^{u,g} \left(\dots\right).
|
||||
|
||||
The parameter :math:`\widetilde{D}_{l,m,n}^{u,g}` represents the linear
|
||||
coupling term between current and flux. These current relationships can be
|
||||
sustituted into eq. :eq:`eq_neut_bal` to produce a linear system of multigroup
|
||||
diffusion equations for each spatial cell and energy group. However, a solution
|
||||
to these equations is not consistent with a higher order transport solution
|
||||
unless equivalence factors are present. This is because both the diffusion
|
||||
approximation, governed by Fick's Law, and spatial trunction error will produce
|
||||
differences. Therefore, a nonlinear parameter,
|
||||
:math:`\widehat{D}_{l,m,n}^{u,g}`, is added to eqs. :eq:`eq_cell_cell` and
|
||||
:eq:`eq_cell_bound`. These equations are, respectively,
|
||||
|
||||
.. math::
|
||||
:label: eq_dhat_cell
|
||||
|
||||
\overline{J}^{u,g}_{l\pm1/2,m,n} = -\widetilde{D}_{l,m,n}^{u,g}
|
||||
\left(\pm\overline{\overline{\phi}}_{l\pm1,m,n}^g\mp
|
||||
\overline{\overline{\phi}}_{l,m,n}^g\right) + \widehat{D}_{l,m,n}^{u,g}
|
||||
\left(\overline{\overline{\phi}}_{l\pm1,m,n}^g +
|
||||
\overline{\overline{\phi}}_{l,m,n}^g\right)
|
||||
|
||||
and
|
||||
|
||||
.. math::
|
||||
:label: eq_dhat_bound
|
||||
|
||||
\overline{J}^{u,g}_{l\pm1/2,m,n} = \pm\widetilde{D}_{l,m,n}^{u,g}
|
||||
\overline{\overline{\phi}}_{l,m,n}^{g} + \widehat{D}_{l,m,n}^{u,g}
|
||||
\overline{\overline{\phi}}_{l,m,n}^{g}.
|
||||
|
||||
The only unknown in each of these equations is the equivalence parameter. The
|
||||
current, linear coupling term and flux can either be obtained or derived from
|
||||
MC tallies. Thus, it is called nonlinear because it is dependent on the flux
|
||||
which is updated on the next iteration.
|
||||
|
||||
Equations :eq:`eq_dhat_cell` and :eq:`eq_dhat_bound` can be substituted into
|
||||
eq. :eq:`eq_neut_bal` to create a linear system of equations that is consistent
|
||||
with transport physics. One example of this equation is written for an
|
||||
interior cell,
|
||||
|
||||
.. math::
|
||||
:label: eq_cmfd_sys
|
||||
|
||||
\sum_{u\in
|
||||
x,y,x}\frac{1}{\Delta_l^u}\left[\left(-\tilde{D}_{l-1/2,m,n}^{u,g} -
|
||||
\hat{D}_{l-1/2,m,n}^{u,g}\right)\overline{\overline{\phi}}_{l-1,m,n}^g\right.
|
||||
\\ + \left(\tilde{D}_{l-1/2,m,n}^{u,g} +
|
||||
\tilde{D}_{l+1/2,m,n}^{u,g} - \hat{D}_{l-1/2,m,n}^{u,g} +
|
||||
\hat{D}_{l+1/2,m,n}^{u,g}\right)\overline{\overline{\phi}}_{l,m,n}^g
|
||||
\\ +
|
||||
\left. \left(-\tilde{D}_{l+1/2,m,n}^{u,g} +
|
||||
\hat{D}_{l+1/2,m,n}^{u,g}\right)\overline{\overline{\phi}}_{l+1,m,n}^g
|
||||
\right] \\ +
|
||||
\overline{\overline\Sigma}_{t_{l,m,n}}^g\overline{\overline{\phi}}_{l,m,n}^g
|
||||
- \sum\limits_{h=1}^G\overline{\overline{\nu_s\Sigma}}^{h\rightarrow
|
||||
g}_{s_{l,m,n}}\overline{\overline{\phi}}_{l,m,n}^h =
|
||||
\frac{1}{k}\sum\limits_{h=1}^G\overline{\overline{\nu_f\Sigma}}^{h\rightarrow
|
||||
g}_{f_{l,m,n}}\overline{\overline{\phi}}_{l,m,n}^h.
|
||||
|
||||
It should be noted that before substitution, eq. :eq:`eq_neut_bal` was divided
|
||||
by the volume of the cell, :math:`\Delta_l^u\Delta_m^v\Delta_n^w`. Equation
|
||||
:eq:`eq_cmfd_sys` can be represented in operator form as
|
||||
|
||||
.. math::
|
||||
:label: eq_CMFDopers
|
||||
|
||||
\mathbb{M}\mathbf{\Phi} = \frac{1}{k}\mathbb{F}\mathbf{\Phi},
|
||||
|
||||
where :math:`\mathbb{M}` is the neutron loss matrix operator,
|
||||
:math:`\mathbb{F}` is the neutron production matrix operator,
|
||||
:math:`\mathbf{\Phi}` is the multigroup flux vector and :math:`k` is the
|
||||
eigenvalue. This generalized eigenvalue problem is solved to obtain fundamental
|
||||
mode multigroup fluxes and eigenvalue. In order to produce consistent results
|
||||
with transport theory from these equations, the neutron balance equation must
|
||||
have been satisfied by MC tallies. The desire is that CMFD equations will
|
||||
produce a more accurate source than MC after each fission source generation.
|
||||
|
||||
CMFD Feedback
|
||||
-------------
|
||||
|
||||
Now that a more accurate representation of the expected source distribution is
|
||||
estimated from CMFD, it needs to be communicated back to MC. The first step
|
||||
in this process is to generate a probability mass function that provides
|
||||
information about how probable it is for a neutron to be born in a given cell
|
||||
and energy group. This is represented as
|
||||
|
||||
.. math::
|
||||
:label: eq_cmfd_psrc
|
||||
|
||||
p_{l,m,n}^g =
|
||||
\frac{\sum_{h=1}^{G}\overline{\overline{\nu_f\Sigma}}^{h\rightarrow
|
||||
g}_{f_{l,m,n}}\overline{\overline{\phi}}_{l,m,n}^h\Delta_l^u\Delta_m^v
|
||||
\Delta_n^w}{\sum_n\sum_m\sum_l\sum_{h=1}^{G}\overline{
|
||||
\overline{\nu_f\Sigma}}^{h\rightarrow
|
||||
g}_{f_{l,m,n}}\overline{\overline{\phi}}_{l,m,n}^h\Delta_l^u\Delta_m^v
|
||||
\Delta_n^w}.
|
||||
|
||||
This equation can be multiplied by the number of source neutrons to obtain an
|
||||
estimate of the expected number of neutrons to be born in a given cell and
|
||||
energy group. This distribution can be compared to the MC source distribution
|
||||
to generate weight adjusted factors defined as
|
||||
|
||||
.. math::
|
||||
:label: eq_waf
|
||||
|
||||
f_{l,m,n}^g = \frac{Np_{l,m,n}^g}{\sum\limits_s w_s};\quad s\in
|
||||
\left(g,l,m,n\right).
|
||||
|
||||
The MC source distribution is represented on the same coarse mesh as
|
||||
CMFD by summing all neutrons' weights, :math:`w_s`, in a given cell and
|
||||
energy group. MC source weights can then be modified by this weight
|
||||
adjustment factor so that it matches the CMFD solution on the coarse
|
||||
mesh,
|
||||
|
||||
.. math::
|
||||
:label: src_mod
|
||||
|
||||
w^\prime_s = w_s\times f_{l,m,n}^g;\quad s\in \left(g,l,m,n\right).
|
||||
|
||||
It should be noted that heterogeneous information about local coordinates and
|
||||
energy remain constant throughout this modification process.
|
||||
|
||||
------------------------
|
||||
Implementation in OpenMC
|
||||
------------------------
|
||||
|
||||
The section describes how CMFD was implemented in OpenMC. Before the simulation
|
||||
begins, a user sets up a CMFD input file that contains the following basic
|
||||
information:
|
||||
|
||||
* CMFD mesh (space and energy),
|
||||
* boundary conditions at edge of mesh (albedos),
|
||||
* acceleration region (subset of mesh, optional),
|
||||
* fission source generation (FSG)/batch that CMFD should begin, and
|
||||
* whether CMFD feedback should be applied.
|
||||
|
||||
It should be noted that for more difficult simulations (e.g., light water
|
||||
reactors), there are other options available to users such as tally resetting
|
||||
parameters, effective down-scatter usage, tally estimator, etc. For more
|
||||
information please see the :class:`openmc.cmfd.CMFDRun` class.
|
||||
|
||||
Of the options described above, the optional acceleration subset region is an
|
||||
uncommon feature. Because OpenMC only has a structured Cartesian mesh, mesh
|
||||
cells may overlay regions that don't contain fissionable material and may be so
|
||||
far from the core that the neutron flux is very low. If these regions were
|
||||
included in the CMFD solution, bad estimates of diffusion parameters may result
|
||||
and affect CMFD feedback. To deal with this, a user can carve out an active
|
||||
acceleration region from their structured Cartesian mesh. This is illustrated
|
||||
in diagram below. When placing a CMFD mesh over a geometry, the boundary
|
||||
conditions must be known at the global edges of the mesh. If the geometry is
|
||||
complex like the one below, one may have to cover the whole geometry including
|
||||
the reactor pressure vessel because we know that there is a zero incoming
|
||||
current boundary condition at the outer edge of the pressure vessel. This is
|
||||
not viable in practice because neutrons in simulations may not reach mesh cells
|
||||
that are near the pressure vessel. To circumvent this, one can shrink the mesh
|
||||
to cover just the core region as shown in the diagram. However, one must still
|
||||
estimate the boundary conditions at the global boundaries, but at these
|
||||
locations, they are not readily known. In OpenMC, one can carve out the active
|
||||
core region from the entire structured Cartesian mesh. This is shown in the
|
||||
diagram below by the darkened region over the core. The albedo boundary
|
||||
conditions at the active core/reflector boundary can be tallied indirectly
|
||||
during the MC simulation with incoming and outgoing partial currents. This
|
||||
allows the user to not have to worry about neutrons producing adequate tallies
|
||||
in mesh cells far away from the core.
|
||||
|
||||
.. figure:: ../_images/meshfig.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Diagram of CMFD acceleration mesh
|
||||
|
||||
During an MC simulation, CMFD tallies are accumulated. The basic tallies needed
|
||||
are listed in Table :ref:`tab_tally`. Each tally is performed on a spatial and
|
||||
energy mesh basis. The surface area-integrated net current is tallied on every
|
||||
surface of the mesh. OpenMC tally objects are created by the CMFD code
|
||||
internally, and cross sections are calculated at each CMFD feedback iteration.
|
||||
The first CMFD iteration, controlled by the user, occurs just after tallies are
|
||||
communicated to the master processor. Once tallies are collapsed, cross
|
||||
sections, diffusion coefficients and equivalence parameters are calculated. This
|
||||
is performed only on the acceleration region if that option has been activated
|
||||
by the user. Once all diffusion parameters are calculated, CMFD matrices are
|
||||
formed where energy groups are the inner most iteration index. In OpenMC,
|
||||
compressed row storage sparse matrices are used due to the sparsity of CMFD
|
||||
operators. An example of this sparsity is shown for the 3-D BEAVRS model in
|
||||
figures :num:`fig-loss` and :num:`fig-prod` [BEAVRS]_. These matrices represent
|
||||
an assembly radial mesh, 24 cell mesh in the axial direction and two energy
|
||||
groups. The loss matrix is 99.92% sparse and the production matrix is 99.99%
|
||||
sparse. Although the loss matrix looks like it is tridiagonal, it is really a
|
||||
seven banded matrix with a block diagonal matrix for scattering. The production
|
||||
matrix is a :math:`2\times 2` block diagonal; however, zeros are present because
|
||||
no fission neutrons appear with energies in the thermal group.
|
||||
|
||||
.. _tab_tally:
|
||||
|
||||
.. table:: OpenMC CMFD tally list
|
||||
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| tally | score | filter |
|
||||
+============================================================================================+================+===========================+
|
||||
| \ :math:`\left\langle\overline{\overline\phi}_{l,m,n}^g | flux | mesh, energy |
|
||||
| \Delta_l^u\Delta_m^v\Delta_n^w\right\rangle` | | |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| \ :math:`\left\langle\overline{\overline\Sigma}_{t_{l,m,n}}^g | total | mesh, energy |
|
||||
| \overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle` | | |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| \ :math:`\left\langle\overline{\overline{\nu_s\Sigma}}_{s1_{l,m,n}}^g | nu-scatter-1 | mesh, energy |
|
||||
| \overline{\overline\phi}_{l,m,n}^g\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle` | | |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| \ :math:`\left\langle\overline{\overline{\nu_s\Sigma}}_{s_{l,m,n}}^{h\rightarrow g} | nu-scatter | mesh, energy, energyout |
|
||||
| \overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle` | | |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| \ :math:`\left\langle\overline{\overline{\nu_f\Sigma}}_{f_{l,m,n}}^{h\rightarrow g} | nu-fission | mesh, energy, energyout |
|
||||
| \overline{\overline\phi}_{l,m,n}^h\Delta_l^u\Delta_m^v\Delta_n^w\right\rangle` | | |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
| \ :math:`\left\langle\overline{J}^{u,g}_{l\pm 1/2,m,n}\Delta_m^v\Delta_n^w\right\rangle` | current | mesh, energy |
|
||||
+--------------------------------------------------------------------------------------------+----------------+---------------------------+
|
||||
|
||||
.. _fig-loss:
|
||||
|
||||
.. figure:: ../_images/loss.png
|
||||
:scale: 50
|
||||
|
||||
Sparsity of Neutron Loss Operator
|
||||
|
||||
.. _fig-prod:
|
||||
|
||||
.. figure:: ../_images/prod.png
|
||||
:scale: 50
|
||||
|
||||
Sparsity of Neutron Production Operator
|
||||
|
||||
To solve the eigenvalue problem with these matrices, different source iteration
|
||||
and linear solvers can be used. The most common source iteration solver used is
|
||||
standard power iteration as described in [Gill]_. To accelerate these source
|
||||
iterations, a Wielandt shift scheme can be used as discussed in [Park]_. PETSc
|
||||
solvers were first implemented to perform the linear solution in parallel that
|
||||
occurs once per source iteration. When using PETSc, different types of parallel
|
||||
linear solvers and preconditioners can be used. By default, OpenMC uses an
|
||||
incomplete LU preconditioner and a GMRES Krylov solver. After some initial
|
||||
studies of parallelization with PETSc, it was observed that because CMFD
|
||||
matrices are very sparse, solution times do not scale well. An additional
|
||||
Gauss-Seidel linear solver with Chebyshev acceleration was added that is
|
||||
similar to the one used for CMFD in CASMO [Rhodes]_ and [Smith]_. This solver
|
||||
was implemented with a custom section for two energy groups. Because energy
|
||||
group is the inner most index, a block diagonal is formed when using more than
|
||||
one group. For two groups, it is easy to invert this diagonal analytically
|
||||
inside the Gauss-Seidel iterative solver. For more than two groups, this
|
||||
analytic inversion can still be performed, but with more computational effort.
|
||||
A standard Gauss-Seidel solver is used for more than two groups.
|
||||
|
||||
Besides a power iteration, a Jacobian-free Newton-Krylov method was also
|
||||
implemented to obtain eigenvalue and multigroup fluxes as described in [Gill]_
|
||||
and [Knoll]_. This method is not the primary one used, but has gotten recent
|
||||
attention due to its coupling advantages to other physics such as thermal
|
||||
hydraulics. Once multigroup fluxes are obtained, a normalized fission source is
|
||||
calculated in the code using eq. :eq:`eq_cmfd_psrc` directly.
|
||||
|
||||
The next step in the process is to compute weight adjustment factors. These are
|
||||
calculated by taking the ratio of the expected number of neutrons from the CMFD
|
||||
source distribution to the current number of neutrons in each mesh. It is
|
||||
straightforward to compute the CMFD number of neutrons because it is the
|
||||
product between the total starting initial weight of neutrons and the CMFD
|
||||
normalized fission source distribution. To compute the number of neutrons from
|
||||
the current MC source, OpenMC sums the statistical
|
||||
weights of neutrons from the source bank on a given spatial and energy mesh.
|
||||
Once weight adjustment factors were calculated, each neutron's statistical
|
||||
weight in the source bank was modified according to its location and energy.
|
||||
Examples of CMFD simulations using OpenMC can be found in [HermanThesis]_.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. rubric:: References
|
||||
|
||||
.. [BEAVRS] Nick Horelik, Bryan Herman. *Benchmark for Evaluation And Verification of Reactor
|
||||
Simulations*. Massachusetts Institute of Technology, https://crpg.mit.edu/research/beavrs
|
||||
, 2013.
|
||||
|
||||
.. [Gill] Daniel F. Gill. *Newton-Krylov methods for the solution of the k-eigenvalue problem in
|
||||
multigroup neutronics calculations*. Ph.D. thesis, Pennsylvania State University, 2010.
|
||||
|
||||
.. [Hebert] Alain Hebert. *Applied reactor physics*. Presses Internationales Polytechnique,
|
||||
Montreal, 2009.
|
||||
|
||||
.. [Herman] Bryan R. Herman, Benoit Forget, Kord Smith, and Brian N. Aviles. Improved
|
||||
diffusion coefficients generated from Monte Carlo codes. In *Proceedings of M&C
|
||||
2013*, Sun Valley, ID, USA, May 5 - 9, 2013.
|
||||
|
||||
.. [HermanThesis] Bryan R. Herman. *Monte Carlo and Thermal Hydraulic Coupling using
|
||||
Low-Order Nonlinear Diffusion Acceleration*. Sc.D. thesis,
|
||||
Massachusetts Institute of Technology, 2014.
|
||||
|
||||
.. [Knoll] D.A. Knoll, H. Park, and C. Newman. *Acceleration of k-eigenvalue/criticality
|
||||
calculations using the Jacobian-free Newton-Krylov method*. Nuclear Science and
|
||||
Engineering, 167:133–140, 2011.
|
||||
|
||||
.. [Park] H. Park, D.A. Knoll, and C.K. Newman. *Nonlinear acceleration of transport
|
||||
criticality problems*. Nuclear Science and Engineering, 172:52–65, 2012.
|
||||
|
||||
.. [Rhodes] Joel Rhodes and Malte Edenius. *CASMO-4 --- A Fuel Assembly Burnup Program.
|
||||
User’s Manual*. Studsvik of America, ssp-09/443-u rev 0, proprietary edition, 2001.
|
||||
|
||||
.. [Smith] Kord S Smith and Joel D Rhodes III. *Full-core, 2-D, LWR core calculations with
|
||||
CASMO-4E*. In Proceedings of PHYSOR 2002, Seoul, Korea, October 7 - 10, 2002.
|
||||
280
docs/source/methods/cross_sections.rst
Normal file
280
docs/source/methods/cross_sections.rst
Normal file
|
|
@ -0,0 +1,280 @@
|
|||
.. _methods_cross_sections:
|
||||
|
||||
=============================
|
||||
Cross Section Representations
|
||||
=============================
|
||||
|
||||
----------------------
|
||||
Continuous-Energy Data
|
||||
----------------------
|
||||
|
||||
In OpenMC, the data governing the interaction of neutrons with various nuclei
|
||||
for continous-energy problems are represented using an HDF5 format that can be
|
||||
produced by converting files in the ACE format, which is used by MCNP_ and
|
||||
Serpent_. ACE-format data can be generated with the NJOY_ nuclear data
|
||||
processing system, which converts raw `ENDF/B data`_ into linearly-interpolable
|
||||
data as required by most Monte Carlo codes. Since ACE-format data can be
|
||||
converted into OpenMC's HDF5 format, it is possible to perform direct comparison
|
||||
of OpenMC with other codes using the same underlying nuclear data library.
|
||||
|
||||
The ACE format contains continuous-energy cross sections for the following types
|
||||
of reactions: elastic scattering, fission (or first-chance fission,
|
||||
second-chance fission, etc.), inelastic scattering, :math:`(n,xn)`,
|
||||
:math:`(n,\gamma)`, and various other absorption reactions. For those reactions
|
||||
with one or more neutrons in the exit channel, secondary angle and energy
|
||||
distributions may be provided. In addition, fissionable nuclides have total,
|
||||
prompt, and/or delayed :math:`\nu` as a function of energy and neutron precursor
|
||||
distributions. Many nuclides also have probability tables to be used for
|
||||
accurate treatment of self-shielding in the unresolved resonance range. For
|
||||
bound scatterers, separate tables with :math:`S(\alpha,\beta,T)` scattering law
|
||||
data can be used.
|
||||
|
||||
Energy Grid Methods
|
||||
-------------------
|
||||
|
||||
The method by which continuous-energy cross sections for each nuclide in a
|
||||
problem are stored as a function of energy can have a substantial effect on the
|
||||
performance of a Monte Carlo simulation. Since the ACE format is based on
|
||||
linearly-interpolable cross sections, each nuclide has cross sections tabulated
|
||||
over a wide range of energies. Some nuclides may only have a few points
|
||||
tabulated (e.g. H-1) whereas other nuclides may have hundreds or thousands of
|
||||
points tabulated (e.g. U-238).
|
||||
|
||||
At each collision, it is necessary to sample the probability of having a
|
||||
particular type of interaction whether it be elastic scattering, :math:`(n,2n)`,
|
||||
level inelastic scattering, etc. This requires looking up the microscopic cross
|
||||
sections for these reactions for each nuclide within the target material. Since
|
||||
each nuclide has a unique energy grid, it would be necessary to search for the
|
||||
appropriate index for each nuclide at every collision. This can become a very
|
||||
time-consuming process, especially if there are many nuclides in a problem as
|
||||
there would be for burnup calculations. Thus, there is a strong motive to
|
||||
implement a method of reducing the number of energy grid searches in order to
|
||||
speed up the calculation.
|
||||
|
||||
Logarithmic Mapping
|
||||
+++++++++++++++++++
|
||||
|
||||
To speed up energy grid searches, OpenMC uses a `logarithmic mapping technique`_
|
||||
to limit the range of energies that must be searched for each nuclide. The
|
||||
entire energy range is divided up into equal-lethargy segments, and the bounding
|
||||
energies of each segment are mapped to bounding indices on each of the nuclide
|
||||
energy grids. By default, OpenMC uses 8000 equal-lethargy segments as
|
||||
recommended by Brown.
|
||||
|
||||
Other Methods
|
||||
+++++++++++++
|
||||
|
||||
A good survey of other energy grid techniques, including unionized energy grids,
|
||||
can be found in a paper by Leppanen_.
|
||||
|
||||
.. _windowed_multipole:
|
||||
|
||||
Windowed Multipole Representation
|
||||
---------------------------------
|
||||
|
||||
In addition to the usual pointwise representation of cross sections, OpenMC
|
||||
offers support for a data format called windowed multipole (WMP). This data
|
||||
format requires less memory than pointwise cross sections, and it allows
|
||||
on-the-fly Doppler broadening to arbitrary temperature.
|
||||
|
||||
The multipole method was introduced by Hwang_ and the faster windowed multipole
|
||||
method by Josey_. In the multipole format, cross section resonances are
|
||||
represented by poles, :math:`p_j`, and residues, :math:`r_j`, in the complex
|
||||
plane. The 0K cross sections in the resolved resonance region can be computed
|
||||
by summing up a contribution from each pole:
|
||||
|
||||
.. math::
|
||||
\sigma(E, T=0\text{K}) = \frac{1}{E} \sum_j \text{Re} \left[
|
||||
\frac{i r_j}{\sqrt{E} - p_j} \right]
|
||||
|
||||
Assuming free-gas thermal motion, cross sections in the multipole form can be
|
||||
analytically Doppler broadened to give the form:
|
||||
|
||||
.. math::
|
||||
\sigma(E, T) = \frac{1}{2 E \sqrt{\xi}} \sum_j \text{Re} \left[r_j
|
||||
\sqrt{\pi} W_i(z) - \frac{r_j}{\sqrt{\pi}} C \left(\frac{p_j}{\sqrt{\xi}},
|
||||
\frac{u}{2 \sqrt{\xi}}\right)\right]
|
||||
.. math::
|
||||
W_i(z) = \frac{i}{\pi} \int_{-\infty}^\infty dt \frac{e^{-t^2}}{z - t}
|
||||
.. math::
|
||||
C \left(\frac{p_j}{\sqrt{\xi}},\frac{u}{2 \sqrt{\xi}}\right) =
|
||||
2p_j \int_0^\infty du' \frac{e^{-(u + u')^2/4\xi}}{p_j^2 - u'^2}
|
||||
.. math::
|
||||
z = \frac{\sqrt{E} - p_j}{2 \sqrt{\xi}}
|
||||
.. math::
|
||||
\xi = \frac{k_B T}{4 A}
|
||||
.. math::
|
||||
u = \sqrt{E}
|
||||
|
||||
where :math:`T` is the temperature of the resonant scatterer, :math:`k_B` is the
|
||||
Boltzmann constant, :math:`A` is the mass of the target nucleus. For
|
||||
:math:`E \gg k_b T/A`, the :math:`C` integral is approximately zero, simplifying
|
||||
the cross section to:
|
||||
|
||||
.. math::
|
||||
\sigma(E, T) = \frac{1}{2 E \sqrt{\xi}} \sum_j \text{Re} \left[i r_j
|
||||
\sqrt{\pi} W_i(z)\right]
|
||||
|
||||
The :math:`W_i` integral simplifies down to an analytic form. We define the
|
||||
Faddeeva function, :math:`W` as:
|
||||
|
||||
.. math::
|
||||
W(z) = e^{-z^2} \text{Erfc}(-iz)
|
||||
|
||||
Through this, the integral transforms as follows:
|
||||
|
||||
.. math::
|
||||
\text{Im} (z) > 0 : W_i(z) = W(z)
|
||||
.. math::
|
||||
\text{Im} (z) < 0 : W_i(z) = -W(z^*)^*
|
||||
|
||||
There are freely available algorithms_ to evaluate the Faddeeva function. For
|
||||
many nuclides, the Faddeeva function needs to be evaluated thousands of times to
|
||||
calculate a cross section. To mitigate that computational cost, the WMP method
|
||||
only evaluates poles within a certain energy "window" around the incident
|
||||
neutron energy and accounts for the effect of resonances outside that window
|
||||
with a polynomial fit. This polynomial fit is then broadened exactly. This
|
||||
exact broadening can make up for the removal of the :math:`C` integral, as
|
||||
typically at low energies, only curve fits are used.
|
||||
|
||||
Note that the implementation of WMP in OpenMC currently assumes that inelastic
|
||||
scattering does not occur in the resolved resonance region. This is usually,
|
||||
but not always the case. Future library versions may eliminate this issue.
|
||||
|
||||
The data format used by OpenMC to represent windowed multipole data is specified
|
||||
in :ref:`io_data_wmp` with a publicly available `WMP library`_.
|
||||
|
||||
.. _temperature_treatment:
|
||||
|
||||
Temperature Treatment
|
||||
---------------------
|
||||
|
||||
At the beginning of a simulation, OpenMC collects a list of all temperatures
|
||||
that are present in a model. It then uses this list to determine what cross
|
||||
sections to load. The data that is loaded depends on what temperature method has
|
||||
been selected. There are three methods available:
|
||||
|
||||
:Nearest: Cross sections are loaded only if they are within a specified
|
||||
tolerance of the actual temperatures in the model.
|
||||
|
||||
:Interpolation: Cross sections are loaded at temperatures that bound the actual
|
||||
temperatures in the model. During transport, cross sections for
|
||||
each material are calculated using statistical linear-linear
|
||||
interpolation between bounding temperature. Suppose cross
|
||||
sections are available at temperatures :math:`T_1, T_2, ...,
|
||||
T_n` and a material is assigned a temperature :math:`T` where
|
||||
:math:`T_i < T < T_{i+1}`. Statistical interpolation is applied
|
||||
as follows: a uniformly-distributed random number of the unit
|
||||
interval, :math:`\xi`, is sampled. If :math:`\xi < (T -
|
||||
T_i)/(T_{i+1} - T_i)`, then cross sections at temperature
|
||||
:math:`T_{i+1}` are used. Otherwise, cross sections at
|
||||
:math:`T_i` are used. This procedure is applied for pointwise
|
||||
cross sections in the resolved resonance range, unresolved
|
||||
resonance probability tables, and :math:`S(\alpha,\beta)`
|
||||
thermal scattering tables.
|
||||
|
||||
:Multipole: Resolved resonance cross sections are calculated on-the-fly using
|
||||
techniques/data described in :ref:`windowed_multipole`. Cross
|
||||
section data is loaded for a single temperature and is used in the
|
||||
unresolved resonance and fast energy ranges.
|
||||
|
||||
----------------
|
||||
Multi-Group Data
|
||||
----------------
|
||||
|
||||
The data governing the interaction of particles with various nuclei or materials
|
||||
are represented using a multi-group library format specific to the OpenMC code.
|
||||
The format is described in the :ref:`mgxs_lib_spec`. The data itself can be
|
||||
prepared via traditional paths or directly from a continuous-energy OpenMC
|
||||
calculation by use of the Python API as is shown in the
|
||||
:ref:`notebook_mg_mode_part_i` example notebook. This multi-group library
|
||||
consists of meta-data (such as the energy group structure) and multiple `xsdata`
|
||||
objects which contains the required microscopic or macroscopic multi-group data.
|
||||
|
||||
At a minimum, the library must contain the absorption cross section
|
||||
(:math:`\sigma_{a,g}`) and a scattering matrix. If the problem is an eigenvalue
|
||||
problem then all fissionable materials must also contain either a fission
|
||||
production matrix cross section (:math:`\nu\sigma_{f,g\rightarrow g'}`), or both
|
||||
the fission spectrum data (:math:`\chi_{g'}`) and a fission production cross
|
||||
section (:math:`\nu\sigma_{f,g}`), or, . The library must also contain the
|
||||
fission cross section (:math:`\sigma_{f,g}`) or the fission energy release cross
|
||||
section (:math:`\kappa\sigma_{f,g}`) if the associated tallies are required by
|
||||
the model using the library.
|
||||
|
||||
After a scattering collision, the outgoing particle experiences a change in both
|
||||
energy and angle. The probability of a particle resulting in a given outgoing
|
||||
energy group (`g'`) given a certain incoming energy group (`g`) is provided by
|
||||
the scattering matrix data. The angular information can be expressed either via
|
||||
Legendre expansion of the particle's change-in-angle (:math:`\mu`), a tabular
|
||||
representation of the probability distribution function of :math:`\mu`, or a
|
||||
histogram representation of the same PDF. The formats used to represent these
|
||||
are described in the :ref:`mgxs_lib_spec`.
|
||||
|
||||
Unlike the continuous-energy mode, the multi-group mode does not explicitly
|
||||
track particles produced from scattering multiplication (i.e., :math:`(n,xn)`)
|
||||
reactions. These are instead accounted for by adjusting the weight of the
|
||||
particle after the collision such that the correct total weight is maintained.
|
||||
The weight adjustment factor is optionally provided by the `multiplicity` data
|
||||
which is required to be provided in the form of a group-wise matrix. This data
|
||||
is provided as a group-wise matrix since the probability of producing multiple
|
||||
particles in a scattering reaction depends on both the incoming energy, `g`, and
|
||||
the sampled outgoing energy, `g'`. This data represents the average number of
|
||||
particles emitted from a scattering reaction, given a scattering reaction has
|
||||
occurred:
|
||||
|
||||
.. math::
|
||||
|
||||
multiplicity_{g \rightarrow g'} = \frac{\nu_{scatter}\sigma_{s,g \rightarrow g'}}{
|
||||
\sigma_{s,g \rightarrow g'}}
|
||||
|
||||
If this scattering multiplication information is not provided in the library
|
||||
then no weight adjustment will be performed. This is equivalent to neglecting
|
||||
any additional particles produced in scattering multiplication reactions.
|
||||
However, this assumption will result in a loss of accuracy since the total
|
||||
particle population would not be conserved. This reduction in accuracy due to
|
||||
the loss in particle conservation can be mitigated by reducing the absorption
|
||||
cross section as needed to maintain particle conservation. This adjustment can
|
||||
be done when generating the library, or by OpenMC. To have OpenMC perform the
|
||||
adjustment, the total cross section (:math:`\sigma_{t,g}`) must be provided.
|
||||
With this information, OpenMC will then adjust the absorption cross section as
|
||||
follows:
|
||||
|
||||
.. math::
|
||||
|
||||
\sigma_{a,g} = \sigma_{t,g} - \sum_{g'}\nu_{scatter}\sigma_{s,g \rightarrow g'}
|
||||
|
||||
The above method is the same as is usually done with most deterministic solvers.
|
||||
Note that this method is less accurate than using the scattering multiplication
|
||||
weight adjustment since simply reducing the absorption cross section does not
|
||||
include any information about the outgoing energy of the particles produced in
|
||||
these reactions.
|
||||
|
||||
All of the data discussed in this section can be provided to the code
|
||||
independent of the particle's direction of motion (i.e., isotropic), or the data
|
||||
can be provided as a tabular distribution of the polar and azimuthal particle
|
||||
direction angles. The isotropic representation is the most commonly used,
|
||||
however inaccuracies are to be expected especially near material interfaces
|
||||
where a material has a very large cross sections relative to the other material
|
||||
(as can be expected in the resonance range). The angular representation can be
|
||||
used to minimize this error.
|
||||
|
||||
Finally, the above options for representing the physics do not have to be
|
||||
consistent across the problem. The number of groups and the structure, however,
|
||||
does have to be consistent across the data sets. That is to say that each
|
||||
microscopic or macroscopic data set does not have to apply the same scattering
|
||||
expansion, treatment of multiplicity or angular representation of the cross
|
||||
sections. This allows flexibility for the model to use highly anisotropic
|
||||
scattering information in the water while the fuel can be simulated with linear
|
||||
or even isotropic scattering.
|
||||
|
||||
.. _logarithmic mapping technique:
|
||||
https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-14-24530.pdf
|
||||
.. _Hwang: http://www.ans.org/pubs/journals/nse/a_16381
|
||||
.. _Josey: https://doi.org/10.1016/j.jcp.2015.08.013
|
||||
.. _WMP Library: https://github.com/mit-crpg/WMP_Library
|
||||
.. _MCNP: http://mcnp.lanl.gov
|
||||
.. _Serpent: http://montecarlo.vtt.fi
|
||||
.. _NJOY: http://t2.lanl.gov/codes.shtml
|
||||
.. _ENDF/B data: http://www.nndc.bnl.gov/endf
|
||||
.. _Leppanen: https://doi.org/10.1016/j.anucene.2009.03.019
|
||||
.. _algorithms: http://ab-initio.mit.edu/wiki/index.php/Faddeeva_Package
|
||||
161
docs/source/methods/eigenvalue.rst
Normal file
161
docs/source/methods/eigenvalue.rst
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
.. _methods_eigenvalue:
|
||||
|
||||
=======================
|
||||
Eigenvalue Calculations
|
||||
=======================
|
||||
|
||||
An eigenvalue calculation, also referred to as a criticality calculation, is a
|
||||
transport simulation wherein the source of neutrons includes a fissionable
|
||||
material. Some common eigenvalue calculations include the simulation of nuclear
|
||||
reactors, spent fuel pools, nuclear weapons, and other fissile systems. The
|
||||
reason they are called *eigenvalue* calculations is that the transport equation
|
||||
becomes an eigenvalue equation if a fissionable source is present since then the
|
||||
source of neutrons will depend on the flux of neutrons itself. Eigenvalue
|
||||
simulations using Monte Carlo methods are becoming increasingly common with the
|
||||
advent of high-performance computing.
|
||||
|
||||
This section will explore the theory behind and implementation of eigenvalue
|
||||
calculations in a Monte Carlo code.
|
||||
|
||||
.. _method-successive-generations:
|
||||
|
||||
--------------------------------
|
||||
Method of Successive Generations
|
||||
--------------------------------
|
||||
|
||||
The method used to converge on the fission source distribution in an eigenvalue
|
||||
calculation, known as the method of successive generations, was first introduced
|
||||
by [Lieberoth]_. In this method, a finite number of neutron histories,
|
||||
:math:`N`, are tracked through their lifetime iteratively. If fission occurs,
|
||||
rather than tracking the resulting fission neutrons, the spatial coordinates of
|
||||
the fission site, the sampled outgoing energy and direction of the fission
|
||||
neutron, and the weight of the neutron are stored for use in the subsequent
|
||||
generation. In OpenMC, the array used for storing the fission site information
|
||||
is called the *fission bank*. At the end of each fission generation, :math:`N`
|
||||
source sites for the next generation must be randomly sampled from the :math:`M`
|
||||
fission sites that were stored to ensure that the neutron population does not
|
||||
grow exponentially. The sampled source sites are stored in an array called the
|
||||
*source bank* and can be retrieved during the subsequent generation.
|
||||
|
||||
It's important to recognize that in the method of successive generations, we
|
||||
must start with some assumption on how the fission source sites are distributed
|
||||
since the distribution is not known *a priori*. Typically, a user will make a
|
||||
guess as to what the distribution is -- this guess could be a uniform
|
||||
distribution over some region of the geometry or simply a point
|
||||
source. Fortunately, regardless of the choice of initial source distribution,
|
||||
the method is guaranteed to converge to the true source distribution. Until the
|
||||
source distribution converges, tallies should not be scored to since they will
|
||||
otherwise include contributions from an unconverged source distribution.
|
||||
|
||||
The method by which the fission source iterations are parallelized can have a
|
||||
large impact on the achievable parallel scaling. This topic is discussed at length
|
||||
in :ref:`fission-bank-algorithms`.
|
||||
|
||||
-------------------------
|
||||
Source Convergence Issues
|
||||
-------------------------
|
||||
|
||||
Diagnosing Convergence with Shannon Entropy
|
||||
-------------------------------------------
|
||||
|
||||
As discussed earlier, it is necessary to converge both :math:`k_{eff}` and the
|
||||
source distribution before any tallies can begin. Moreover, the convergence rate
|
||||
of the source distribution is in general slower than that of
|
||||
:math:`k_{eff}`. One should thus examine not only the convergence of
|
||||
:math:`k_{eff}` but also the convergence of the source distribution in order to
|
||||
make decisions on when to start active batches.
|
||||
|
||||
However, the representation of the source distribution makes it a bit more
|
||||
difficult to analyze its convergence. Since :math:`k_{eff}` is a scalar
|
||||
quantity, it is easy to simply look at a line plot of :math:`k_{eff}` versus the
|
||||
number of batches and this should give the user some idea about whether it has
|
||||
converged. On the other hand, the source distribution at any given batch is a
|
||||
finite set of coordinates in Euclidean space. In order to analyze the
|
||||
convergence, we would either need to use a method for assessing convergence of
|
||||
an N-dimensional quantity or transform our set of coordinates into a scalar
|
||||
metric. The latter approach has been developed considerably over the last decade
|
||||
and a method now commonly used in Monte Carlo eigenvalue calculations is to use
|
||||
a metric called the `Shannon entropy`_, a concept borrowed from information
|
||||
theory.
|
||||
|
||||
To compute the Shannon entropy of the source distribution, we first need to
|
||||
discretize the source distribution rather than having a set of coordinates in
|
||||
Euclidean space. This can be done by superimposing a structured mesh over the
|
||||
geometry (containing at least all fissionable materials). Then, the fraction of
|
||||
source sites that are present in each mesh element is counted:
|
||||
|
||||
.. math::
|
||||
:label: fraction-source
|
||||
|
||||
S_i = \frac{\text{Source sites in $i$-th mesh element}}{\text{Total number of
|
||||
source sites}}
|
||||
|
||||
The Shannon entropy is then computed as
|
||||
|
||||
.. math::
|
||||
:label: shannon-entropy
|
||||
|
||||
H = - \sum_{i=1}^N S_i \log_2 S_i
|
||||
|
||||
where :math:`N` is the number of mesh elements. With equation
|
||||
:eq:`shannon-entropy`, we now have a scalar metric that we can use to assess the
|
||||
convergence of the source distribution by observing line plots of the Shannon
|
||||
entropy versus the number of batches.
|
||||
|
||||
In recent years, researchers have started looking at ways of automatically
|
||||
assessing source convergence to relieve the burden on the user of having to look
|
||||
at plots of :math:`k_{eff}` and the Shannon entropy. A number of methods have
|
||||
been proposed (see e.g. [Romano]_, [Ueki]_), but each of these is not without
|
||||
problems.
|
||||
|
||||
---------------------------
|
||||
Uniform Fission Site Method
|
||||
---------------------------
|
||||
|
||||
Generally speaking, the variance of a Monte Carlo tally will be inversely
|
||||
proportional to the number of events that score to the tally. In a reactor
|
||||
problem, this implies that regions with low relative power density will have
|
||||
higher variance that regions with high relative power density. One method to
|
||||
circumvent the uneven distribution of relative errors is the uniform fission
|
||||
site (UFS) method introduced by [Sutton]_. In this method, the portion of the
|
||||
problem containing fissionable material is subdivided into a number of cells
|
||||
(typically using a structured mesh). Rather than producing
|
||||
|
||||
.. math::
|
||||
|
||||
m = \frac{w}{k} \frac{\nu\Sigma_f}{\Sigma_t}
|
||||
|
||||
fission sites at each collision where :math:`w` is the weight of the neutron,
|
||||
:math:`k` is the previous-generation estimate of the neutron multiplication
|
||||
factor, :math:`\nu\Sigma_f` is the neutron production cross section, and
|
||||
:math:`\Sigma_t` is the total cross section, in the UFS method we produce
|
||||
|
||||
.. math::
|
||||
|
||||
m_{UFS} = \frac{w}{k} \frac{\nu\Sigma_f}{\Sigma_t} \frac{v_i}{s_i}
|
||||
|
||||
fission sites at each collision where :math:`v_i` is the fraction of the total
|
||||
volume occupied by cell :math:`i` and :math:`s_i` is the fraction of the fission
|
||||
source contained in cell :math:`i`. To ensure that no bias is introduced, the
|
||||
weight of each fission site stored in the fission bank is :math:`s_i/v_i` rather
|
||||
than unity. By ensuring that the expected number of fission sites in each mesh
|
||||
cell is constant, the collision density across all cells, and hence the variance
|
||||
of tallies, is more uniform than it would be otherwise.
|
||||
|
||||
.. _Shannon entropy: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-06-3737.pdf
|
||||
|
||||
.. [Lieberoth] J. Lieberoth, "A Monte Carlo Technique to Solve the Static
|
||||
Eigenvalue Problem of the Boltzmann Transport Equation," *Nukleonik*, **11**,
|
||||
213-219 (1968).
|
||||
|
||||
.. [Romano] Paul K. Romano, "Application of the Stochastic Oscillator to Assess
|
||||
Source Convergence in Monte Carlo Criticality Calculations,"
|
||||
*Proc. International Conference on Mathematics, Computational Methods, and
|
||||
Reactor Physics*, Saratoga Springs, New York (2009).
|
||||
|
||||
.. [Sutton] Daniel J. Kelly, Thomas M. Sutton, and Stephen C. Wilson, "MC21
|
||||
Analysis of the Nuclear Energy Agency Monte Carlo Performance Benchmark
|
||||
Problem," *Proc. PHYSOR 2012*, Knoxville, Tennessee, Apr. 15--20 (2012).
|
||||
|
||||
.. [Ueki] Taro Ueki, "On-the-Fly Judgments of Monte Carlo Fission Source
|
||||
Convergence," *Trans. Am. Nucl. Soc.*, **98**, 512 (2008).
|
||||
149
docs/source/methods/energy_deposition.rst
Normal file
149
docs/source/methods/energy_deposition.rst
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
.. _methods_heating:
|
||||
|
||||
=============================
|
||||
Heating and Energy Deposition
|
||||
=============================
|
||||
|
||||
As particles traverse a problem, some portion of their energy is deposited at
|
||||
collision sites. This energy is deposited when charged particles, including
|
||||
electrons and recoil nuclei, undergo electromagnetic interactions with
|
||||
surrounding electons and ions. The information describing how much energy
|
||||
is deposited for a specific reaction is referred to as
|
||||
"heating numbers" and can be computed using a program like NJOY with the
|
||||
``heatr`` module.
|
||||
|
||||
These heating rate is the product of reaction-specific coefficients and
|
||||
a reaction cross section
|
||||
|
||||
.. math::
|
||||
|
||||
H(E) = \phi(E)\sum_i\rho_i\sum_rk_{i, r}(E),
|
||||
|
||||
and has units energy per time, typically eV / s.
|
||||
Here, :math:`k_{i, r}` are the KERMA (Kinetic Energy Release in Materials)
|
||||
[Mack97]_ coefficients for reaction :math:`r` of isotope :math:`i`.
|
||||
The KERMA coefficients have units energy :math:`\times` cross-section, e.g.
|
||||
eV-barn, and can be used much like a reaction cross section for the purpose
|
||||
of tallying energy deposition.
|
||||
|
||||
KERMA coefficients can be computed using the energy-balance method with
|
||||
a nuclear data processing code like NJOY, which performs the following
|
||||
iteration over all reactions :math:`r` for all isotopes :math:`i`
|
||||
requested
|
||||
|
||||
.. math::
|
||||
|
||||
k_{i, r}(E) = \left(E + Q_{i, r} - \bar{E}_{i, r, n}
|
||||
- \bar{E}_{i, r, \gamma}\right)\sigma_{i, r}(E),
|
||||
|
||||
removing the energy of neutral particles (neutrons and photons) that are
|
||||
transported away from the reaction site :math:`\bar{E}`, and the reaction
|
||||
:math:`Q` value.
|
||||
|
||||
-------
|
||||
Fission
|
||||
-------
|
||||
|
||||
During a fission event, there are potentially many secondary particles, and all
|
||||
must be considered. The total energy released in a fission event is typically
|
||||
broken up into the following categories:
|
||||
|
||||
- :math:`E_{fr}` - kinetic energy of fission fragments
|
||||
- :math:`E_{n,p}` - energy of prompt fission neutrons
|
||||
- :math:`E_{n,d}` - energy of delayed fission neutrons
|
||||
- :math:`E_{\gamma,p}` - energy of prompt fission photons
|
||||
- :math:`E_{\gamma,d}` - energy of delayed fission photons
|
||||
- :math:`E_{\beta}` - energy of released :math:`\beta` particles
|
||||
- :math:`E_{\nu}` - energy of neutrinos
|
||||
|
||||
These components are defined in MF=1,MT=458 data in a standard ENDF/B-6 formatted
|
||||
file. All these quantities may depend upon incident neutron energy,
|
||||
but this dependence is not shown to make the following demonstrations cleaner.
|
||||
As neutrinos scarcely interact with matter, the recoverable energy from
|
||||
fission is defined as
|
||||
|
||||
.. math::
|
||||
|
||||
E_r\equiv E_{fr} + E_{n,p} + E_{n, d} + E_{\gamma, p}
|
||||
+ E_{\gamma, d} + E_{\beta}
|
||||
|
||||
Furthermore, the energy of the secondary neutrons and photons is given as
|
||||
:math:`E_{n, p}` and :math:`E_{\gamma, p}`, respectively.
|
||||
|
||||
NJOY computes the fission KERMA coefficient using this energy-balance method to be
|
||||
|
||||
.. math::
|
||||
|
||||
k_{i, f}(E) = \left[E + Q(E) - \bar{E}(E)\right]\sigma_{i, f}(E)
|
||||
= \left[E_{fr} + E_{\gamma, p}\right]\sigma_{i, j}(E)
|
||||
|
||||
.. note::
|
||||
|
||||
The energy from delayed neutrons and photons and beta particles is intentionally
|
||||
left out from the NJOY calculations.
|
||||
|
||||
---------------------
|
||||
OpenMC Implementation
|
||||
---------------------
|
||||
|
||||
For fissile isotopes, OpenMC makes modifications to the heating reaction to
|
||||
include all relevant components of fission energy release. These modifications
|
||||
are made to the total heating reaction, MT=301. Breaking the total heating
|
||||
KERMA into a fission and non-fission section, one can write
|
||||
|
||||
.. math::
|
||||
|
||||
k_i(E) = k_{i, nf}(E) + \left[E_{fr}(E) + E_{\gamma, p}\right]\sigma_{i, f}(E)
|
||||
|
||||
OpenMC seeks to modify the total heating data to include energy from
|
||||
:math:`\beta` particles and, conditionally, delayed photons. This conditional
|
||||
inclusion depends on the simulation mode: neutron transport, or coupled
|
||||
neutron-photon transport. The heating due to fission is removed using MT=318
|
||||
data, and then re-built using the desired components of fission energy release
|
||||
from MF=1,MT=458 data.
|
||||
|
||||
Neutron Transport
|
||||
-----------------
|
||||
|
||||
For this case, OpenMC instructs ``heatr`` to produce heating coefficients
|
||||
assuming that energy from photons, :math:`E_{\gamma, p}` and
|
||||
:math:`E_{\gamma, d}`, is deposited at the fission site.
|
||||
Let :math:`N901` represent the total heating number returned from this ``heatr``
|
||||
run with :math:`N918` reflecting fission heating computed from NJOY.
|
||||
:math:`M901` represent the following modification
|
||||
|
||||
.. math::
|
||||
|
||||
M901_{i}(E)\equiv N901_{i}(E) - N918_{i}(E)
|
||||
+ \left[E_{i, fr} + E_{i, \beta} + E_{i, \gamma, p}
|
||||
+ E_{i, \gamma, d}\right]\sigma_{i, f}(E).
|
||||
|
||||
This modified heating data is stored as the MT=901 reaction and will be scored
|
||||
if ``heating-local`` is included in :attr:`openmc.Tally.scores`.
|
||||
|
||||
Coupled neutron-photon transport
|
||||
--------------------------------
|
||||
|
||||
Here, OpenMC instructs ``heatr`` to assume that energy from photons is not
|
||||
deposited locally. However, the definitions provided in the NJOY manual
|
||||
indicate that, regardless of this mode, the prompt photon energy is still
|
||||
included in :math:`k_{i, f}`, and therefore must be manually removed.
|
||||
Let :math:`N301` represent the total heating number returned from this
|
||||
``heatr`` run and :math:`M301` be
|
||||
|
||||
.. math::
|
||||
|
||||
M301_{i}(E)\equiv N301_{i}(E) - N318_{i}(E)
|
||||
+ \left[E_{i, fr}(E) + E_{i, \beta}(E)\right]\sigma_{i, f}(E).
|
||||
|
||||
This modified heating data is stored as the MT=301 reaction and will be scored
|
||||
if ``heating`` is included in :attr:`openmc.Tally.scores`.
|
||||
|
||||
----------
|
||||
References
|
||||
----------
|
||||
|
||||
.. [Mack97] Abdou, M.A., Maynard, C.W., and Wright, R.Q. MACK: computer
|
||||
program to calculate neutron energy release parameters (fluence-to-kerma
|
||||
factors) and multigroup neutron reaction cross sections from nuclear data
|
||||
in ENDF Format. Oak Ridge National Laboratory report ORNL-TM-3994.
|
||||
967
docs/source/methods/geometry.rst
Normal file
967
docs/source/methods/geometry.rst
Normal file
|
|
@ -0,0 +1,967 @@
|
|||
.. _methods_geometry:
|
||||
|
||||
========
|
||||
Geometry
|
||||
========
|
||||
|
||||
---------------------------
|
||||
Constructive Solid Geometry
|
||||
---------------------------
|
||||
|
||||
OpenMC uses a technique known as `constructive solid geometry`_ (CSG) to build
|
||||
arbitrarily complex three-dimensional models in Euclidean space. In a CSG model,
|
||||
every unique object is described as the union and/or intersection of
|
||||
*half-spaces* created by bounding `surfaces`_. Every surface divides all of
|
||||
space into exactly two half-spaces. We can mathematically define a surface as a
|
||||
collection of points that satisfy an equation of the form :math:`f(x,y,z) = 0`
|
||||
where :math:`f(x,y,z)` is a given function. All coordinates for which
|
||||
:math:`f(x,y,z) < 0` are referred to as the negative half-space (or simply the
|
||||
*negative side*) and coordinates for which :math:`f(x,y,z) > 0` are referred to
|
||||
as the positive half-space.
|
||||
|
||||
Let us take the example of a sphere centered at the point :math:`(x_0,y_0,z_0)`
|
||||
with radius :math:`R`. One would normally write the equation of the sphere as
|
||||
|
||||
.. math::
|
||||
:label: sphere-equation
|
||||
|
||||
(x - x_0)^2 + (y - y_0)^2 + (z - z_0)^2 = R^2
|
||||
|
||||
By subtracting the right-hand term from both sides of equation
|
||||
:eq:`sphere-equation`, we can then write the surface equation for the sphere:
|
||||
|
||||
.. math::
|
||||
:label: surface-equation-sphere
|
||||
|
||||
f(x,y,z) = (x - x_0)^2 + (y - y_0)^2 + (z - z_0)^2 - R^2 = 0
|
||||
|
||||
One can confirm that any point inside this sphere will correspond to
|
||||
:math:`f(x,y,z) < 0` and any point outside the sphere will correspond to
|
||||
:math:`f(x,y,z) > 0`.
|
||||
|
||||
In OpenMC, every surface defined by the user is assigned an integer to uniquely
|
||||
identify it. We can then refer to either of the two half-spaces created by a
|
||||
surface by a combination of the unique ID of the surface and a positive/negative
|
||||
sign. Figure :num:`fig-halfspace` shows an example of an ellipse with unique ID 1
|
||||
dividing space into two half-spaces.
|
||||
|
||||
.. _fig-halfspace:
|
||||
|
||||
.. figure:: ../_images/halfspace.svg
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Example of an ellipse and its associated half-spaces.
|
||||
|
||||
References to half-spaces created by surfaces are used to define regions of
|
||||
space of uniform composition, which are then assigned to *cells*. OpenMC allows
|
||||
regions to be defined using union, intersection, and complement operators. As in
|
||||
MCNP_, the intersection operator is implicit as doesn't need to be written in a
|
||||
region specification. A defined region is then associated with a material
|
||||
composition in a cell. Figure :num:`fig-union` shows an example of a cell region
|
||||
defined as the intersection of an ellipse and two planes.
|
||||
|
||||
.. _fig-union:
|
||||
|
||||
.. figure:: ../_images/union.svg
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
The shaded region represents a cell bounded by three surfaces.
|
||||
|
||||
The ability to form regions based on bounding quadratic surfaces enables OpenMC
|
||||
to model arbitrarily complex three-dimensional objects. In practice, one is
|
||||
limited only by the different surface types available in OpenMC. The following
|
||||
table lists the available surface types, the identifier used to specify them in
|
||||
input files, the corresponding surface equation, and the input parameters needed
|
||||
to fully define the surface.
|
||||
|
||||
.. table:: Surface types available in OpenMC.
|
||||
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Surface | Identifier | Equation | Parameters |
|
||||
+======================+============+==============================+=========================+
|
||||
| Plane perpendicular | x-plane | :math:`x - x_0 = 0` | :math:`x_0` |
|
||||
| to :math:`x`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Plane perpendicular | y-plane | :math:`y - y_0 = 0` | :math:`y_0` |
|
||||
| to :math:`y`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Plane perpendicular | z-plane | :math:`z - z_0 = 0` | :math:`z_0` |
|
||||
| to :math:`z`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Arbitrary plane | plane | :math:`Ax + By + Cz = D` | :math:`A\;B\;C\;D` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Infinite cylinder | x-cylinder | :math:`(y-y_0)^2 + (z-z_0)^2 | :math:`y_0\;z_0\;R` |
|
||||
| parallel to | | = R^2` | |
|
||||
| :math:`x`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Infinite cylinder | y-cylinder | :math:`(x-x_0)^2 + (z-z_0)^2 | :math:`x_0\;z_0\;R` |
|
||||
| parallel to | | = R^2` | |
|
||||
| :math:`y`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Infinite cylinder | z-cylinder | :math:`(x-x_0)^2 + (y-y_0)^2 | :math:`x_0\;y_0\;R` |
|
||||
| parallel to | | = R^2` | |
|
||||
| :math:`z`-axis | | | |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Sphere | sphere | :math:`(x-x_0)^2 + (y-y_0)^2 | :math:`x_0 \; y_0 \; |
|
||||
| | | + (z-z_0)^2 = R^2` | z_0 \; R` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Cone parallel to the | x-cone | :math:`(y-y_0)^2 + (z-z_0)^2 | :math:`x_0 \; y_0 \; |
|
||||
| :math:`x`-axis | | = R^2(x-x_0)^2` | z_0 \; R^2` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Cone parallel to the | y-cone | :math:`(x-x_0)^2 + (z-z_0)^2 | :math:`x_0 \; y_0 \; |
|
||||
| :math:`y`-axis | | = R^2(y-y_0)^2` | z_0 \; R^2` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| Cone parallel to the | z-cone | :math:`(x-x_0)^2 + (y-y_0)^2 | :math:`x_0 \; y_0 \; |
|
||||
| :math:`z`-axis | | = R^2(z-z_0)^2` | z_0 \; R^2` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
| General quadric | quadric | :math:`Ax^2 + By^2 + Cz^2 + | :math:`A \; B \; C \; D |
|
||||
| surface | | Dxy + Eyz + Fxz + Gx + Hy + | \; E \; F \; G \; H \; |
|
||||
| | | Jz + K` | J \; K` |
|
||||
+----------------------+------------+------------------------------+-------------------------+
|
||||
|
||||
.. _universes:
|
||||
|
||||
Universes
|
||||
---------
|
||||
|
||||
OpenMC supports universe-based geometry similar to the likes of MCNP_ and
|
||||
Serpent_. This capability enables user to model any identical repeated
|
||||
structures once and then fill them in various spots in the geometry. A
|
||||
prototypical example of a repeated structure would be a fuel pin within a fuel
|
||||
assembly or a fuel assembly within a core.
|
||||
|
||||
Each cell in OpenMC can either be filled with a normal material or with a
|
||||
universe. If the cell is filled with a universe, only the region of the universe
|
||||
that is within the defined boundaries of the parent cell will be present in the
|
||||
geometry. That is to say, even though a collection of cells in a universe may
|
||||
extend to infinity, not all of the universe will be "visible" in the geometry
|
||||
since it will be truncated by the boundaries of the cell that contains it.
|
||||
|
||||
When a cell is filled with a universe, it is possible to specify that the
|
||||
universe filling the cell should be rotated and translated. This is done through
|
||||
the ``rotation`` and ``translation`` attributes on a cell (note though that
|
||||
these can only be specified on a cell that is filled with another universe, not
|
||||
a material).
|
||||
|
||||
It is not necessary to use or assign universes in a geometry if there are no
|
||||
repeated structures. Any cell in the geometry that is not assigned to a
|
||||
specified universe is automatically part of the *base universe* whose
|
||||
coordinates are just the normal coordinates in Euclidean space.
|
||||
|
||||
Lattices
|
||||
--------
|
||||
|
||||
Often times, repeated structures in a geometry occur in a regular pattern such
|
||||
as a rectangular or hexagonal lattice. In such a case, it would be cumbersome
|
||||
for a user to have to define the boundaries of each of the cells to be filled
|
||||
with a universe. Thus, OpenMC provides a lattice capability similar to that used
|
||||
in MCNP_ and Serpent_.
|
||||
|
||||
The implementation of lattices is similar in principle to universes --- instead
|
||||
of a cell being filled with a universe, the user can specify that it is filled
|
||||
with a finite lattice. The lattice is then defined by a two-dimensional array of
|
||||
universes that are to fill each position in the lattice. A good example of the
|
||||
use of lattices and universes can be seen in the OpenMC model for the `Monte
|
||||
Carlo Performance benchmark`_.
|
||||
|
||||
------------------------------------------
|
||||
Computing the Distance to Nearest Boundary
|
||||
------------------------------------------
|
||||
|
||||
One of the most basic algorithms in any Monte Carlo code is determining the
|
||||
distance to the nearest surface within a cell. Since each cell is defined by
|
||||
the surfaces that bound it, if we compute the distance to all surfaces bounding
|
||||
a cell, we can determine the nearest one.
|
||||
|
||||
With the possibility of a particle having coordinates on multiple levels
|
||||
(universes) in a geometry, we must exercise care when calculating the distance
|
||||
to the nearest surface. Each different level of geometry has a set of boundaries
|
||||
with which the particle's direction of travel may intersect. Thus, it is
|
||||
necessary to check the distance to the surfaces bounding the cell in each
|
||||
level. This should be done starting the highest (most global) level going down
|
||||
to the lowest (most local) level. That ensures that if two surfaces on different
|
||||
levels are coincident, by default the one on the higher level will be selected
|
||||
as the nearest surface. Although they are not explicitly defined, it is also
|
||||
necessary to check the distance to surfaces representing lattice boundaries if a
|
||||
lattice exists on a given level.
|
||||
|
||||
The following procedure is used to calculate the distance to each bounding
|
||||
surface. Suppose we have a particle at :math:`(x_0,y_0,z_0)` traveling in the
|
||||
direction :math:`u_0,v_0,w_0`. To find the distance :math:`d` to a surface
|
||||
:math:`f(x,y,z) = 0`, we need to solve the equation:
|
||||
|
||||
.. math::
|
||||
:label: dist-to-boundary-1
|
||||
|
||||
f(x_0 + du_0, y_0 + dv_0, z_0 + dw_0) = 0
|
||||
|
||||
If no solutions to equation :eq:`dist-to-boundary-1` exist or the only solutions
|
||||
are complex, then the particle's direction of travel will not intersect the
|
||||
surface. If the solution to equation :eq:`dist-to-boundary-1` is negative, this
|
||||
means that the surface is "behind" the particle, i.e. if the particle continues
|
||||
traveling in its current direction, it will not hit the surface. The complete
|
||||
derivation for different types of surfaces used in OpenMC will be presented in
|
||||
the following sections.
|
||||
|
||||
Since :math:`f(x,y,z)` in general is quadratic in :math:`x`, :math:`y`, and
|
||||
:math:`z`, this implies that :math:`f(x_0 + du_0, y + dv_0, z + dw_0)` is
|
||||
quadratic in :math:`d`. Thus we expect at most two real solutions to
|
||||
:eq:`dist-to-boundary-1`. If no solutions to :eq:`dist-to-boundary-1` exist or
|
||||
the only solutions are complex, then the particle's direction of travel will not
|
||||
intersect the surface. If the solution to :eq:`dist-to-boundary-1` is negative,
|
||||
this means that the surface is "behind" the particle, i.e. if the particle
|
||||
continues traveling in its current direction, it will not hit the surface.
|
||||
|
||||
Once a distance has been computed to a surface, we need to check if it is closer
|
||||
than previously-computed distances to surfaces. Unfortunately, we cannot just
|
||||
use the minimum function because some of the calculated distances, which should
|
||||
be the same in theory (e.g. coincident surfaces), may be slightly different due
|
||||
to the use of floating-point arithmetic. Consequently, we should first check for
|
||||
floating-point equality of the current distance calculated and the minimum found
|
||||
thus far. This is done by checking if
|
||||
|
||||
.. math::
|
||||
:label: fp-distance
|
||||
|
||||
\frac{| d - d_{min} |}{d_{min}} < \epsilon
|
||||
|
||||
where :math:`d` is the distance to a surface just calculated, :math:`d_{min}` is
|
||||
the minimum distance found thus far, and :math:`\epsilon` is a small number. In
|
||||
OpenMC, this parameter is set to :math:`\epsilon = 10^{-14}` since all floating
|
||||
calculations are done on 8-byte floating point numbers.
|
||||
|
||||
Plane Perpendicular to an Axis
|
||||
------------------------------
|
||||
|
||||
The equation for a plane perpendicular to, for example, the x-axis is simply
|
||||
:math:`x - x_0 = 0`. As such, we need to solve :math:`x + du - x_0 = 0`. The
|
||||
solution for the distance is
|
||||
|
||||
.. math::
|
||||
:label: dist-xplane
|
||||
|
||||
d = \frac{x_0 - x}{u}
|
||||
|
||||
Note that if the particle's direction of flight is parallel to the x-axis,
|
||||
i.e. :math:`u = 0`, the distance to the surface will be infinity. While the
|
||||
example here was for a plane perpendicular to the x-axis, the same formula can
|
||||
be applied for the surfaces :math:`y = y_0` and :math:`z = z_0`.
|
||||
|
||||
Generic Plane
|
||||
-------------
|
||||
|
||||
The equation for a generic plane is :math:`Ax + By + Cz = D`. Thus, we need to
|
||||
solve the equation :math:`A(x + du) + B(y + dv) + C(z + dw) = D`. The solution
|
||||
to this equation for the distance is
|
||||
|
||||
.. math::
|
||||
:label: dist-plane
|
||||
|
||||
d = \frac{D - Ax - By - Cz}{Au + Bv + Cw}
|
||||
|
||||
Again, we need to check whether the denominator is zero. If so, this means that
|
||||
the particle's direction of flight is parallel to the plane and it will
|
||||
therefore never hit the plane.
|
||||
|
||||
.. _cylinder_distance:
|
||||
|
||||
Cylinder Parallel to an Axis
|
||||
----------------------------
|
||||
|
||||
The equation for a cylinder parallel to, for example, the x-axis is :math:`(y -
|
||||
y_0)^2 + (z - z_0)^2 = R^2`. Thus, we need to solve :math:`(y + dv - y_0)^2 +
|
||||
(z + dw - z_0)^2 = R^2`. Let us define :math:`\bar{y} = y - y_0` and
|
||||
:math:`\bar{z} = z - z_0`. We then have
|
||||
|
||||
.. math::
|
||||
:label: dist-xcylinder-1
|
||||
|
||||
(\bar{y} + dv)^2 + (\bar{z} + dw)^2 = R^2
|
||||
|
||||
Expanding equation :eq:`dist-xcylinder-1` and rearranging terms, we obtain
|
||||
|
||||
.. math::
|
||||
:label: dist-xcylinder-2
|
||||
|
||||
(v^2 + w^2) d^2 + 2 (\bar{y}v + \bar{z}w) d + (\bar{y}^2 + \bar{z}^2 - R^2)
|
||||
= 0
|
||||
|
||||
This is a quadratic equation for :math:`d`. To simplify notation, let us define
|
||||
:math:`a = v^2 + w^2`, :math:`k = \bar{y}v + \bar{z}w`, and :math:`c =
|
||||
\bar{y}^2 + \bar{z}^2 - R^2`. Thus, the distance is just the solution to
|
||||
:math:`ad^2 + 2kd + c = 0`:
|
||||
|
||||
.. math::
|
||||
:label: dist-xcylinder-3
|
||||
|
||||
d = \frac{-k \pm \sqrt{k^2 - ac}}{a}
|
||||
|
||||
A few conditions must be checked for. If :math:`a = 0`, this means the particle
|
||||
is parallel to the cylinder and will thus never intersect it. Also, if
|
||||
:math:`k^2 - ac < 0`, this means that both solutions to the quadratic are
|
||||
complex. In physical terms, this means that the ray along which the particle is
|
||||
traveling does not make any intersections with the cylinder.
|
||||
|
||||
If we do have intersections and :math:`c < 0`, this means that the particle is
|
||||
inside the cylinder. Thus, one solution should be positive and one should be
|
||||
negative. Clearly, the positive distance will occur when the sign on the
|
||||
square root of the discriminant is positive since :math:`a > 0`.
|
||||
|
||||
If we have intersections and :math:`c > 0` this means that the particle is
|
||||
outside the cylinder. Thus, the solutions to the quadratic are either both
|
||||
positive or both negative. If they are both positive, the smaller (closer) one
|
||||
will be the solution with a negative sign on the square root of the
|
||||
discriminant.
|
||||
|
||||
The same equations and logic here can be used for cylinders that are parallel to
|
||||
the y- or z-axis with appropriate substitution of constants.
|
||||
|
||||
Sphere
|
||||
------
|
||||
|
||||
The equation for a sphere is :math:`(x - x_0)^2 + (y - y_0)^2 + (z - z_0)^2 =
|
||||
R^2`. Thus, we need to solve the equation
|
||||
|
||||
.. math::
|
||||
:label: dist-sphere-1
|
||||
|
||||
(x + du - x_0)^2 + (y + dv - y_0)^2 + (z + dw - z_0)^2 = R^2
|
||||
|
||||
Let us define :math:`\bar{x} = x - x_0`, :math:`\bar{y} = y - y_0`, and
|
||||
:math:`\bar{z} = z - z_0`. We then have
|
||||
|
||||
.. math::
|
||||
:label: dist-sphere-2
|
||||
|
||||
(\bar{x} + du)^2 + (\bar{y} + dv)^2 + (\bar{z} - dw)^2 = R^2
|
||||
|
||||
Expanding equation :eq:`dist-sphere-2` and rearranging terms, we obtain
|
||||
|
||||
.. math::
|
||||
:label: dist-sphere-3
|
||||
|
||||
d^2 + 2 (\bar{x}u + \bar{y}v + \bar{z}w) d + (\bar{x}^2 + \bar{y}^2 +
|
||||
\bar{z}^2 - R^2) = 0
|
||||
|
||||
This is a quadratic equation for :math:`d`. To simplify notation, let us define
|
||||
:math:`k = \bar{x}u + \bar{y}v + \bar{z}w` and :math:`c = \bar{x}^2 +
|
||||
\bar{y}^2 + \bar{z}^2 - R^2`. Thus, the distance is just the solution to
|
||||
:math:`d^2 + 2kd + c = 0`:
|
||||
|
||||
.. math::
|
||||
:label: dist-sphere-4
|
||||
|
||||
d = -k \pm \sqrt{k^2 - c}
|
||||
|
||||
If the discriminant :math:`k^2 - c < 0`, this means that both solutions to the
|
||||
quadratic are complex. In physical terms, this means that the ray along which
|
||||
the particle is traveling does not make any intersections with the sphere.
|
||||
|
||||
If we do have intersections and :math:`c < 0`, this means that the particle is
|
||||
inside the sphere. Thus, one solution should be positive and one should be
|
||||
negative. The positive distance will occur when the sign on the square root of
|
||||
the discriminant is positive. If we have intersections but :math:`c > 0` this
|
||||
means that the particle is outside the sphere. The solutions to the quadratic
|
||||
will then be either both positive or both negative. If they are both positive,
|
||||
the smaller (closer) one will be the solution with a negative sign on the square
|
||||
root of the discriminant.
|
||||
|
||||
Cone Parallel to an Axis
|
||||
------------------------
|
||||
|
||||
The equation for a cone parallel to, for example, the x-axis is :math:`(y -
|
||||
y_0)^2 + (z - z_0)^2 = R^2(x - x_0)^2`. Thus, we need to solve :math:`(y + dv -
|
||||
y_0)^2 + (z + dw - z_0)^2 = R^2(x + du - x_0)^2`. Let us define :math:`\bar{x} =
|
||||
x - x_0`, :math:`\bar{y} = y - y_0`, and :math:`\bar{z} = z - z_0`. We then have
|
||||
|
||||
.. math::
|
||||
:label: dist-xcone-1
|
||||
|
||||
(\bar{y} + dv)^2 + (\bar{z} + dw)^2 = R^2(\bar{x} + du)^2
|
||||
|
||||
Expanding equation :eq:`dist-xcone-1` and rearranging terms, we obtain
|
||||
|
||||
.. math::
|
||||
:label: dist-xcone-2
|
||||
|
||||
(v^2 + w^2 - R^2u^2) d^2 + 2 (\bar{y}v + \bar{z}w - R^2\bar{x}u) d +
|
||||
(\bar{y}^2 + \bar{z}^2 - R^2\bar{x}^2) = 0
|
||||
|
||||
Defining the terms
|
||||
|
||||
.. math::
|
||||
:label: dist-xcone-terms
|
||||
|
||||
a = v^2 + w^2 - R^2u^2
|
||||
|
||||
k = \bar{y}v + \bar{z}w - R^2\bar{x}u
|
||||
|
||||
c = \bar{y}^2 + \bar{z}^2 - R^2\bar{x}^2
|
||||
|
||||
we then have the simple quadratic equation :math:`ad^2 + 2kd + c = 0` which can
|
||||
be solved as described in :ref:`cylinder_distance`.
|
||||
|
||||
General Quadric
|
||||
---------------
|
||||
|
||||
The equation for a general quadric surface is :math:`Ax^2 + By^2 + Cz^2 + Dxy +
|
||||
Eyz + Fxz + Gx + Hy + Jz + K = 0`. Thus, we need to solve the equation
|
||||
|
||||
.. math::
|
||||
:label: dist-quadric-1
|
||||
|
||||
A(x+du)^2 + B(y+dv)^2 + C(z+dw)^2 + D(x+du)(y+dv) + E(y+dv)(z+dw) + \\
|
||||
F(x+du)(z+dw) + G(x+du) + H(y+dv) + J(z+dw) + K = 0
|
||||
|
||||
Expanding equation :eq:`dist-quadric-1` and rearranging terms, we obtain
|
||||
|
||||
.. math::
|
||||
:label: dist-quadric-2
|
||||
|
||||
d^2(uv + vw + uw) + 2d(Aux + Bvy + Cwx + (D(uv + vx) + E(vz + wy) + \\
|
||||
F(wx + uz))/2) + (x(Ax + Dy) + y(By + Ez) + z(Cz + Fx)) = 0
|
||||
|
||||
Defining the terms
|
||||
|
||||
.. math::
|
||||
:label: dist-quadric-terms
|
||||
|
||||
a = uv + vw + uw
|
||||
|
||||
k = Aux + Bvy + Cwx + (D(uv + vx) + E(vz + wy) + F(wx + uz))/2
|
||||
|
||||
c = x(Ax + Dy) + y(By + Ez) + z(Cz + Fx)
|
||||
|
||||
we then have the simple quadratic equation :math:`ad^2 + 2kd + c = 0` which can
|
||||
be solved as described in :ref:`cylinder_distance`.
|
||||
|
||||
.. _find-cell:
|
||||
|
||||
----------------------------
|
||||
Finding a Cell Given a Point
|
||||
----------------------------
|
||||
|
||||
Another basic algorithm is to determine which cell contains a given point in the
|
||||
global coordinate system, i.e. if the particle's position is :math:`(x,y,z)`,
|
||||
what cell is it currently in. This is done in the following manner in
|
||||
OpenMC. With the possibility of multiple levels of coordinates, we must perform
|
||||
a recursive search for the cell. First, we start in the highest (most global)
|
||||
universe, which we call the base universe, and loop over each cell within
|
||||
that universe. For each cell, we check whether the specified point is inside the
|
||||
cell using the algorithm described in :ref:`cell-contains`. If the cell is
|
||||
filled with a normal material, the search is done and we have identified the
|
||||
cell containing the point. If the cell is filled with another universe, we then
|
||||
search all cells within that universe to see if any of them contain the
|
||||
specified point. If the cell is filled with a lattice, the position within the
|
||||
lattice is determined, and then whatever universe fills that lattice position is
|
||||
recursively searched. The search ends once a cell containing a normal material
|
||||
is found that contains the specified point.
|
||||
|
||||
.. _cell-contains:
|
||||
|
||||
----------------------
|
||||
Finding a Lattice Tile
|
||||
----------------------
|
||||
|
||||
If a particle is inside a lattice, its position inside the lattice must be
|
||||
determined before assigning it to a cell. Throughout this section, the
|
||||
volumetric units of the lattice will be referred to as "tiles". Tiles are
|
||||
identified by thier indices, and the process of discovering which tile contains
|
||||
the particle is referred to as "indexing".
|
||||
|
||||
Rectilinear Lattice Indexing
|
||||
----------------------------
|
||||
|
||||
Indices are assigned to tiles in a rectilinear lattice based on the tile's
|
||||
position along the :math:`x`, :math:`y`, and :math:`z` axes. Figure
|
||||
:num:`fig-rect-lat` maps the indices for a 2D lattice. The indices, (1, 1),
|
||||
map to the lower-left tile. (5, 1) and (5, 5) map to the lower-right and
|
||||
upper-right tiles, respectively.
|
||||
|
||||
.. _fig-rect-lat:
|
||||
|
||||
.. figure:: ../_images/rect_lat.svg
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
:width: 400px
|
||||
|
||||
Rectilinear lattice tile indices.
|
||||
|
||||
In general, a lattice tile is specified by the three indices,
|
||||
:math:`(i_x, i_y, i_z)`. If a particle's current coordinates are
|
||||
:math:`(x, y, z)` then the indices can be determined from these formulas:
|
||||
|
||||
.. math::
|
||||
:label: rect_indexing
|
||||
|
||||
i_x = \left \lceil \frac{x - x_0}{p_0} \right \rceil
|
||||
|
||||
i_y = \left \lceil \frac{y - y_0}{p_1} \right \rceil
|
||||
|
||||
i_z = \left \lceil \frac{z - z_0}{p_2} \right \rceil
|
||||
|
||||
where :math:`(x_0, y_0, z_0)` are the coordinates to the lower-left-bottom
|
||||
corner of the lattice, and :math:`p_0, p_1, p_2` are the pitches along the
|
||||
:math:`x`, :math:`y`, and :math:`z` axes, respectively.
|
||||
|
||||
.. _hexagonal_indexing:
|
||||
|
||||
Hexagonal Lattice Indexing
|
||||
--------------------------
|
||||
|
||||
A skewed coordinate system is used for indexing hexagonal lattice tiles.
|
||||
Rather than a :math:`y`-axis, another axis is used that is rotated 30 degrees
|
||||
counter-clockwise from the :math:`y`-axis. This axis is referred to as the
|
||||
:math:`\alpha`-axis. Figure :num:`fig-hex-lat` shows how 2D hexagonal tiles
|
||||
are mapped with the :math:`(x, \alpha)` basis. In this system, (0, 0) maps to
|
||||
the center tile, (0, 2) to the top tile, and (2, -1) to the middle tile on the
|
||||
right side.
|
||||
|
||||
.. _fig-hex-lat:
|
||||
|
||||
.. figure:: ../_images/hex_lat.svg
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
:width: 400px
|
||||
|
||||
Hexagonal lattice tile indices.
|
||||
|
||||
Unfortunately, the indices cannot be determined with one simple formula as
|
||||
before. Indexing requires a two-step process, a coarse step which determines a
|
||||
set of four tiles that contains the particle and a fine step that determines
|
||||
which of those four tiles actually contains the particle.
|
||||
|
||||
In the first step, indices are found using these formulas:
|
||||
|
||||
.. math::
|
||||
:label: hex_indexing
|
||||
|
||||
\alpha = -\frac{x}{\sqrt{3}} + y
|
||||
|
||||
i_x^* = \left \lfloor \frac{x}{p_0 \sqrt{3} / 2} \right \rfloor
|
||||
|
||||
i_\alpha^* = \left \lfloor \frac{\alpha}{p_0} \right \rfloor
|
||||
|
||||
where :math:`p_0` is the lattice pitch (in the :math:`x`-:math:`y` plane). The
|
||||
true index of the particle could be :math:`(i_x^*, i_\alpha^*)`,
|
||||
:math:`(i_x^* + 1, i_\alpha^*)`, :math:`(i_x^*, i_\alpha^* + 1)`, or
|
||||
:math:`(i_x^* + 1, i_\alpha^* + 1)`.
|
||||
|
||||
The second step selects the correct tile from that neighborhood of 4. OpenMC
|
||||
does this by calculating the distance between the particle and the centers of
|
||||
each of the 4 tiles, and then picking the closest tile. This works because
|
||||
regular hexagonal tiles form a Voronoi tessellation which means that all of the
|
||||
points within a tile are closest to the center of that same tile.
|
||||
|
||||
Indexing along the :math:`z`-axis uses the same method from rectilinear
|
||||
lattices, i.e.
|
||||
|
||||
.. math::
|
||||
:label: hex_indexing_z
|
||||
|
||||
i_z = \left \lceil \frac{z - z_0}{p_2} \right \rceil
|
||||
|
||||
----------------------------------------
|
||||
Determining if a Coordinate is in a Cell
|
||||
----------------------------------------
|
||||
|
||||
To determine which cell a particle is in given its coordinates, we need to be
|
||||
able to check whether a given cell contains a point. The algorithm for
|
||||
determining if a cell contains a point is as follows. For each surface that
|
||||
bounds a cell, we determine the particle's sense with respect to the surface. As
|
||||
explained earlier, if we have a point :math:`(x_0,y_0,z_0)` and a surface
|
||||
:math:`f(x,y,z) = 0`, the point is said to have negative sense if
|
||||
:math:`f(x_0,y_0,z_0) < 0` and positive sense if :math:`f(x_0,y_0,z_0) > 0`. If
|
||||
for all surfaces, the sense of the particle with respect to the surface matches
|
||||
the specified sense that defines the half-space within the cell, then the point
|
||||
is inside the cell. Note that this algorithm works only for *simple cells*
|
||||
defined as intersections of half-spaces.
|
||||
|
||||
It may help to illustrate this algorithm using a simple example. Let's say we
|
||||
have a cell defined as
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<surface id="1" type="sphere" coeffs="0 0 0 10" />
|
||||
<surface id="2" type="x-plane" coeffs="-3" />
|
||||
<surface id="3" type="y-plane" coeffs="2" />
|
||||
<cell id="1" surfaces="-1 2 -3" />
|
||||
|
||||
This means that the cell is defined as the intersection of the negative half
|
||||
space of a sphere, the positive half-space of an x-plane, and the negative
|
||||
half-space of a y-plane. Said another way, any point inside this cell must
|
||||
satisfy the following equations
|
||||
|
||||
.. math::
|
||||
:label: cell-contains-example
|
||||
|
||||
x^2 + y^2 + z^2 - 10^2 < 0 \\
|
||||
x - (-3) > 0 \\
|
||||
y - 2 < 0
|
||||
|
||||
In order to determine if a point is inside the cell, we would substitute its
|
||||
coordinates into equation :eq:`cell-contains-example`. If the inequalities are
|
||||
satisfied, than the point is indeed inside the cell.
|
||||
|
||||
--------------------------
|
||||
Handling Surface Crossings
|
||||
--------------------------
|
||||
|
||||
A particle will cross a surface if the distance to the nearest surface is closer
|
||||
than the distance sampled to the next collision. A number of things happen when
|
||||
a particle hits a surface. First, we need to check if a non-transmissive
|
||||
boundary condition has been applied to the surface. If a vacuum boundary
|
||||
condition has been applied, the particle is killed and any surface current
|
||||
tallies are scored to as needed. If a reflective boundary condition has been
|
||||
applied to the surface, surface current tallies are scored to and then the
|
||||
particle's direction is changed according to the procedure in :ref:`reflection`.
|
||||
Note that the white boundary condition can be considered as the special case of
|
||||
reflective boundary condition, where the same processing method will be applied to
|
||||
deal with the surface current tallies scoring, except for determining the
|
||||
changes of particle's direction according to the procedures in :ref:`white`.
|
||||
|
||||
Next, we need to determine what cell is beyond the surface in the direction of
|
||||
travel of the particle so that we can evaluate cross sections based on its
|
||||
material properties. At initialization, a list of neighboring cells is created
|
||||
for each surface in the problem as described in :ref:`neighbor-lists`. The
|
||||
algorithm outlined in :ref:`find-cell` is used to find a cell containing the
|
||||
particle with one minor modification; rather than searching all cells in the
|
||||
base universe, only the list of neighboring cells is searched. If this search is
|
||||
unsuccessful, then a search is done over every cell in the base universe.
|
||||
|
||||
.. _neighbor-lists:
|
||||
|
||||
-----------------------
|
||||
Building Neighbor Lists
|
||||
-----------------------
|
||||
|
||||
After the geometry has been loaded and stored in memory from an input file,
|
||||
OpenMC builds a list for each surface containing any cells that are bounded by
|
||||
that surface in order to speed up processing of surface crossings. The algorithm
|
||||
to build these lists is as follows. First, we loop over all cells in the
|
||||
geometry and count up how many times each surface appears in a specification as
|
||||
bounding a negative half-space and bounding a positive half-space. Two arrays
|
||||
are then allocated for each surface, one that lists each cell that contains the
|
||||
negative half-space of the surface and one that lists each cell that contains
|
||||
the positive half-space of the surface. Another loop is performed over all cells
|
||||
and the neighbor lists are populated for each surface.
|
||||
|
||||
.. _reflection:
|
||||
|
||||
------------------------------
|
||||
Reflective Boundary Conditions
|
||||
------------------------------
|
||||
|
||||
If the velocity of a particle is :math:`\mathbf{v}` and it crosses a surface of
|
||||
the form :math:`f(x,y,z) = 0` with a reflective boundary condition, it can be
|
||||
shown based on geometric arguments that the velocity vector will then become
|
||||
|
||||
.. math::
|
||||
:label: reflection-v
|
||||
|
||||
\mathbf{v'} = \mathbf{v} - 2 (\mathbf{v} \cdot \hat{\mathbf{n}})
|
||||
\hat{\mathbf{n}}
|
||||
|
||||
where :math:`\hat{\mathbf{n}}` is a unit vector normal to the surface at the
|
||||
point of the surface crossing. The rationale for this can be understood by
|
||||
noting that :math:`(\mathbf{v} \cdot \hat{\mathbf{n}}) \hat{\mathbf{n}}` is the
|
||||
projection of the velocity vector onto the normal vector. By subtracting two
|
||||
times this projection, the velocity is reflected with respect to the surface
|
||||
normal. Since the magnitude of the velocity of the particle will not change as
|
||||
it undergoes reflection, we can work with the direction of the particle instead,
|
||||
simplifying equation :eq:`reflection-v` to
|
||||
|
||||
.. math::
|
||||
:label: reflection-omega
|
||||
|
||||
\mathbf{\Omega'} = \mathbf{\Omega} - 2 (\mathbf{\Omega} \cdot
|
||||
\hat{\mathbf{n}}) \hat{\mathbf{n}}
|
||||
|
||||
where :math:`\mathbf{v} = || \mathbf{v} || \mathbf{\Omega}`. The direction of
|
||||
the surface normal will be the gradient of the surface at the point of crossing,
|
||||
i.e. :math:`\mathbf{n} = \nabla f(x,y,z)`. Substituting this into equation
|
||||
:eq:`reflection-omega`, we get
|
||||
|
||||
.. math::
|
||||
:label: reflection-omega-2
|
||||
|
||||
\mathbf{\Omega'} = \mathbf{\Omega} - \frac{2 ( \mathbf{\Omega} \cdot \nabla
|
||||
f )}{|| \nabla f ||^2} \nabla f
|
||||
|
||||
|
||||
If we write the initial and final directions in terms of their vector
|
||||
components, :math:`\mathbf{\Omega} = (u,v,w)` and :math:`\mathbf{\Omega'} = (u',
|
||||
v', w')`, this allows us to represent equation :eq:`reflection-omega` as a
|
||||
series of equations:
|
||||
|
||||
.. math::
|
||||
:label: reflection-system
|
||||
|
||||
u' = u - \frac{2 ( \mathbf{\Omega} \cdot \nabla f )}{|| \nabla f ||^2}
|
||||
\frac{\partial f}{\partial x} \\
|
||||
|
||||
v' = v - \frac{2 ( \mathbf{\Omega} \cdot \nabla f )}{|| \nabla f ||^2}
|
||||
\frac{\partial f}{\partial y} \\
|
||||
|
||||
w' = w - \frac{2 ( \mathbf{\Omega} \cdot \nabla f )}{|| \nabla f ||^2}
|
||||
\frac{\partial f}{\partial z}
|
||||
|
||||
One can then use equation :eq:`reflection-system` to develop equations for
|
||||
transforming a particle's direction given the equation of the surface.
|
||||
|
||||
Plane Perpendicular to an Axis
|
||||
------------------------------
|
||||
|
||||
For a plane that is perpendicular to an axis, the rule for reflection is almost
|
||||
so simple that no derivation is needed at all. Nevertheless, we will proceed
|
||||
with the derivation to confirm that the rules of geometry agree with our
|
||||
intuition. The gradient of the surface :math:`f(x,y,z) = x - x_0 = 0` is simply
|
||||
:math:`\nabla f = (1, 0, 0)`. Note that this vector is already normalized,
|
||||
i.e. :math:`|| \nabla f || = 1`. The second two equations in
|
||||
:eq:`reflection-system` tell us that :math:`v` and :math:`w` do not change and
|
||||
the first tell us that
|
||||
|
||||
.. math::
|
||||
:label: reflection-xplane
|
||||
|
||||
u' = u - 2u = -u
|
||||
|
||||
We see that reflection for a plane perpendicular to an axis only entails
|
||||
negating the directional cosine for that axis.
|
||||
|
||||
Generic Plane
|
||||
-------------
|
||||
|
||||
A generic plane has the form :math:`f(x,y,z) = Ax + By + Cz - D = 0`. Thus, the
|
||||
gradient to the surface is simply :math:`\nabla f = (A,B,C)` whose norm squared
|
||||
is :math:`A^2 + B^2 + C^2`. This implies that
|
||||
|
||||
.. math::
|
||||
:label: reflection-plane-constant
|
||||
|
||||
\frac{2 (\mathbf{\Omega} \cdot \nabla f)}{|| \nabla f ||^2} = \frac{2(Au +
|
||||
Bv + Cw)}{A^2 + B^2 + C^2}
|
||||
|
||||
Substituting equation :eq:`reflection-plane-constant` into equation
|
||||
:eq:`reflection-system` gives us the form of the solution. For example, the
|
||||
x-component of the reflected direction will be
|
||||
|
||||
.. math::
|
||||
:label: reflection-plane
|
||||
|
||||
u' = u - \frac{2A(Au + Bv + Cw)}{A^2 + B^2 + C^2}
|
||||
|
||||
|
||||
Cylinder Parallel to an Axis
|
||||
----------------------------
|
||||
|
||||
A cylinder parallel to, for example, the x-axis has the form :math:`f(x,y,z) =
|
||||
(y - y_0)^2 + (z - z_0)^2 - R^2 = 0`. Thus, the gradient to the surface is
|
||||
|
||||
.. math::
|
||||
:label: reflection-cylinder-grad
|
||||
|
||||
\nabla f = 2 \left ( \begin{array}{c} 0 \\ y - y_0 \\ z - z_0 \end{array}
|
||||
\right ) = 2 \left ( \begin{array}{c} 0 \\ \bar{y} \\ \bar{z} \end{array}
|
||||
\right )
|
||||
|
||||
where we have introduced the constants :math:`\bar{y}` and
|
||||
:math:`\bar{z}`. Taking the square of the norm of the gradient, we find that
|
||||
|
||||
.. math::
|
||||
:label: reflection-cylinder-norm
|
||||
|
||||
|| \nabla f ||^2 = 4 \bar{y}^2 + 4 \bar{z}^2 = 4 R^2
|
||||
|
||||
This implies that
|
||||
|
||||
.. math::
|
||||
:label: reflection-cylinder-constant
|
||||
|
||||
\frac{2 (\mathbf{\Omega} \cdot \nabla f)}{|| \nabla f ||^2} =
|
||||
\frac{\bar{y}v + \bar{z}w}{R^2}
|
||||
|
||||
Substituting equations :eq:`reflection-cylinder-constant` and
|
||||
:eq:`reflection-cylinder-grad` into equation :eq:`reflection-system` gives us
|
||||
the form of the solution. In this case, the x-component will not change. The y-
|
||||
and z-components of the reflected direction will be
|
||||
|
||||
.. math::
|
||||
:label: reflection-cylinder
|
||||
|
||||
v' = v - \frac{2 ( \bar{y}v + \bar{z}w ) \bar{y}}{R^2} \\
|
||||
|
||||
w' = w - \frac{2 ( \bar{y}v + \bar{z}w ) \bar{z}}{R^2}
|
||||
|
||||
|
||||
Sphere
|
||||
------
|
||||
|
||||
The surface equation for a sphere has the form :math:`f(x,y,z) = (x - x_0)^2 +
|
||||
(y - y_0)^2 + (z - z_0)^2 - R^2 = 0`. Thus, the gradient to the surface is
|
||||
|
||||
.. math::
|
||||
:label: reflection-sphere-grad
|
||||
|
||||
\nabla f = 2 \left ( \begin{array}{c} x - x_0 \\ y - y_0 \\ z - z_0
|
||||
\end{array} \right ) = 2 \left ( \begin{array}{c} \bar{x} \\ \bar{y} \\
|
||||
\bar{z} \end{array} \right )
|
||||
|
||||
where we have introduced the constants :math:`\bar{x}, \bar{y}, \bar{z}`. Taking
|
||||
the square of the norm of the gradient, we find that
|
||||
|
||||
.. math::
|
||||
:label: reflection-sphere-norm
|
||||
|
||||
|| \nabla f ||^2 = 4 \bar{x}^2 + 4 \bar{y}^2 + 4 \bar{z}^2 = 4 R^2
|
||||
|
||||
This implies that
|
||||
|
||||
.. math::
|
||||
:label: reflection-sphere-constant
|
||||
|
||||
\frac{2 (\mathbf{\Omega} \cdot \nabla f)}{|| \nabla f ||^2} =
|
||||
\frac{\bar{x}u + \bar{y}v + \bar{z}w}{R^2}
|
||||
|
||||
Substituting equations :eq:`reflection-sphere-constant` and
|
||||
:eq:`reflection-sphere-grad` into equation :eq:`reflection-system` gives us the
|
||||
form of the solution:
|
||||
|
||||
.. math::
|
||||
:label: reflection-sphere
|
||||
|
||||
u' = u - \frac{2 ( \bar{x}u + \bar{y}v + \bar{z}w ) \bar{x} }{R^2} \\
|
||||
|
||||
v' = v - \frac{2 ( \bar{x}u + \bar{y}v + \bar{z}w ) \bar{y} }{R^2} \\
|
||||
|
||||
w' = w - \frac{2 ( \bar{x}u + \bar{y}v + \bar{z}w ) \bar{z} }{R^2}
|
||||
|
||||
Cone Parallel to an Axis
|
||||
------------------------
|
||||
|
||||
A cone parallel to, for example, the z-axis has the form :math:`f(x,y,z) = (x -
|
||||
x_0)^2 + (y - y_0)^2 - R^2(z - z_0)^2 = 0`. Thus, the gradient to the surface is
|
||||
|
||||
.. math::
|
||||
:label: reflection-cone-grad
|
||||
|
||||
\nabla f = 2 \left ( \begin{array}{c} x - x_0 \\ y - y_0 \\ -R^2(z - z_0)
|
||||
\end{array} \right ) = 2 \left ( \begin{array}{c} \bar{x} \\ \bar{y} \\
|
||||
-R^2\bar{z} \end{array} \right )
|
||||
|
||||
where we have introduced the constants :math:`\bar{x}`, :math:`\bar{y}`, and
|
||||
:math:`\bar{z}`. Taking the square of the norm of the gradient, we find that
|
||||
|
||||
.. math::
|
||||
:label: reflection-cone-norm
|
||||
|
||||
|| \nabla f ||^2 = 4 \bar{x}^2 + \bar{y}^2 + 4 R^4 \bar{z}^2 \\ = 4 R^2
|
||||
\bar{z}^2 + 4 R^4 \bar{z}^2 \\ = 4 R^2 (1 + R^2) \bar{z}^2
|
||||
|
||||
This implies that
|
||||
|
||||
.. math::
|
||||
:label: reflection-cone-constant
|
||||
|
||||
\frac{2 (\mathbf{\Omega} \cdot \nabla f)}{|| \nabla f ||^2} =
|
||||
\frac{\bar{x}u + \bar{y}v - R^2\bar{z}w}{R^2 (1 + R^2) \bar{z}^2}
|
||||
|
||||
Substituting equations :eq:`reflection-cone-constant` and
|
||||
:eq:`reflection-cone-grad` into equation :eq:`reflection-system` gives us the
|
||||
form of the solution:
|
||||
|
||||
.. math::
|
||||
:label: reflection-cone
|
||||
|
||||
u' = u - \frac{2 (\bar{x}u + \bar{y}v - R^2\bar{z}w) \bar{x}}{R^2 (1 + R^2)
|
||||
\bar{z}^2}
|
||||
|
||||
v' = v - \frac{2 (\bar{x}u + \bar{y}v - R^2\bar{z}w) \bar{y}}{R^2 (1 + R^2)
|
||||
\bar{z}^2}
|
||||
|
||||
w' = w + \frac{2 (\bar{x}u + \bar{y}v - R^2\bar{z}w)}{R^2 (1 + R^2) \bar{z}}
|
||||
|
||||
General Quadric
|
||||
---------------
|
||||
|
||||
A general quadric surface has the form :math:`f(x,y,z) = Ax^2 + By^2 + Cz^2 +
|
||||
Dxy + Eyz + Fxz + Gx + Hy + Jz + K = 0`. Thus, the gradient to the surface is
|
||||
|
||||
.. math::
|
||||
:label: reflection-quadric-grad
|
||||
|
||||
\nabla f = \left ( \begin{array}{c} 2Ax + Dy + Fz + G \\ 2By + Dx + Ez + H
|
||||
\\ 2Cz + Ey + Fx + J \end{array} \right ).
|
||||
|
||||
|
||||
.. _white:
|
||||
|
||||
-------------------------
|
||||
White Boundary Conditions
|
||||
-------------------------
|
||||
|
||||
The `white boundary condition <https://doi.org/10.1016/j.anucene.2019.05.006>`_
|
||||
is usually applied in deterministic codes, where the particle will hit the
|
||||
surface and travel back with isotropic angular distribution. The change in
|
||||
particle's direction is sampled from a cosine distribution instead of uniform.
|
||||
Figure :num:`fig-cosine-dist` shows an example of cosine-distribution reflection
|
||||
on the arbitrary surface relative to the surface normal.
|
||||
|
||||
.. _fig-cosine-dist:
|
||||
|
||||
.. figure:: ../_images/cosine-dist.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Cosine-distribution reflection on an arbitrary surface.
|
||||
|
||||
The probability density function (pdf) for the reflected direction can be
|
||||
expressed as follows,
|
||||
|
||||
.. math::
|
||||
:label: white-reflection-pdf
|
||||
|
||||
f(\mu, \phi) d\mu d\phi = \frac{\mu}{\pi} d\mu d\phi = 2\mu d\mu \frac{d\phi}{2\pi}
|
||||
|
||||
where :math:`\mu = \cos \theta` is the cosine of the polar angle between
|
||||
reflected direction and the normal to the surface; and :math:`\theta` is the
|
||||
azimuthal angle in :math:`[0,2\pi]`. We can separate the multivariate
|
||||
probability density into two separate univariate density functions, one for
|
||||
the cosine of the polar angle,
|
||||
|
||||
.. math::
|
||||
:label: white-reflection-cosine
|
||||
|
||||
f(\mu) = 2\mu
|
||||
|
||||
and one for the azimuthal angle,
|
||||
|
||||
.. math::
|
||||
:label: white-reflection-uniform
|
||||
|
||||
f(\phi) = \frac{1}{2\pi}.
|
||||
|
||||
Each of these density functions can be sampled by analytical inversion of the
|
||||
cumulative distribution distribution, resulting in the following sampling
|
||||
scheme:
|
||||
|
||||
.. math::
|
||||
:label: white-reflection-sqrt-prn
|
||||
|
||||
\mu = \sqrt{\xi_1} \\
|
||||
\phi = 2\pi\xi_2
|
||||
|
||||
where :math:`\xi_1` and :math:`\xi_2` are uniform random numbers on
|
||||
:math:`[0,1)`. With the sampled values of :math:`\mu` and :math:`\phi`, the
|
||||
final reflected direction vector can be computed via rotation of the surface
|
||||
normal using the equations from :ref:`transform-coordinates`. The white boundary
|
||||
condition can be applied to any kind of surface, as long as the normal to the
|
||||
surface is known as in :ref:`reflection`.
|
||||
|
||||
.. _constructive solid geometry: https://en.wikipedia.org/wiki/Constructive_solid_geometry
|
||||
.. _surfaces: https://en.wikipedia.org/wiki/Surface
|
||||
.. _MCNP: http://mcnp.lanl.gov
|
||||
.. _Serpent: http://montecarlo.vtt.fi
|
||||
.. _Monte Carlo Performance benchmark: https://github.com/mit-crpg/benchmarks/tree/master/mc-performance/openmc
|
||||
21
docs/source/methods/index.rst
Normal file
21
docs/source/methods/index.rst
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
.. _methods:
|
||||
|
||||
======================
|
||||
Theory and Methodology
|
||||
======================
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 3
|
||||
|
||||
introduction
|
||||
geometry
|
||||
cross_sections
|
||||
random_numbers
|
||||
neutron_physics
|
||||
photon_physics
|
||||
tallies
|
||||
eigenvalue
|
||||
parallelization
|
||||
cmfd
|
||||
energy_deposition
|
||||
147
docs/source/methods/introduction.rst
Normal file
147
docs/source/methods/introduction.rst
Normal file
|
|
@ -0,0 +1,147 @@
|
|||
.. _methods_introduction:
|
||||
|
||||
============
|
||||
Introduction
|
||||
============
|
||||
|
||||
The physical process by which a population of particles evolves over time is
|
||||
governed by a number of `probability distributions`_. For instance, given a
|
||||
particle traveling through some material, there is a probability distribution
|
||||
for the distance it will travel until its next collision (an exponential
|
||||
distribution). Then, when it collides with a nucleus, there is an associated
|
||||
probability of undergoing each possible reaction with that nucleus. While the
|
||||
behavior of any single particle is unpredictable, the average behavior of a
|
||||
large population of particles originating from the same source is well defined.
|
||||
|
||||
If the probability distributions that govern the transport of a particle are
|
||||
known, the process of single particles randomly streaming and colliding with
|
||||
nuclei can be simulated directly with computers using a technique known as
|
||||
`Monte Carlo`_ simulation. If enough particles are simulated this way, the
|
||||
average behavior can be determined to within arbitrarily small statistical
|
||||
error, a fact guaranteed by the `central limit theorem`_. To be more precise,
|
||||
the central limit theorem tells us that the variance of the sample mean of some
|
||||
physical parameter being estimated with Monte Carlo will be inversely
|
||||
proportional to the number of realizations, i.e. the number of particles we
|
||||
simulate:
|
||||
|
||||
.. math::
|
||||
|
||||
\sigma^2 \propto \frac{1}{N}.
|
||||
|
||||
where :math:`\sigma^2` is the variance of the sample mean and :math:`N` is the
|
||||
number of realizations.
|
||||
|
||||
------------------------
|
||||
Overview of Program Flow
|
||||
------------------------
|
||||
|
||||
OpenMC performs a Monte Carlo simulation one particle at a time -- at no point
|
||||
is more than one particle being tracked on a single program instance. Before any
|
||||
particles are tracked, the problem must be initialized. This involves the
|
||||
following steps:
|
||||
|
||||
- Read input files and building data structures for the geometry, materials,
|
||||
tallies, and other associated variables.
|
||||
|
||||
- Initialize the pseudorandom number generator.
|
||||
|
||||
- Read the contiuous-energy or multi-group cross section data specified in
|
||||
the problem.
|
||||
|
||||
- If using a special energy grid treatment such as a union energy grid or
|
||||
lethargy bins, that must be initialized as well in a continuous-energy
|
||||
problem.
|
||||
|
||||
- In a multi-group problem, individual nuclide cross section information is
|
||||
combined to produce material-specific cross section data.
|
||||
|
||||
- In a fixed source problem, source sites are sampled from the specified
|
||||
source. In an eigenvalue problem, source sites are sampled from some
|
||||
initial source distribution or from a source file. The source sites
|
||||
consist of coordinates, a direction, and an energy.
|
||||
|
||||
Once initialization is complete, the actual transport simulation can
|
||||
proceed. The life of a single particle will proceed as follows:
|
||||
|
||||
1. The particle's properties are initialized from a source site previously
|
||||
sampled.
|
||||
|
||||
2. Based on the particle's coordinates, the current cell in which the particle
|
||||
resides is determined.
|
||||
|
||||
3. The energy-dependent cross sections for the material that the particle is
|
||||
currently in are determined. Note that this includes the total
|
||||
cross section, which is not pre-calculated.
|
||||
|
||||
4. The distance to the nearest boundary of the particle's cell is determined
|
||||
based on the bounding surfaces to the cell.
|
||||
|
||||
5. The distance to the next collision is sampled. If the total material
|
||||
cross section is :math:`\Sigma_t`, this can be shown to be
|
||||
|
||||
.. math::
|
||||
|
||||
d = -\frac{\ln \xi}{\Sigma_t}
|
||||
|
||||
where :math:`\xi` is a `pseudorandom number`_ sampled from a uniform
|
||||
distribution on :math:`[0,1)`.
|
||||
|
||||
6. If the distance to the nearest boundary is less than the distance to the next
|
||||
collision, the particle is moved forward to this boundary. Then, the process
|
||||
is repeated from step 2. If the distance to collision is closer than the
|
||||
distance to the nearest boundary, then the particle will undergo a collision.
|
||||
|
||||
7. The material at the collision site may consist of multiple nuclides. First,
|
||||
the nuclide with which the collision will happen is sampled based on the
|
||||
total cross sections. If the total cross section of material :math:`i` is
|
||||
:math:`\Sigma_{t,i}`, then the probability that any nuclide is sampled is
|
||||
|
||||
.. math::
|
||||
|
||||
P(i) = \frac{\Sigma_{t,i}}{\Sigma_t}.
|
||||
|
||||
Note that the above selection of collided nuclide only applies to
|
||||
continuous-energy simulations as multi-group simulations use nuclide
|
||||
data which has already been combined in to material-specific data.
|
||||
|
||||
8. Once the specific nuclide is sampled, the random samples a reaction for
|
||||
that nuclide based on the microscopic cross sections. If the microscopic
|
||||
cross section for some reaction :math:`x` is :math:`\sigma_x` and the total
|
||||
microscopic cross section for the nuclide is :math:`\sigma_t`, then the
|
||||
probability that reaction :math:`x` will occur is
|
||||
|
||||
.. math::
|
||||
|
||||
P(x) = \frac{\sigma_x}{\sigma_t}.
|
||||
|
||||
Since multi-group simulations use material-specific data, the above is
|
||||
performed with those material multi-group cross sections (i.e.,
|
||||
macroscopic cross sections for the material) instead of microscopic
|
||||
cross sections for the nuclide).
|
||||
|
||||
9. If the sampled reaction is elastic or inelastic scattering, the outgoing
|
||||
energy and angle is sampled from the appropriate distribution. In
|
||||
continuous-energy simulation, reactions of type :math:`(n,xn)` are treated
|
||||
as scattering and any additional particles which may be created are added
|
||||
to a secondary particle bank to be tracked later. In a multi-group
|
||||
simulation, this secondary bank is not used but the particle weight is
|
||||
increased accordingly. The original particle then continues from step 3.
|
||||
If the reaction is absorption or fission, the particle dies and if
|
||||
necessary, fission sites are created and stored in the fission bank.
|
||||
|
||||
After all particles have been simulated, there are a few final tasks that must
|
||||
be performed before the run is finished. This include the following:
|
||||
|
||||
- With the accumulated sum and sum of squares for each tally, the sample mean
|
||||
and its variance is calculated.
|
||||
|
||||
- All tallies and other results are written to disk.
|
||||
|
||||
- If requested, a source file is written to disk.
|
||||
|
||||
- Dynamically-allocated memory should be freed.
|
||||
|
||||
.. _probability distributions: https://en.wikipedia.org/wiki/Probability_distribution
|
||||
.. _Monte Carlo: https://en.wikipedia.org/wiki/Monte_Carlo_method
|
||||
.. _central limit theorem: https://en.wikipedia.org/wiki/Central_limit_theorem
|
||||
.. _pseudorandom number: https://en.wikipedia.org/wiki/Pseudorandom_number_generator
|
||||
1677
docs/source/methods/neutron_physics.rst
Normal file
1677
docs/source/methods/neutron_physics.rst
Normal file
File diff suppressed because it is too large
Load diff
650
docs/source/methods/parallelization.rst
Normal file
650
docs/source/methods/parallelization.rst
Normal file
|
|
@ -0,0 +1,650 @@
|
|||
.. _methods_parallel:
|
||||
|
||||
===============
|
||||
Parallelization
|
||||
===============
|
||||
|
||||
Due to the computationally-intensive nature of Monte Carlo methods, there has
|
||||
been an ever-present interest in parallelizing such simulations. Even in the
|
||||
`first paper`_ on the Monte Carlo method, John Metropolis and Stanislaw Ulam
|
||||
recognized that solving the Boltzmann equation with the Monte Carlo method could
|
||||
be done in parallel very easily whereas the deterministic counterparts for
|
||||
solving the Boltzmann equation did not offer such a natural means of
|
||||
parallelism. With the introduction of `vector computers`_ in the early 1970s,
|
||||
general-purpose parallel computing became a reality. In 1972, Troubetzkoy et
|
||||
al. designed a Monte Carlo code to be run on the first vector computer, the
|
||||
ILLIAC-IV [Troubetzkoy]_. The general principles from that work were later
|
||||
refined and extended greatly through the `work of Forrest Brown`_ in the
|
||||
1980s. However, as Brown's work shows, the `single-instruction multiple-data`_
|
||||
(SIMD) parallel model inherent to vector processing does not lend itself to the
|
||||
parallelism on particles in Monte Carlo simulations. Troubetzkoy et
|
||||
al. recognized this, remarking that "the order and the nature of these physical
|
||||
events have little, if any, correlation from history to history," and thus
|
||||
following independent particle histories simultaneously using a SIMD model is
|
||||
difficult.
|
||||
|
||||
The difficulties with vector processing of Monte Carlo codes led to the adoption
|
||||
of the `single program multiple data`_ (SPMD) technique for parallelization. In
|
||||
this model, each different process tracks a particle independently of other
|
||||
processes, and between fission source generations the processes communicate data
|
||||
through a `message-passing interface`_. This means of parallelism was enabled by
|
||||
the introduction of message-passing standards in the late 1980s and early 1990s
|
||||
such as PVM_ and MPI_. The SPMD model proved much easier to use in practice and
|
||||
took advantage of the inherent parallelism on particles rather than
|
||||
instruction-level parallelism. As a result, it has since become ubiquitous for
|
||||
Monte Carlo simulations of transport phenomena.
|
||||
|
||||
Thanks to the particle-level parallelism using SPMD techniques, extremely high
|
||||
parallel efficiencies could be achieved in Monte Carlo codes. Until the last
|
||||
decade, even the most demanding problems did not require transmitting large
|
||||
amounts of data between processors, and thus the total amount of time spent on
|
||||
communication was not significant compared to the amount of time spent on
|
||||
computation. However, today's computing power has created a demand for
|
||||
increasingly large and complex problems, requiring a greater number of particles
|
||||
to obtain decent statistics (and convergence in the case of criticality
|
||||
calculations). This results in a correspondingly higher amount of communication,
|
||||
potentially degrading the parallel efficiency. Thus, while Monte Carlo
|
||||
simulations may seem `embarrassingly parallel`_, obtaining good parallel scaling
|
||||
with large numbers of processors can be quite difficult to achieve in practice.
|
||||
|
||||
.. _fission-bank-algorithms:
|
||||
|
||||
-----------------------
|
||||
Fission Bank Algorithms
|
||||
-----------------------
|
||||
|
||||
Master-Slave Algorithm
|
||||
----------------------
|
||||
|
||||
Monte Carlo particle transport codes commonly implement a SPMD model by having
|
||||
one master process that controls the scheduling of work and the remaining
|
||||
processes wait to receive work from the master, process the work, and then send
|
||||
their results to the master at the end of the simulation (or a source iteration
|
||||
in the case of an eigenvalue calculation). This idea is illustrated in
|
||||
:ref:`figure-master-slave`.
|
||||
|
||||
.. _figure-master-slave:
|
||||
|
||||
.. figure:: ../_images/master-slave.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Communication pattern in master-slave algorithm.
|
||||
|
||||
Eigenvalue calculations are slightly more difficult to parallelize than fixed
|
||||
source calculations since it is necessary to converge on the fission source
|
||||
distribution and eigenvalue before tallying. In the
|
||||
:ref:`method-successive-generations`, to ensure that the results are
|
||||
reproducible, one must guarantee that the process by which fission sites are
|
||||
randomly sampled does not depend on the number of processors. What is typically
|
||||
done is the following:
|
||||
|
||||
1. Each compute node sends_ its fission bank sites to a master process;
|
||||
|
||||
2. The master process sorts or orders the fission sites based on a unique
|
||||
identifier;
|
||||
|
||||
3. The master process samples :math:`N` fission sites from the ordered array
|
||||
of :math:`M` sites; and
|
||||
|
||||
4. The master process broadcasts_ all the fission sites to the compute
|
||||
nodes.
|
||||
|
||||
The first and last steps of this process are the major sources of communication
|
||||
overhead between cycles. Since the master process must receive :math:`M` fission
|
||||
sites from the compute nodes, the first step is necessarily serial. This step
|
||||
can be completed in :math:`O(M)` time. The broadcast step can benefit from
|
||||
parallelization through a tree-based algorithm. Despite this, the communication
|
||||
overhead is still considerable.
|
||||
|
||||
To see why this is the case, it is instructive to look at a hypothetical
|
||||
example. Suppose that a calculation is run with :math:`N = 10,000,000` neutrons
|
||||
across 64 compute nodes. On average, :math:`M = 10,000,000` fission sites will
|
||||
be produced. If the data for each fission site consists of a spatial location
|
||||
(three 8 byte real numbers) and a unique identifier (one 4 byte integer), the
|
||||
memory required per site is 28 bytes. To broadcast 10,000,000 source sites to 64
|
||||
nodes will thus require transferring 17.92 GB of data. Since each compute node
|
||||
does not need to keep every source site in memory, one could modify the
|
||||
algorithm from a broadcast to a scatter_. However, for practical reasons
|
||||
(e.g. work self-scheduling), this is normally not done in production Monte Carlo
|
||||
codes.
|
||||
|
||||
.. _nearest-neighbors-algorithm:
|
||||
|
||||
Nearest Neighbors Algorithm
|
||||
---------------------------
|
||||
|
||||
To reduce the amount of communication required in a fission bank synchronization
|
||||
algorithm, it is desirable to move away from the typical master-slave algorithm
|
||||
to an algorithm whereby the compute nodes communicate with one another only as
|
||||
needed. This concept is illustrated in :ref:`figure-nearest-neighbor`.
|
||||
|
||||
.. _figure-nearest-neighbor:
|
||||
|
||||
.. figure:: ../_images/nearest-neighbor.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Communication pattern in nearest neighbor algorithm.
|
||||
|
||||
Since the source sites for each cycle are sampled from the fission sites banked
|
||||
from the previous cycle, it is a common occurrence for a fission site to be
|
||||
banked on one compute node and sent back to the master only to get sent back to
|
||||
the same compute node as a source site. As a result, much of the communication
|
||||
inherent in the algorithm described previously is entirely unnecessary. By
|
||||
keeping the fission sites local, having each compute node sample fission sites,
|
||||
and sending sites between nodes only as needed, one can cut down on most of the
|
||||
communication. One algorithm to achieve this is as follows:
|
||||
|
||||
1. An exclusive scan is performed on the number of sites banked, and the
|
||||
total number of fission bank sites is broadcasted to all compute nodes. By
|
||||
picturing the fission bank as one large array distributed across multiple
|
||||
nodes, one can see that this step enables each compute node to determine the
|
||||
starting index of fission bank sites in this array. Let us call the starting
|
||||
and ending indices on the :math:`i`-th node :math:`a_i` and :math:`b_i`,
|
||||
respectively;
|
||||
|
||||
2. Each compute node samples sites at random from the fission bank using the
|
||||
same starting seed. A separate array on each compute node is created that
|
||||
consists of sites that were sampled local to that node, i.e. if the index of
|
||||
the sampled site is between :math:`a_i` and :math:`b_i`, it is set aside;
|
||||
|
||||
3. If any node sampled more than :math:`N/p` fission sites where :math:`p`
|
||||
is the number of compute nodes, the extra sites are put in a separate array
|
||||
and sent to all other compute nodes. This can be done efficiently using the
|
||||
allgather_ collective operation;
|
||||
|
||||
4. The extra sites are divided among those compute nodes that sampled fewer
|
||||
than :math:`N/p` fission sites.
|
||||
|
||||
However, even this algorithm exhibits more communication than necessary since
|
||||
the allgather will send fission bank sites to nodes that don't necessarily
|
||||
need any extra sites.
|
||||
|
||||
One alternative is to replace the allgather with a series of sends. If
|
||||
:math:`a_i` is less than :math:`iN/p`, then send :math:`iN/p - a_i` sites to the
|
||||
left adjacent node. Similarly, if :math:`a_i` is greater than :math:`iN/p`, then
|
||||
receive :math:`a_i - iN/p` from the left adjacent node. This idea is applied to
|
||||
the fission bank sites at the end of each node's array as well. If :math:`b_i`
|
||||
is less than :math:`(i+1)N/p`, then receive :math:`(i+1)N/p - b_i` sites from
|
||||
the right adjacent node. If :math:`b_i` is greater than :math:`(i+1)N/p`, then
|
||||
send :math:`b_i - (i+1)N/p` sites to the right adjacent node. Thus, each compute
|
||||
node sends/receives only two messages under normal circumstances.
|
||||
|
||||
The following example illustrates how this algorithm works. Let us suppose we
|
||||
are simulating :math:`N = 1000` neutrons across four compute nodes. For this
|
||||
example, it is instructive to look at the state of the fission bank and source
|
||||
bank at several points in the algorithm:
|
||||
|
||||
1. The beginning of a cycle where each node has :math:`N/p` source sites;
|
||||
|
||||
2. The end of a cycle where each node has accumulated fission sites;
|
||||
|
||||
3. After sampling, where each node has some amount of source sites usually
|
||||
not equal to :math:`N/p`;
|
||||
|
||||
4. After redistribution, each node again has :math:`N/p` source sites for
|
||||
the next cycle;
|
||||
|
||||
At the end of each cycle, each compute node needs 250 fission bank sites to
|
||||
continue on the next cycle. Let us suppose that :math:`p_0` produces 270 fission
|
||||
banks sites, :math:`p_1` produces 230, :math:`p_2` produces 290, and :math:`p_3`
|
||||
produces 250. After each node samples from its fission bank sites, let's assume
|
||||
that :math:`p_0` has 260 source sites, :math:`p_1` has 215, :math:`p_2` has 280,
|
||||
and :math:`p_3` has 245. Note that the total number of sampled sites is 1000 as
|
||||
needed. For each node to have the same number of source sites, :math:`p_0` needs
|
||||
to send its right-most 10 sites to :math:`p_1`, and :math:`p_2` needs to send
|
||||
its left-most 25 sites to :math:`p_1` and its right-most 5 sites to
|
||||
:math:`p_3`. A schematic of this example is shown in
|
||||
:ref:`figure-neighbor-example`. The data local to each node is given a different
|
||||
hatching, and the cross-hatched regions represent source sites that are
|
||||
communicated between adjacent nodes.
|
||||
|
||||
.. _figure-neighbor-example:
|
||||
|
||||
.. figure:: ../_images/nearest-neighbor-example.png
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Example of nearest neighbor algorithm.
|
||||
|
||||
.. _master-slave-cost:
|
||||
|
||||
Cost of Master-Slave Algorithm
|
||||
------------------------------
|
||||
|
||||
While the prior considerations may make it readily apparent that the novel
|
||||
algorithm should outperform the traditional algorithm, it is instructive to look
|
||||
at the total communication cost of the novel algorithm relative to the
|
||||
traditional algorithm. This is especially so because the novel algorithm does
|
||||
not have a constant communication cost due to stochastic fluctuations. Let us
|
||||
begin by looking at the cost of communication in the traditional algorithm
|
||||
|
||||
As discussed earlier, the traditional algorithm is composed of a series of sends
|
||||
and typically a broadcast. To estimate the communication cost of the algorithm,
|
||||
we can apply a simple model that captures the essential features. In this model,
|
||||
we assume that the time that it takes to send a message between two nodes is
|
||||
given by :math:`\alpha + (sN)\beta`, where :math:`\alpha` is the time it takes
|
||||
to initiate the communication (commonly called the latency_), :math:`\beta` is
|
||||
the transfer time per unit of data (commonly called the bandwidth_), :math:`N`
|
||||
is the number of fission sites, and :math:`s` is the size in bytes of each
|
||||
fission site.
|
||||
|
||||
The first step of the traditional algorithm is to send :math:`p` messages to the
|
||||
master node, each of size :math:`sN/p`. Thus, the total time to send these
|
||||
messages is
|
||||
|
||||
.. math::
|
||||
:label: t-send
|
||||
|
||||
t_{\text{send}} = p\alpha + sN\beta.
|
||||
|
||||
Generally, the best parallel performance is achieved in a weak scaling scheme
|
||||
where the total number of histories is proportional to the number of
|
||||
processors. However, we see that when :math:`N` is proportional to :math:`p`,
|
||||
the time to send these messages increases proportionally with :math:`p`.
|
||||
|
||||
Estimating the time of the broadcast is complicated by the fact that different
|
||||
MPI implementations may use different algorithms to perform collective
|
||||
communications. Worse yet, a single implementation may use a different algorithm
|
||||
depending on how many nodes are communicating and the size of the message. Using
|
||||
multiple algorithms allows one to minimize latency for small messages and
|
||||
minimize bandwidth for long messages.
|
||||
|
||||
We will focus here on the implementation of broadcast in the MPICH2_
|
||||
implementation. For short messages, MPICH2 uses a `binomial tree`_ algorithm. In
|
||||
this algorithm, the root process sends the data to one node in the first step,
|
||||
and then in the subsequent, both the root and the other node can send the data
|
||||
to other nodes. Thus, it takes a total of :math:`\lceil \log_2 p \rceil` steps
|
||||
to complete the communication. The time to complete the communication is
|
||||
|
||||
.. math::
|
||||
:label: t-short
|
||||
|
||||
t_{\text{short}} = \lceil \log_2 p \rceil \left ( \alpha + sN\beta \right ).
|
||||
|
||||
This algorithm works well for short messages since the latency term scales
|
||||
logarithmically with the number of nodes. However, for long messages, an
|
||||
algorithm that has lower bandwidth has been proposed by Barnett_ and implemented
|
||||
in MPICH2. Rather than using a binomial tree, the broadcast is divided into a
|
||||
scatter and an allgather. The time to complete the scatter is :math:` \log_2 p
|
||||
\: \alpha + \frac{p-1}{p} N\beta` using a binomial tree algorithm. The allgather
|
||||
is performed using a ring algorithm that completes in :math:`p-1) \alpha +
|
||||
\frac{p-1}{p} N\beta`. Thus, together the time to complete the broadcast is
|
||||
|
||||
.. math::
|
||||
:label: t-broadcast
|
||||
|
||||
t_{\text{long}} = \left ( \log_2 p + p - 1 \right ) \alpha + 2 \frac{p-1}{p}
|
||||
sN\beta.
|
||||
|
||||
The fission bank data will generally exceed the threshold for switching from
|
||||
short to long messages (typically 8 kilobytes), and thus we will use the
|
||||
equation for long messages. Adding equations :eq:`t-send` and :eq:`t-broadcast`,
|
||||
the total cost of the series of sends and the broadcast is
|
||||
|
||||
.. math::
|
||||
:label: t-old
|
||||
|
||||
t_{\text{old}} = \left ( \log_2 p + 2p - 1 \right ) \alpha + \frac{3p-2}{p}
|
||||
sN\beta.
|
||||
|
||||
Cost of Nearest Neighbor Algorithm
|
||||
----------------------------------
|
||||
|
||||
With the communication cost of the traditional fission bank algorithm
|
||||
quantified, we now proceed to discuss the communicatin cost of the proposed
|
||||
algorithm. Comparing the cost of communication of this algorithm with the
|
||||
traditional algorithm is not trivial due to fact that the cost will be a
|
||||
function of how many fission sites are sampled on each node. If each node
|
||||
samples exactly :math:`N/p` sites, there will not be communication between nodes
|
||||
at all. However, if any one node samples more or less than :math:`N/p` sites,
|
||||
the deviation will result in communication between logically adjacent nodes. To
|
||||
determine the expected deviation, one can analyze the process based on the
|
||||
fundamentals of the Monte Carlo process.
|
||||
|
||||
The steady-state neutron transport equation for a multiplying medium can be
|
||||
written in the form of an eigenvalue problem,
|
||||
|
||||
.. math::
|
||||
:label: NTE
|
||||
|
||||
S(\mathbf{r})= \frac{1}{k} \int F(\mathbf{r}' \rightarrow
|
||||
\mathbf{r})S(\mathbf{r}')\: d\mathbf{r},
|
||||
|
||||
where :math:`\mathbf{r}` is the spatial coordinates of the neutron,
|
||||
:math:`S(\mathbf{r})` is the source distribution defined as the expected number
|
||||
of neutrons born from fission per unit phase-space volume at :math:`\mathbf{r}`,
|
||||
:math:`F( \mathbf{r}' \rightarrow \mathbf{r})` is the expected number of
|
||||
neutrons born from fission per unit phase space volume at :math:`\mathbf{r}`
|
||||
caused by a neutron at :math:`\mathbf{r}`, and :math:`k` is the eigenvalue. The
|
||||
fundamental eigenvalue of equation :eq:`NTE` is known as :math:`k_{eff}`, but
|
||||
for simplicity we will simply refer to it as :math:`k`.
|
||||
|
||||
In a Monte Carlo criticality simulation, the power iteration method is applied
|
||||
iteratively to obtain stochastic realizations of the source distribution and
|
||||
estimates of the :math:`k`-eigenvalue. Let us define :math:`\hat{S}^{(m)}` to be
|
||||
the realization of the source distribution at cycle :math:`m` and
|
||||
:math:`\hat{\epsilon}^{(m)}` be the noise arising from the stochastic nature of
|
||||
the tracking process. We can write the stochastic realization in terms of the
|
||||
fundamental source distribution and the noise component as (see `Brissenden and
|
||||
Garlick`_):
|
||||
|
||||
.. math::
|
||||
:label: source
|
||||
|
||||
\hat{S}^{(m)}(\mathbf{r})= N S(\mathbf{r}) + \sqrt{N}
|
||||
\hat{\epsilon}^{(m)}(\mathbf{r}),
|
||||
|
||||
where :math:`N` is the number of particle histories per cycle. Without loss of
|
||||
generality, we shall drop the superscript notation indicating the cycle as it is
|
||||
understood that the stochastic realization is at a particular cycle. The
|
||||
expected value of the stochastic source distribution is simply
|
||||
|
||||
.. math::
|
||||
:label: expected-value-source
|
||||
|
||||
E \left[ \hat{S}(\mathbf{r})\right] = N S (\mathbf{r})
|
||||
|
||||
since :math:`E \left[ \hat{\epsilon}(\mathbf{r})\right] = 0`. The noise in the
|
||||
source distribution is due only to :math:`\hat{\epsilon}(\mathbf{r})` and thus
|
||||
the variance of the source distribution will be
|
||||
|
||||
.. math::
|
||||
:label: var-source
|
||||
|
||||
\text{Var} \left[ \hat{S}(\mathbf{r})\right] = N \text{Var} \left[
|
||||
\hat{\epsilon}(\mathbf{r}) \right].
|
||||
|
||||
Lastly, the stochastic and true eigenvalues can be written as integrals over all
|
||||
phase space of the stochastic and true source distributions, respectively, as
|
||||
|
||||
.. math::
|
||||
:label: k-to-source
|
||||
|
||||
\hat{k} = \frac{1}{N} \int \hat{S}(\mathbf{r}) \: d\mathbf{r} \quad
|
||||
\text{and} \quad k = \int S(\mathbf{r}) \: d\mathbf{r},
|
||||
|
||||
noting that :math:`S(\mathbf{r})` is :math:`O(1)`. One should note that the
|
||||
expected value :math:`k` calculated by Monte Carlo power iteration (i.e. the
|
||||
method of successive generations) will be biased from the true fundamental
|
||||
eigenvalue of equation :eq:`NTE` by :math:`O(1/N)` (see `Brissenden and
|
||||
Garlick`_), but we will assume henceforth that the number of particle histories
|
||||
per cycle is sufficiently large to neglect this bias.
|
||||
|
||||
With this formalism, we now have a framework within which we can determine the
|
||||
properties of the distribution of expected number of fission sites. The explicit
|
||||
form of the source distribution can be written as
|
||||
|
||||
.. math::
|
||||
:label: source-explicit
|
||||
|
||||
\hat{S}(\mathbf{r}) = \sum_{i=1}^{M} w_i \delta( \mathbf{r} - \mathbf{r}_i )
|
||||
|
||||
where :math:`\mathbf{r}_i` is the spatial location of the :math:`i`-th fission
|
||||
site, :math:`w_i` is the statistical weight of the fission site at
|
||||
:math:`\mathbf{r}_i`, and :math:`M` is the total number of fission sites. It is
|
||||
clear that the total weight of the fission sites is simply the integral of the
|
||||
source distribution. Integrating equation :eq:`source` over all space, we obtain
|
||||
|
||||
.. math::
|
||||
:label: source-integrated
|
||||
|
||||
\int \hat{S}(\mathbf{r}) \: d\mathbf{r} = N \int S(\mathbf{r}) \:
|
||||
d\mathbf{r} + \sqrt{N} \int \hat{\epsilon}(\mathbf{r}) \: d\mathbf{r} .
|
||||
|
||||
Substituting the expressions for the stochastic and true eigenvalues from
|
||||
equation :eq:`k-to-source`, we can relate the stochastic eigenvalue to the
|
||||
integral of the noise component of the source distribution as
|
||||
|
||||
.. math::
|
||||
:label: noise-integeral
|
||||
|
||||
N\hat{k} = Nk + \sqrt{N} \int \hat{\epsilon}(\mathbf{r}) \: d\mathbf{r}.
|
||||
|
||||
Since the expected value of :math:`\hat{\epsilon}` is zero, the expected value
|
||||
of its integral will also be zero. We thus see that the variance of the integral
|
||||
of the source distribution, i.e. the variance of the total weight of fission
|
||||
sites produced, is directly proportional to the variance of the integral of the
|
||||
noise component. Let us call this term :math:`\sigma^2` for simplicity:
|
||||
|
||||
.. math::
|
||||
:label: variance-sigma2
|
||||
|
||||
\text{Var} \left[ \int \hat{S}(\mathbf{r}) \right ] = N \sigma^2.
|
||||
|
||||
The actual value of :math:`\sigma^2` will depend on the physical nature of the
|
||||
problem, whether variance reduction techniques are employed, etc. For instance,
|
||||
one could surmise that for a highly scattering problem, :math:`\sigma^2` would
|
||||
be smaller than for a highly absorbing problem since more collisions will lead
|
||||
to a more precise estimate of the source distribution. Similarly, using implicit
|
||||
capture should in theory reduce the value of :math:`\sigma^2`.
|
||||
|
||||
Let us now consider the case where the :math:`N` total histories are divided up
|
||||
evenly across :math:`p` compute nodes. Since each node simulates :math:`N/p`
|
||||
histories, we can write the source distribution as
|
||||
|
||||
.. math::
|
||||
:label: source-node
|
||||
|
||||
\hat{S}_i(\mathbf{r})= \frac{N}{p} S(\mathbf{r}) + \sqrt{\frac{N}{p}}
|
||||
\hat{\epsilon}_i(\mathbf{r}) \quad \text{for} \quad i = 1, \dots, p
|
||||
|
||||
Integrating over all space and simplifying, we can obtain an expression for the
|
||||
eigenvalue on the :math:`i`-th node:
|
||||
|
||||
.. math::
|
||||
:label: k-i-hat
|
||||
|
||||
\hat{k}_i = k + \sqrt{\frac{p}{N}} \int \hat{\epsilon}_i(\mathbf{r}) \:
|
||||
d\mathbf{r}.
|
||||
|
||||
It is easy to show from this expression that the stochastic realization of the
|
||||
global eigenvalue is merely the average of these local eigenvalues:
|
||||
|
||||
.. math::
|
||||
:label: average-k-as-sum
|
||||
|
||||
\hat{k} = \frac{1}{p} \sum_{i=1}^p \hat{k}_i.
|
||||
|
||||
As was mentioned earlier, at the end of each cycle one must sample :math:`N`
|
||||
sites from the :math:`M` sites that were created. Thus, the source for the next
|
||||
cycle can be seen as the fission source from the current cycle divided by the
|
||||
stochastic realization of the eigenvalue since it is clear from equation
|
||||
:eq:`k-to-source` that :math:`\hat{k} = M/N`. Similarly, the number of sites
|
||||
sampled on each compute node that will be used for the next cycle is
|
||||
|
||||
.. math::
|
||||
:label: sites-per-node
|
||||
|
||||
M_i = \frac{1}{\hat{k}} \int \hat{S}_i(\mathbf{r}) \: d\mathbf{r} =
|
||||
\frac{N}{p} \frac{\hat{k}_i}{\hat{k}}.
|
||||
|
||||
While we know conceptually that each compute node will under normal
|
||||
circumstances send two messages, many of these messages will overlap. Rather
|
||||
than trying to determine the actual communication cost, we will instead attempt
|
||||
to determine the maximum amount of data being communicated from one node to
|
||||
another. At any given cycle, the number of fission sites that the :math:`j`-th
|
||||
compute node will send or receive (:math:`\Lambda_j`) is
|
||||
|
||||
.. math::
|
||||
:label: Lambda
|
||||
|
||||
\Lambda_j = \left | \sum_{i=1}^j M_i - \frac{jN}{p} \right |.
|
||||
|
||||
Noting that :math:`jN/p` is the expected value of the summation, we can write
|
||||
the expected value of :math:`\Lambda_j` as the mean absolute deviation of the
|
||||
summation:
|
||||
|
||||
.. math::
|
||||
:label: mean-dev-lambda
|
||||
|
||||
E \left [ \Lambda_j \right ] = E \left [ \left | \sum_{i=1}^j M_i -
|
||||
\frac{jN}{p} \right | \right ] = \text{MD} \left [ \sum_{i=1}^j M_i \right ]
|
||||
|
||||
where :math:`\text{MD}` indicates the mean absolute deviation of a random
|
||||
variable. The mean absolute deviation is an alternative measure of variability.
|
||||
|
||||
In order to ascertain any information about the mean deviation of :math:`M_i`,
|
||||
we need to know the nature of its distribution. Thus far, we have said nothing
|
||||
of the distributions of the random variables in question. The total number of
|
||||
fission sites resulting from the tracking of :math:`N` neutrons can be shown to
|
||||
be normally distributed via the :ref:`central-limit-theorem` (provided that
|
||||
:math:`N` is sufficiently large) since the fission sites resulting from each
|
||||
neutron are "sampled" from independent, identically-distributed random
|
||||
variables. Thus, :math:`\hat{k}` and :math:`\int \hat{S} (\mathbf{r}) \:
|
||||
d\mathbf{r}` will be normally distributed as will the individual estimates of
|
||||
these on each compute node.
|
||||
|
||||
Next, we need to know what the distribution of :math:`M_i` in equation
|
||||
:eq:`sites-per-node` is or, equivalently, how :math:`\hat{k}_i / \hat{k}` is
|
||||
distributed. The distribution of a ratio of random variables is not easy to
|
||||
calculate analytically, and it is not guaranteed that the ratio distribution is
|
||||
normal if the numerator and denominator are normally distributed. For example,
|
||||
if :math:`X` is a standard normal distribution and :math:`Y` is also standard
|
||||
normal distribution, then the ratio :math:`X/Y` has the standard `Cauchy
|
||||
distribution`_. The reader should be reminded that the Cauchy distribution has
|
||||
no defined mean or variance. That being said, Geary_ has shown that, for the
|
||||
case of two normal distributions, if the denominator is unlikely to assume
|
||||
values less than zero, then the ratio distribution is indeed approximately
|
||||
normal. In our case, :math:`\hat{k}` absolutely cannot assume a value less than
|
||||
zero, so we can be reasonably assured that the distribution of :math:`M_i` will
|
||||
be normal.
|
||||
|
||||
For a normal distribution with mean :math:`\mu` and distribution function
|
||||
:math:`f(x)`, it can be shown that
|
||||
|
||||
.. math::
|
||||
:label: mean-dev-to-stdev
|
||||
|
||||
\int_{-\infty}^{\infty} f(x) \left | x - \mu \right | \: dx =
|
||||
\sqrt{\frac{2}{\pi} \int_{-\infty}^{\infty} f(x) \left ( x - \mu \right )^2
|
||||
\: dx}
|
||||
|
||||
and thus the mean absolute deviation is :math:`\sqrt{2/\pi}` times the standard
|
||||
deviation. Therefore, to evaluate the mean absolute deviation of :math:`M_i`, we
|
||||
need to first determine its variance. Substituting equation
|
||||
:eq:`average-k-as-sum` into equation :eq:`sites-per-node`, we can rewrite
|
||||
:math:`M_i` solely in terms of :math:`\hat{k}_1, \dots, \hat{k}_p`:
|
||||
|
||||
.. math::
|
||||
:label: M-i
|
||||
|
||||
M_i = \frac{N \hat{k}_i}{\sum\limits_{j=1}^p \hat{k}_j}.
|
||||
|
||||
Since we know the variance of :math:`\hat{k}_i`, we can use the error
|
||||
propagation law to determine the variance of :math:`M_i`:
|
||||
|
||||
.. math::
|
||||
:label: M-variance
|
||||
|
||||
\text{Var} \left [ M_i \right ] = \sum_{j=1}^p \left ( \frac{\partial
|
||||
M_i}{\partial \hat{k}_j} \right )^2 \text{Var} \left [ \hat{k}_j \right ] +
|
||||
\sum\limits_{j \neq m} \sum\limits_{m=1}^p \left ( \frac{\partial
|
||||
M_i}{\partial \hat{k}_j} \right ) \left ( \frac{\partial M_i}{\partial
|
||||
\hat{k}_m} \right ) \text{Cov} \left [ \hat{k}_j, \hat{k}_m \right ]
|
||||
|
||||
where the partial derivatives are evaluated at :math:`\hat{k}_j = k`. Since
|
||||
:math:`\hat{k}_j` and :math:`\hat{k}_m` are independent if :math:`j \neq m`,
|
||||
their covariance is zero and thus the second term cancels out. Evaluating the
|
||||
partial derivatives, we obtain
|
||||
|
||||
.. math::
|
||||
:label: M-variance-2
|
||||
|
||||
\text{Var} \left [ M_i \right ] = \left ( \frac{N(p-1)}{kp^2} \right )^2
|
||||
\frac{p\sigma^2}{N} + \sum_{j \neq i} \left ( \frac{-N}{kp^2} \right )^2
|
||||
\frac{p\sigma^2}{N} = \frac{N(p-1)}{k^2p^2} \sigma^2.
|
||||
|
||||
Through a similar analysis, one can show that the variance of
|
||||
:math:`\sum_{i=1}^j M_i` is
|
||||
|
||||
.. math::
|
||||
:label: sum-M-variance
|
||||
|
||||
\text{Var} \left [ \sum_{i=1}^j M_i \right ] = \frac{Nj(p-j)}{k^2p^2}
|
||||
\sigma^2
|
||||
|
||||
Thus, the expected amount of communication on node :math:`j`, i.e. the mean
|
||||
absolute deviation of :math:`\sum_{i=1}^j M_i` is proportional to
|
||||
|
||||
.. math::
|
||||
:label: communication-cost
|
||||
|
||||
E \left [ \Lambda_j \right ] = \sqrt{\frac{2Nj(p-j)\sigma^2}{\pi k^2p^2}}.
|
||||
|
||||
This formula has all the properties that one would expect based on intuition:
|
||||
|
||||
1. As the number of histories increases, the communication cost on each node
|
||||
increases as well;
|
||||
|
||||
2. If :math:`p=1`, i.e. if the problem is run on only one compute node, the
|
||||
variance will be zero. This reflects the fact that exactly :math:`N` sites
|
||||
will be sampled if there is only one node.
|
||||
|
||||
3. For :math:`j=p`, the variance will be zero. Again, this says that when
|
||||
you sum the number of sites from each node, you will get exactly :math:`N`
|
||||
sites.
|
||||
|
||||
We can determine the node that has the highest communication cost by
|
||||
differentiating equation :eq:`communication-cost` with respect to :math:`j`,
|
||||
setting it equal to zero, and solving for :math:`j`. Doing so yields
|
||||
:math:`j_{\text{max}} = p/2`. Interestingly, substituting :math:`j = p/2` in
|
||||
equation :eq:`communication-cost` shows us that the maximum communication cost
|
||||
is actually independent of the number of nodes:
|
||||
|
||||
.. math::
|
||||
:label: maximum-communication
|
||||
|
||||
E \left [ \Lambda_{j_{\text{max}}} \right ] = \sqrt{ \frac{N\sigma^2}{2\pi
|
||||
k^2}}.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. rubric:: References
|
||||
|
||||
.. [Troubetzkoy] E. Troubetzkoy, H. Steinberg, and M. Kalos, "Monte Carlo
|
||||
Radiation Penetration Calculations on a Parallel Computer,"
|
||||
*Trans. Am. Nucl. Soc.*, **17**, 260 (1973).
|
||||
|
||||
.. _first paper: https://doi.org/10.2307/2280232
|
||||
|
||||
.. _work of Forrest Brown: http://hdl.handle.net/2027.42/24996
|
||||
|
||||
.. _Brissenden and Garlick: https://doi.org/10.1016/0306-4549(86)90095-2
|
||||
|
||||
.. _MPICH2: http://www.mcs.anl.gov/mpi/mpich
|
||||
|
||||
.. _binomial tree: https://www.mcs.anl.gov/~thakur/papers/ijhpca-coll.pdf
|
||||
|
||||
.. _Geary: https://doi.org/10.2307/2342070
|
||||
|
||||
.. _Barnett: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.7772
|
||||
|
||||
.. _single-instruction multiple-data: https://en.wikipedia.org/wiki/SIMD
|
||||
|
||||
.. _vector computers: https://en.wikipedia.org/wiki/Vector_processor
|
||||
|
||||
.. _single program multiple data: https://en.wikipedia.org/wiki/SPMD
|
||||
|
||||
.. _message-passing interface: https://en.wikipedia.org/wiki/Message_Passing_Interface
|
||||
|
||||
.. _PVM: http://www.csm.ornl.gov/pvm/pvm_home.html
|
||||
|
||||
.. _MPI: http://www.mcs.anl.gov/research/projects/mpi/
|
||||
|
||||
.. _embarrassingly parallel: https://en.wikipedia.org/wiki/Embarrassingly_parallel
|
||||
|
||||
.. _sends: http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Send.html
|
||||
|
||||
.. _broadcasts: http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Bcast.html
|
||||
|
||||
.. _scatter: http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Scatter.html
|
||||
|
||||
.. _allgather: http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Allgather.html
|
||||
|
||||
.. _Cauchy distribution: https://en.wikipedia.org/wiki/Cauchy_distribution
|
||||
|
||||
.. _latency: https://en.wikipedia.org/wiki/Latency_(engineering)#Packet-switched_networks
|
||||
|
||||
.. _bandwidth: https://en.wikipedia.org/wiki/Bandwidth_(computing)
|
||||
1072
docs/source/methods/photon_physics.rst
Normal file
1072
docs/source/methods/photon_physics.rst
Normal file
File diff suppressed because it is too large
Load diff
72
docs/source/methods/random_numbers.rst
Normal file
72
docs/source/methods/random_numbers.rst
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
.. _methods_random_numbers:
|
||||
|
||||
========================
|
||||
Random Number Generation
|
||||
========================
|
||||
|
||||
In order to sample probability distributions, one must be able to produce random
|
||||
numbers. The standard technique to do this is to generate numbers on the
|
||||
interval :math:`[0,1)` from a deterministic sequence that has properties that
|
||||
make it appear to be random, e.g. being uniformly distributed and not exhibiting
|
||||
correlation between successive terms. Since the numbers produced this way are
|
||||
not truly "random" in a strict sense, they are typically referred to as
|
||||
pseudorandom numbers, and the techniques used to generate them are pseudorandom
|
||||
number generators (PRNGs). Numbers sampled on the unit interval can then be
|
||||
transformed for the purpose of sampling other continuous or discrete probability
|
||||
distributions.
|
||||
|
||||
------------------------------
|
||||
Linear Congruential Generators
|
||||
------------------------------
|
||||
|
||||
There are a great number of algorithms for generating random numbers. One of the
|
||||
simplest and commonly used algorithms is called a `linear congruential
|
||||
generator`_. We start with a random number *seed* :math:`\xi_0` and a sequence
|
||||
of random numbers can then be generated using the following recurrence relation:
|
||||
|
||||
.. math::
|
||||
:label: lcg
|
||||
|
||||
\xi_{i+1} = g \xi_i + c \mod M
|
||||
|
||||
where :math:`g`, :math:`c`, and :math:`M` are constants. The choice of these
|
||||
constants will have a profound effect on the quality and performance of the
|
||||
generator, so they should not be chosen arbitrarily. As Donald Knuth stated in
|
||||
his seminal work *The Art of Computer Programming*, "random numbers should not
|
||||
be generated with a method chosen at random. Some theory should be used."
|
||||
Typically, :math:`M` is chosen to be a power of two as this enables :math:`x
|
||||
\mod M` to be performed using the bitwise AND operator with a bit mask. The
|
||||
constants for the linear congruential generator used by default in OpenMC are
|
||||
:math:`g = 2806196910506780709`, :math:`c = 1`, and :math:`M = 2^{63}` (see
|
||||
`L'Ecuyer`_).
|
||||
|
||||
Skip-ahead Capability
|
||||
---------------------
|
||||
|
||||
One of the important capabilities for a random number generator is to be able to
|
||||
skip ahead in the sequence of random numbers. Without this capability, it would
|
||||
be very difficult to maintain reproducibility in a parallel calculation. If we
|
||||
want to skip ahead :math:`N` random numbers and :math:`N` is large, the cost of
|
||||
sampling :math:`N` random numbers to get to that position may be prohibitively
|
||||
expensive. Fortunately, algorithms have been developed that allow us to skip
|
||||
ahead in :math:`O(\log_2 N)` operations instead of :math:`O(N)`. One algorithm
|
||||
to do so is described in a paper by Brown_. This algorithm relies on the following
|
||||
relationship:
|
||||
|
||||
.. math::
|
||||
:label: lcg-skipahead
|
||||
|
||||
\xi_{i+k} = g^k \xi_i + c \frac{g^k - 1}{g - 1} \mod M
|
||||
|
||||
Note that equation :eq:`lcg-skipahead` has the same general form as equation :eq:`lcg`, so
|
||||
the idea is to determine the new multiplicative and additive constants in
|
||||
:math:`O(\log_2 N)` operations.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. rubric:: References
|
||||
|
||||
|
||||
.. _L'Ecuyer: https://doi.org/10.1090/S0025-5718-99-00996-5
|
||||
.. _Brown: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/anl-rn-arb-stride.pdf
|
||||
.. _linear congruential generator: https://en.wikipedia.org/wiki/Linear_congruential_generator
|
||||
515
docs/source/methods/tallies.rst
Normal file
515
docs/source/methods/tallies.rst
Normal file
|
|
@ -0,0 +1,515 @@
|
|||
.. _methods_tallies:
|
||||
|
||||
=======
|
||||
Tallies
|
||||
=======
|
||||
|
||||
Note that the methods discussed in this section are written specifically for
|
||||
continuous-energy mode but equivalent apply to the multi-group mode if the
|
||||
particle's energy is replaced with the particle's group
|
||||
|
||||
------------------
|
||||
Filters and Scores
|
||||
------------------
|
||||
|
||||
The tally capability in OpenMC takes a similar philosophy as that employed in
|
||||
the MC21_ Monte Carlo code to give maximum flexibility in specifying tallies
|
||||
while still maintaining scalability. Any tally in a Monte Carlo simulation can
|
||||
be written in the following form:
|
||||
|
||||
.. math::
|
||||
:label: tally-integral
|
||||
|
||||
X = \underbrace{\int d\mathbf{r} \int d\mathbf{\Omega} \int
|
||||
dE}_{\text{filters}} \underbrace{f(\mathbf{r}, \mathbf{\Omega},
|
||||
E)}_{\text{scores}} \psi (\mathbf{r}, \mathbf{\Omega}, E)
|
||||
|
||||
|
||||
A user can specify one or more filters which identify which regions of phase
|
||||
space should score to a given tally (the limits of integration as shown in
|
||||
equation :eq:`tally-integral`) as well as the scoring function (:math:`f` in
|
||||
equation :eq:`tally-integral`). For example, if the desired tally was the
|
||||
:math:`(n,\gamma)` reaction rate in a fuel pin, the filter would specify the
|
||||
cell which contains the fuel pin and the scoring function would be the radiative
|
||||
capture macroscopic cross section. The following quantities can be scored in
|
||||
OpenMC: flux, total reaction rate, scattering reaction rate, neutron production
|
||||
from scattering, higher scattering moments, :math:`(n,xn)` reaction rates,
|
||||
absorption reaction rate, fission reaction rate, neutron production rate from
|
||||
fission, and surface currents. The following variables can be used as filters:
|
||||
universe, material, cell, birth cell, surface, mesh, pre-collision energy,
|
||||
post-collision energy, polar angle, azimuthal angle, and the cosine of the
|
||||
change-in-angle due to a scattering event.
|
||||
|
||||
With filters for pre- and post-collision energy and scoring functions for
|
||||
scattering and fission production, it is possible to use OpenMC to generate
|
||||
cross sections with user-defined group structures. These multigroup cross
|
||||
sections can subsequently be used in deterministic solvers such as coarse mesh
|
||||
finite difference (CMFD) diffusion.
|
||||
|
||||
------------------------------
|
||||
Using Maps for Filter-Matching
|
||||
------------------------------
|
||||
|
||||
Some Monte Carlo codes suffer severe performance penalties when tallying a large
|
||||
number of quantities. Care must be taken to ensure that a tally system scales
|
||||
well with the total number of tally bins. In OpenMC, a mapping technique is used
|
||||
that allows for a fast determination of what tally/bin combinations need to be
|
||||
scored to a given particle's phase space coordinates. For each discrete filter
|
||||
variable, a list is stored that contains the tally/bin combinations that could
|
||||
be scored to for each value of the filter variable. If a particle is in cell
|
||||
:math:`n`, the mapping would identify what tally/bin combinations specify cell
|
||||
:math:`n` for the cell filter variable. In this manner, it is not necessary to
|
||||
check the phase space variables against each tally. Note that this technique
|
||||
only applies to discrete filter variables and cannot be applied to energy,
|
||||
angle, or change-in-angle bins. For these filters, it is necessary to perform
|
||||
a binary search on the specified energy grid.
|
||||
|
||||
-----------------------------------------
|
||||
Volume-Integrated Flux and Reaction Rates
|
||||
-----------------------------------------
|
||||
|
||||
One quantity we may wish to compute during the course of a Monte Carlo
|
||||
simulation is the flux or a reaction rate integrated over a finite volume. The
|
||||
volume may be a particular cell, a collection of cells, or the entire
|
||||
geometry. There are various methods by which we can estimate reaction rates
|
||||
|
||||
Analog Estimator
|
||||
----------------
|
||||
|
||||
The analog estimator is the simplest type of estimator for reaction rates. The
|
||||
basic idea is that we simply count the number of actual reactions that take
|
||||
place and use that as our estimate for the reaction rate. This can be written
|
||||
mathematically as
|
||||
|
||||
.. math::
|
||||
:label: analog-estimator
|
||||
|
||||
R_x = \frac{1}{W} \sum_{i \in A} w_i
|
||||
|
||||
where :math:`R_x` is the reaction rate for reaction :math:`x`, :math:`i` denotes
|
||||
an index for each event, :math:`A` is the set of all events resulting in
|
||||
reaction :math:`x`, and :math:`W` is the total starting weight of the particles,
|
||||
and :math:`w_i` is the pre-collision weight of the particle as it enters event
|
||||
:math:`i`. One should note that equation :eq:`analog-estimator` is
|
||||
volume-integrated so if we want a volume-averaged quantity, we need to divided
|
||||
by the volume of the region of integration. If survival biasing is employed, the
|
||||
analog estimator cannot be used for any reactions with zero neutrons in the exit
|
||||
channel.
|
||||
|
||||
Collision Estimator
|
||||
-------------------
|
||||
|
||||
While the analog estimator is conceptually very simple and easy to implement, it
|
||||
can suffer higher variance due to the fact low probability events will not occur
|
||||
often enough to get good statistics if they are being tallied. Thus, it is
|
||||
desirable to use a different estimator that allows us to score to the tally more
|
||||
often. One such estimator is the collision estimator. Instead of tallying a
|
||||
reaction only when it happens, the idea is to make a contribution to the tally
|
||||
at every collision.
|
||||
|
||||
We can start by writing a formula for the collision estimate of the flux. Since
|
||||
:math:`R = \Sigma_t \phi` where :math:`R` is the total reaction rate,
|
||||
:math:`\Sigma_t` is the total macroscopic cross section, and :math:`\phi` is the
|
||||
scalar flux, it stands to reason that we can estimate the flux by taking an
|
||||
estimate of the total reaction rate and dividing it by the total macroscopic
|
||||
cross section. This gives us the following formula:
|
||||
|
||||
.. math::
|
||||
:label: collision-estimator-flux
|
||||
|
||||
\phi = \frac{1}{W} \sum_{i \in C} \frac{w_i}{\Sigma_t (E_i)}
|
||||
|
||||
where :math:`W` is again the total starting weight of the particles, :math:`C`
|
||||
is the set of all events resulting in a collision with a nucleus, and
|
||||
:math:`\Sigma_t (E)` is the total macroscopic cross section of the target
|
||||
material at the incoming energy of the particle :math:`E_i`.
|
||||
|
||||
If we multiply both sides of equation :eq:`collision-estimator-flux` by the
|
||||
macroscopic cross section for some reaction :math:`x`, then we get the collision
|
||||
estimate for the reaction rate for that reaction:
|
||||
|
||||
.. math::
|
||||
:label: collision-estimator
|
||||
|
||||
R_x = \frac{1}{W} \sum_{i \in C} \frac{w_i \Sigma_x (E_i)}{\Sigma_t (E_i)}
|
||||
|
||||
where :math:`\Sigma_x (E_i)` is the macroscopic cross section for reaction
|
||||
:math:`x` at the incoming energy of the particle :math:`E_i`. In comparison to
|
||||
equation :eq:`analog-estimator`, we see that the collision estimate will result
|
||||
in a tally with a larger number of events that score to it with smaller
|
||||
contributions (since we have multiplied it by :math:`\Sigma_x / \Sigma_t`).
|
||||
|
||||
Track-length Estimator
|
||||
----------------------
|
||||
|
||||
One other method we can use to increase the number of events that scores to
|
||||
tallies is to use an estimator the scores contributions to a tally at every
|
||||
track for the particle rather than every collision. This is known as a
|
||||
track-length estimator, sometimes also called a path-length estimator. We first
|
||||
start with an expression for the volume integrated flux, which can be written as
|
||||
|
||||
.. math::
|
||||
:label: flux-integrated
|
||||
|
||||
V \phi = \int d\mathbf{r} \int dE \int d\mathbf{\Omega} \int dt \,
|
||||
\psi(\mathbf{r}, \mathbf{\hat{\Omega}}, E, t)
|
||||
|
||||
where :math:`V` is the volume, :math:`\psi` is the angular flux,
|
||||
:math:`\mathbf{r}` is the position of the particle, :math:`\mathbf{\hat{\Omega}}`
|
||||
is the direction of the particle, :math:`E` is the energy of the particle, and
|
||||
:math:`t` is the time. By noting that :math:`\psi(\mathbf{r},
|
||||
\mathbf{\hat{\Omega}}, E, t) = v n(\mathbf{r}, \mathbf{\hat{\Omega}}, E, t)`
|
||||
where :math:`n` is the angular neutron density, we can rewrite equation
|
||||
:eq:`flux-integrated` as
|
||||
|
||||
.. math::
|
||||
:label: flux-integrated-2
|
||||
|
||||
V \phi = \int d\mathbf{r} \int dE \int dt v \int d\mathbf{\Omega} \, n(\mathbf{r},
|
||||
\mathbf{\hat{\Omega}}, E, t)).
|
||||
|
||||
Using the relations :math:`N(\mathbf{r}, E, t) = \int d\mathbf{\Omega}
|
||||
n(\mathbf{r}, \mathbf{\hat{\Omega}}, E, t)` and :math:`d\ell = v \, dt` where
|
||||
:math:`d\ell` is the differential unit of track length, we then obtain
|
||||
|
||||
.. math::
|
||||
:label: track-length-integral
|
||||
|
||||
V \phi = \int d\mathbf{r} \int dE \int d\ell N(\mathbf{r}, E, t).
|
||||
|
||||
Equation :eq:`track-length-integral` indicates that we can use the length of a
|
||||
particle's trajectory as an estimate for the flux, i.e. the track-length
|
||||
estimator of the flux would be
|
||||
|
||||
.. math::
|
||||
:label: track-length-flux
|
||||
|
||||
\phi = \frac{1}{W} \sum_{i \in T} w_i \ell_i
|
||||
|
||||
where :math:`T` is the set of all the particle's trajectories within the desired
|
||||
volume and :math:`\ell_i` is the length of the :math:`i`-th trajectory. In the
|
||||
same vein as equation :eq:`collision-estimator`, the track-length estimate of a
|
||||
reaction rate is found by multiplying equation :eq:`track-length-flux` by a
|
||||
macroscopic reaction cross section:
|
||||
|
||||
.. math::
|
||||
:label: track-length-estimator
|
||||
|
||||
R_x = \frac{1}{W} \sum_{i \in T} w_i \ell_i \Sigma_x (E_i).
|
||||
|
||||
One important fact to take into consideration is that the use of a track-length
|
||||
estimator precludes us from using any filter that requires knowledge of the
|
||||
particle's state following a collision because by definition, it will not have
|
||||
had a collision at every event. Thus, for tallies with outgoing-energy filters
|
||||
(which require the post-collision energy), scattering change-in-angle filters,
|
||||
or for tallies of scattering moments (which require the scattering cosine of
|
||||
the change-in-angle), we must use an analog estimator.
|
||||
|
||||
.. TODO: Add description of surface current tallies
|
||||
|
||||
----------
|
||||
Statistics
|
||||
----------
|
||||
|
||||
As was discussed briefly in :ref:`methods_introduction`, any given result from a
|
||||
Monte Carlo calculation, colloquially known as a "tally", represents an estimate
|
||||
of the mean of some `random variable`_ of interest. This random variable
|
||||
typically corresponds to some physical quantity like a reaction rate, a net
|
||||
current across some surface, or the neutron flux in a region. Given that all
|
||||
tallies are produced by a `stochastic process`_, there is an associated
|
||||
uncertainty with each value reported. It is important to understand how the
|
||||
uncertainty is calculated and what it tells us about our results. To that end,
|
||||
we will introduce a number of theorems and results from statistics that should
|
||||
shed some light on the interpretation of uncertainties.
|
||||
|
||||
Law of Large Numbers
|
||||
--------------------
|
||||
|
||||
The `law of large numbers`_ is an important statistical result that tells us
|
||||
that the average value of the result a large number of repeated experiments
|
||||
should be close to the `expected value`_. Let :math:`X_1, X_2, \dots, X_n` be an
|
||||
infinite sequence of `independent, identically-distributed random variables`_
|
||||
with expected values :math:`E(X_1) = E(X_2) = \mu`. One form of the law of large
|
||||
numbers states that the sample mean :math:`\bar{X_n} = \frac{X_1 + \dots +
|
||||
X_n}{n}` `converges in probability`_ to the true mean, i.e. for all
|
||||
:math:`\epsilon > 0`
|
||||
|
||||
.. math::
|
||||
|
||||
\lim\limits_{n\rightarrow\infty} P \left ( \left | \bar{X}_n - \mu \right |
|
||||
\ge \epsilon \right ) = 0.
|
||||
|
||||
.. _central-limit-theorem:
|
||||
|
||||
Central Limit Theorem
|
||||
---------------------
|
||||
|
||||
The `central limit theorem`_ (CLT) is perhaps the most well-known and ubiquitous
|
||||
statistical theorem that has far-reaching implications across many
|
||||
disciplines. The CLT is similar to the law of large numbers in that it tells us
|
||||
the limiting behavior of the sample mean. Whereas the law of large numbers tells
|
||||
us only that the value of the sample mean will converge to the expected value of
|
||||
the distribution, the CLT says that the distribution of the sample mean will
|
||||
converge to a `normal distribution`_. As we defined before, let :math:`X_1, X_2,
|
||||
\dots, X_n` be an infinite sequence of independent, identically-distributed
|
||||
random variables with expected values :math:`E(X_i) = \mu` and variances
|
||||
:math:`\text{Var} (X_i) = \sigma^2 < \infty`. Note that we don't require that
|
||||
these random variables take on any particular distribution -- they can be
|
||||
normal, log-normal, Weibull, etc. The central limit theorem states that as
|
||||
:math:`n \rightarrow \infty`, the random variable :math:`\sqrt{n} (\bar{X}_n -
|
||||
\mu)` `converges in distribution`_ to the standard normal distribution:
|
||||
|
||||
.. math::
|
||||
:label: central-limit-theorem
|
||||
|
||||
\sqrt{n} \left ( \frac{1}{n} \sum_{i=1}^n X_i - \mu \right ) \xrightarrow{d}
|
||||
\mathcal{N} (0, \sigma^2)
|
||||
|
||||
Estimating Statistics of a Random Variable
|
||||
------------------------------------------
|
||||
|
||||
Mean
|
||||
++++
|
||||
|
||||
Given independent samples drawn from a random variable, the sample mean is
|
||||
simply an estimate of the average value of the random variable. In a Monte Carlo
|
||||
simulation, the random variable represents physical quantities that we want
|
||||
tallied. If :math:`X` is the random variable with :math:`N` observations
|
||||
:math:`x_1, x_2, \dots, x_N`, then an unbiased estimator for the population mean
|
||||
is the sample mean, defined as
|
||||
|
||||
.. math::
|
||||
:label: sample-mean
|
||||
|
||||
\bar{x} = \frac{1}{N} \sum_{i=1}^N x_i.
|
||||
|
||||
Variance
|
||||
++++++++
|
||||
|
||||
The variance of a population indicates how spread out different members of the
|
||||
population are. For a Monte Carlo simulation, the variance of a tally is a
|
||||
measure of how precisely we know the tally value, with a lower variance
|
||||
indicating a higher precision. There are a few different estimators for the
|
||||
population variance. One of these is the second central moment of the
|
||||
distribution also known as the biased sample variance:
|
||||
|
||||
.. math::
|
||||
:label: biased-variance
|
||||
|
||||
s_N^2 = \frac{1}{N} \sum_{i=1}^N \left ( x_i - \bar{x} \right )^2 = \left (
|
||||
\frac{1}{N} \sum_{i=1}^N x_i^2 \right ) - \bar{x}^2.
|
||||
|
||||
This estimator is biased because its expected value is actually not equal to the
|
||||
population variance:
|
||||
|
||||
.. math::
|
||||
:label: biased-variance-expectation
|
||||
|
||||
E[s_N^2] = \frac{N - 1}{N} \sigma^2
|
||||
|
||||
where :math:`\sigma^2` is the actual population variance. As a result, this
|
||||
estimator should not be used in practice. Instead, one can use `Bessel's
|
||||
correction`_ to come up with an unbiased sample variance estimator:
|
||||
|
||||
.. math::
|
||||
:label: unbiased-variance
|
||||
|
||||
s^2 = \frac{1}{N - 1} \sum_{i=1}^N \left ( x_i - \bar{x} \right )^2 =
|
||||
\frac{1}{N - 1} \left ( \sum_{i=1}^N x_i^2 - N\bar{x}^2 \right ).
|
||||
|
||||
This is the estimator normally used to calculate sample variance. The final form
|
||||
in equation :eq:`unbiased-variance` is especially suitable for computation since
|
||||
we do not need to store the values at every realization of the random variable
|
||||
as the simulation proceeds. Instead, we can simply keep a running sum and sum of
|
||||
squares of the values at each realization of the random variable and use that to
|
||||
calculate the variance.
|
||||
|
||||
Variance of the Mean
|
||||
++++++++++++++++++++
|
||||
|
||||
The previous sections discussed how to estimate the mean and variance of a
|
||||
random variable using statistics on a finite sample. However, we are generally
|
||||
not interested in the *variance of the random variable* itself; we are more
|
||||
interested in the *variance of the estimated mean*. The sample mean is the
|
||||
result of our simulation, and the variance of the sample mean will tell us how
|
||||
confident we should be in our answers.
|
||||
|
||||
Fortunately, it is quite easy to estimate the variance of the mean if we are
|
||||
able to estimate the variance of the random variable. We start with the
|
||||
observation that if we have a series of uncorrelated random variables, we can
|
||||
write the variance of their sum as the sum of their variances:
|
||||
|
||||
.. math::
|
||||
:label: bienayme-formula
|
||||
|
||||
\text{Var} \left ( \sum_{i=1}^N X_i \right ) = \sum_{i=1}^N \text{Var} \left
|
||||
( X_i \right )
|
||||
|
||||
This result is known as the Bienaymé formula. We can use this result to
|
||||
determine a formula for the variance of the sample mean. Assuming that the
|
||||
realizations of our random variable are again identical,
|
||||
independently-distributed samples, then we have that
|
||||
|
||||
.. math::
|
||||
:label: sample-variance-mean
|
||||
|
||||
\text{Var} \left ( \bar{X} \right ) = \text{Var} \left ( \frac{1}{N}
|
||||
\sum_{i=1}^N X_i \right ) = \frac{1}{N^2} \sum_{i=1}^N \text{Var} \left (
|
||||
X_i \right ) = \frac{1}{N^2} \left ( N\sigma^2 \right ) =
|
||||
\frac{\sigma^2}{N}.
|
||||
|
||||
We can combine this result with equation :eq:`unbiased-variance` to come up with
|
||||
an unbiased estimator for the variance of the sample mean:
|
||||
|
||||
.. math::
|
||||
:label: sample-variance-mean-formula
|
||||
|
||||
s_{\bar{X}}^2 = \frac{1}{N - 1} \left ( \frac{1}{N} \sum_{i=1}^N x_i^2 -
|
||||
\bar{x}^2 \right ).
|
||||
|
||||
At this point, an important distinction should be made between the estimator for
|
||||
the variance of the population and the estimator for the variance of the
|
||||
mean. As the number of realizations increases, the estimated variance of the
|
||||
population based on equation :eq:`unbiased-variance` will tend to the true
|
||||
population variance. On the other hand, the estimated variance of the mean will
|
||||
tend to zero as the number of realizations increases. A practical interpretation
|
||||
of this is that the longer you run a simulation, the better you know your
|
||||
results. Therefore, by running a simulation long enough, it is possible to
|
||||
reduce the stochastic uncertainty to arbitrarily low levels.
|
||||
|
||||
Confidence Intervals
|
||||
++++++++++++++++++++
|
||||
|
||||
While the sample variance and standard deviation gives us some idea about the
|
||||
variability of the estimate of the mean of whatever quantities we've tallied, it
|
||||
does not help us interpret how confidence we should be in the results. To
|
||||
quantity the reliability of our estimates, we can use `confidence intervals`_
|
||||
based on the calculated sample variance.
|
||||
|
||||
A :math:`1-\alpha` confidence interval for a population parameter is defined as
|
||||
such: if we repeat the same experiment many times and calculate the confidence
|
||||
interval for each experiment, then :math:`1 - \alpha` percent of the calculated
|
||||
intervals would encompass the true population parameter. Let :math:`x_1, x_2,
|
||||
\dots, x_N` be samples from a set of independent, identically-distributed random
|
||||
variables each with population mean :math:`\mu` and variance
|
||||
:math:`\sigma^2`. The t-statistic is defined as
|
||||
|
||||
.. math::
|
||||
:label: t-statistic
|
||||
|
||||
t = \frac{\bar{x} - \mu}{s/\sqrt{N}}
|
||||
|
||||
where :math:`\bar{x}` is the sample mean from equation :eq:`sample-mean` and
|
||||
:math:`s` is the standard deviation based on equation
|
||||
:eq:`unbiased-variance`. If the random variables :math:`X_i` are
|
||||
normally-distributed, then the t-statistic has a `Student's t-distribution`_
|
||||
with :math:`N-1` degrees of freedom. This implies that
|
||||
|
||||
.. math::
|
||||
:label: t-probability
|
||||
|
||||
Pr \left ( -t_{1 - \alpha/2, N - 1} \le \frac{\bar{x} - \mu}{s/\sqrt{N}} \le
|
||||
t_{1 - \alpha/2, N - 1} \right ) = 1 - \alpha
|
||||
|
||||
where :math:`t_{1-\alpha/2, N-1}` is the :math:`1 - \alpha/2` percentile of a
|
||||
t-distribution with :math:`N-1` degrees of freedom. Thus, the :math:`1 - \alpha`
|
||||
two sided confidence interval for the sample mean is
|
||||
|
||||
.. math::
|
||||
:label: two-sided-ci
|
||||
|
||||
\bar{x} \pm t_{1 - \alpha/2, N-1} \frac{s}{\sqrt{N}}.
|
||||
|
||||
One should be cautioned that equation :eq:`two-sided-ci` only applies if the
|
||||
*underlying random variables* are normally-distributed. In general, this may not
|
||||
be true for a tally random variable --- the central limit theorem guarantees
|
||||
only that the sample mean is normally distributed, not the underlying random
|
||||
variable. If batching is used, then the underlying random variable, which would
|
||||
then be the averages from each batch, will be normally distributed as long as
|
||||
the conditions of the central limit theorem are met.
|
||||
|
||||
Let us now outline the method used to calculate the percentile of the Student's
|
||||
t-distribution. For one or two degrees of freedom, the percentile can be written
|
||||
analytically. For one degree of freedom, the t-distribution becomes a standard
|
||||
`Cauchy distribution`_ whose cumulative distribution function is
|
||||
|
||||
.. math::
|
||||
:label: cauchy-cdf
|
||||
|
||||
c(x) = \frac{1}{\pi} \arctan x + \frac{1}{2}.
|
||||
|
||||
Thus, inverting the cumulative distribution function, we find the :math:`x`
|
||||
percentile of the standard Cauchy distribution to be
|
||||
|
||||
.. math::
|
||||
:label: percentile-1
|
||||
|
||||
t_{x,1} = \tan \left ( \pi \left ( x - \frac{1}{2} \right ) \right ).
|
||||
|
||||
For two degrees of freedom, the cumulative distribution function is the
|
||||
second-degree polynomial
|
||||
|
||||
.. math::
|
||||
:label: t-2-polynomial
|
||||
|
||||
c(x) = \frac{1}{2} + \frac{x}{2\sqrt{x^2 + 2}}
|
||||
|
||||
Solving for :math:`x`, we find the :math:`x` percentile to be
|
||||
|
||||
.. math::
|
||||
:label: percentile-2
|
||||
|
||||
t_{x,2} = \frac{2\sqrt{2} (x - 1/2)}{\sqrt{1 - 4 (x - 1/2)^2}}
|
||||
|
||||
For degrees of freedom greater than two, it is not possible to obtain an
|
||||
analytical formula for the inverse of the cumulative distribution function. We
|
||||
must resort to either numerically solving for the inverse or to an
|
||||
approximation. Approximations for percentiles of the t-distribution have been
|
||||
found with high levels of accuracy. OpenMC uses the `following approximation`_:
|
||||
|
||||
.. math::
|
||||
:label: percentile-n
|
||||
|
||||
t_{x,n} = \sqrt{\frac{n}{n-2}} \left ( z_x + \frac{1}{4} \frac{z_x^3 -
|
||||
3z_x}{n-2} + \frac{1}{96} \frac{5z_x^5 - 56z_x^3 + 75z_x}{(n-2)^2} +
|
||||
\frac{1}{384} \frac{3z_x^7 - 81z_x^5 + 417z_x^3 - 315z_x}{(n-2)^3} \right )
|
||||
|
||||
where :math:`z_x` is the :math:`x` percentile of the standard normal
|
||||
distribution. In order to determine an arbitrary percentile of the standard
|
||||
normal distribution, we use an `unpublished rational approximation`_. After
|
||||
using the rational approximation, one iteration of Newton's method is applied to
|
||||
improve the estimate of the percentile.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. rubric:: References
|
||||
|
||||
.. _following approximation: https://doi.org/10.1080/03610918708812641
|
||||
|
||||
.. _Bessel's correction: https://en.wikipedia.org/wiki/Bessel's_correction
|
||||
|
||||
.. _random variable: https://en.wikipedia.org/wiki/Random_variable
|
||||
|
||||
.. _stochastic process: https://en.wikipedia.org/wiki/Stochastic_process
|
||||
|
||||
.. _independent, identically-distributed random variables: https://en.wikipedia.org/wiki/Independent_and_identically_distributed_random_variables
|
||||
|
||||
.. _law of large numbers: https://en.wikipedia.org/wiki/Law_of_large_numbers
|
||||
|
||||
.. _expected value: https://en.wikipedia.org/wiki/Expected_value
|
||||
|
||||
.. _converges in probability: https://en.wikipedia.org/wiki/Convergence_of_random_variables#Convergence_in_probability
|
||||
|
||||
.. _normal distribution: https://en.wikipedia.org/wiki/Normal_distribution
|
||||
|
||||
.. _converges in distribution: https://en.wikipedia.org/wiki/Convergence_of_random_variables#Convergence_in_distribution
|
||||
|
||||
.. _confidence intervals: https://en.wikipedia.org/wiki/Confidence_interval
|
||||
|
||||
.. _Student's t-distribution: https://en.wikipedia.org/wiki/Student%27s_t-distribution
|
||||
|
||||
.. _Cauchy distribution: https://en.wikipedia.org/wiki/Cauchy_distribution
|
||||
|
||||
.. _unpublished rational approximation: https://web.archive.org/web/20150926021742/http://home.online.no/~pjacklam/notes/invnorm/
|
||||
|
||||
.. _MC21: http://www.osti.gov/bridge/servlets/purl/903083-HT5p1o/903083.pdf
|
||||
550
docs/source/publications.rst
Normal file
550
docs/source/publications.rst
Normal file
|
|
@ -0,0 +1,550 @@
|
|||
.. _publications:
|
||||
|
||||
============
|
||||
Publications
|
||||
============
|
||||
|
||||
---------
|
||||
Overviews
|
||||
---------
|
||||
|
||||
- Paul K. Romano, Nicholas E. Horelik, Bryan R. Herman, Adam G. Nelson, Benoit
|
||||
Forget, and Kord Smith, "`OpenMC: A State-of-the-Art Monte Carlo Code for
|
||||
Research and Development <https://doi.org/10.1016/j.anucene.2014.07.048>`_,"
|
||||
*Ann. Nucl. Energy*, **82**, 90--97 (2015).
|
||||
|
||||
- Paul K. Romano, Bryan R. Herman, Nicholas E. Horelik, Benoit Forget, Kord
|
||||
Smith, and Andrew R. Siegel, "Progress and Status of the OpenMC Monte Carlo
|
||||
Code," *Proc. Int. Conf. Mathematics and Computational Methods Applied to
|
||||
Nuclear Science and Engineering*, Sun Valley, Idaho, May 5--9 (2013).
|
||||
|
||||
- Paul K. Romano and Benoit Forget, "`The OpenMC Monte Carlo Particle Transport
|
||||
Code <https://doi.org/10.1016/j.anucene.2012.06.040>`_,"
|
||||
*Ann. Nucl. Energy*, **51**, 274--281 (2013).
|
||||
|
||||
------------
|
||||
Benchmarking
|
||||
------------
|
||||
|
||||
- Travis J. Labossiere-Hickman and Benoit Forget, "Selected VERA Core Physics
|
||||
Benchmarks in OpenMC," *Trans. Am. Nucl. Soc.*, **117**, 1520-1523 (2017).
|
||||
|
||||
- Khurrum S. Chaudri and Sikander M. Mirza, "`Burnup dependent Monte Carlo
|
||||
neutron physics calculations of IAEA MTR benchmark
|
||||
<https://doi.org/10.1016/j.pnucene.2014.12.018>`_," *Prog. Nucl. Energy*,
|
||||
**81**, 43-52 (2015).
|
||||
|
||||
- Daniel J. Kelly, Brian N. Aviles, Paul K. Romano, Bryan R. Herman,
|
||||
Nicholas E. Horelik, and Benoit Forget, "Analysis of select BEAVRS PWR
|
||||
benchmark cycle 1 results using MC21 and OpenMC," *Proc. PHYSOR*, Kyoto,
|
||||
Japan, Sep. 28--Oct. 3 (2014).
|
||||
|
||||
- Bryan R. Herman, Benoit Forget, Kord Smith, Paul K. Romano, Thomas M. Sutton,
|
||||
Daniel J. Kelly, III, and Brian N. Aviles, "Analysis of tally correlations in
|
||||
large light water reactors," *Proc. PHYSOR*, Kyoto, Japan, Sep. 28--Oct. 3
|
||||
(2014).
|
||||
|
||||
- Nicholas Horelik, Bryan Herman, Benoit Forget, and Kord Smith, "Benchmark for
|
||||
Evaluation and Validation of Reactor Simulations,"
|
||||
*Proc. Int. Conf. Mathematics and Computational Methods Applied to Nuclear
|
||||
Science and Engineering*, Sun Valley, Idaho, May 5--9 (2013).
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, and Kord S. Smith, "Validation of OpenMC
|
||||
Reactor Physics Simulations with the B&W 1810 Series Benchmarks,"
|
||||
*Trans. Am. Nucl. Soc.*, **109**, 1301--1304 (2013).
|
||||
|
||||
--------------------------
|
||||
Coupling and Multi-physics
|
||||
--------------------------
|
||||
|
||||
- Miriam A. Kreher, Benoit Forget, and Kord Smith, "Single-Batch Monte Carlo
|
||||
Multiphysics Coupling," *Proc. M&C*, 1789-1797, Portland, Oregon, Aug. 25-29
|
||||
(2019).
|
||||
|
||||
- Ze-Long Zhao, Yongwei Yang, and Shuang Hong, "`Application of FLUKA and OpenMC
|
||||
in coupled physics calculation of target and subcritical reactor for ADS
|
||||
<https://doi.org/10.1007/s41365-018-0539-1>`_," *Nucl. Sci. Tech.*, **30**: 10
|
||||
(2019).
|
||||
|
||||
- April Novak, Paul Romano, Brycen Wendt, Ron Rahaman, Elia Merzari, Leslie
|
||||
Kerby, Cody Permann, Richard Martineau, and Rachel N. Slaybaugh, "Preliminary
|
||||
Coupling of OpenMC and Nek5000 within the MOOSE Framework," *Proc. PHYSOR*,
|
||||
Cancun, Mexico, Apr. 22-26 (2018).
|
||||
|
||||
- Jun Chen, Liangzhi Cao, Chuanqi Zhao, and Zhouyu Liu, "`Development of
|
||||
Subchannel Code SUBSC for high-fidelity multi-physics coupling application
|
||||
<https://doi.org/10.1016/j.egypro.2017.08.121>`_", *Energy Procedia*, **127**,
|
||||
264-274 (2017).
|
||||
|
||||
- Tianliang Hu, Liangzhu Cao, Hongchun Wu, Xianan Du, and Mingtao He, "`Coupled
|
||||
neutrons and thermal-hydraulics simulation of molten salt reactors based on
|
||||
OpenMC/TANSY <https://doi.org/10.1016/j.anucene.2017.05.002>`_,"
|
||||
*Ann. Nucl. Energy*, **109**, 260-276 (2017).
|
||||
|
||||
- Matthew Ellis, Derek Gaston, Benoit Forget, and Kord Smith, "`Preliminary
|
||||
Coupling of the Monte Carlo Code OpenMC and the Multiphysics Object-Oriented
|
||||
Simulation Environment for Analyzing Doppler Feedback in Monte Carlo
|
||||
Simulations <https://doi.org/10.13182/NSE16-26>`_," *Nucl. Sci. Eng.*,
|
||||
**185**, 184-193 (2017).
|
||||
|
||||
- Matthew Ellis, Benoit Forget, Kord Smith, and Derek Gaston, "Continuous
|
||||
Temperature Representation in Coupled OpenMC/MOOSE Simulations," *Proc. PHYSOR
|
||||
2016*, Sun Valley, Idaho, May 1-5, 2016.
|
||||
|
||||
- Antonios G. Mylonakis, Melpomeni Varvayanni, and Nicolas Catsaros,
|
||||
"`Investigating a Matrix-free, Newton-based, Neutron-Monte
|
||||
Carlo/Thermal-Hydraulic Coupling Scheme
|
||||
<https://www.researchgate.net/publication/282001032>`_",
|
||||
*Proc. Int. Conf. Nuclear Energy for New Europe*, Portoroz, Slovenia, Sep
|
||||
.14-17 (2015).
|
||||
|
||||
- Matt Ellis, Benoit Forget, Kord Smith, and Derek Gaston, "Preliminary coupling
|
||||
of the Monte Carlo code OpenMC and the Multiphysics Object-Oriented Simulation
|
||||
Environment (MOOSE) for analyzing Doppler feedback in Monte Carlo
|
||||
simulations," *Proc. Joint Int. Conf. M&C+SNA+MC*, Nashville, Tennessee,
|
||||
Apr. 19--23 (2015).
|
||||
|
||||
- Bryan R. Herman, Benoit Forget, and Kord Smith, "`Progress toward Monte
|
||||
Carlo-thermal hydraulic coupling using low-order nonlinear diffusion
|
||||
acceleration methods <https://doi.org/10.1016/j.anucene.2014.10.029>`_,"
|
||||
*Ann. Nucl. Energy*, **84**, 63-72 (2015).
|
||||
|
||||
- Bryan R. Herman, Benoit Forget, and Kord Smith, "Utilizing CMFD in OpenMC to
|
||||
Estimate Dominance Ratio and Adjoint," *Trans. Am. Nucl. Soc.*, **109**,
|
||||
1389-1392 (2013).
|
||||
|
||||
--------------------------
|
||||
Geometry and Visualization
|
||||
--------------------------
|
||||
|
||||
- Sterling Harper, Paul Romano, Benoit Forget, and Kord Smith, "Efficient
|
||||
dynamic threadsafe neighbor lists for Monte Carlo ray tracing," *Proc. M&C*,
|
||||
918-926, Portland, Oregon, Aug. 25-29 (2019).
|
||||
|
||||
- Jin-Yang Li, Long Gu, Hu-Shan Xu, Nadezha Korepanova, Rui Yu, Yan-Lei Zhu, and
|
||||
Chang-Ping Qin, "`CAD modeling study on FLUKA and OpenMC for accelerator
|
||||
driven system simulation <https://doi.org/10.1016/j.anucene.2017.12.050>`_",
|
||||
*Ann. Nucl. Energy*, **114**, 329-341 (2018).
|
||||
|
||||
- Logan Abel, William Boyd, Benoit Forget, and Kord Smith, "Interactive
|
||||
Visualization of Multi-Group Cross Sections on High-Fidelity Spatial Meshes,"
|
||||
*Trans. Am. Nucl. Soc.*, **114**, 391-394 (2016).
|
||||
|
||||
- Derek M. Lax, "`Memory efficient indexing algorithm for physical properties in
|
||||
OpenMC <http://hdl.handle.net/1721.1/97862>`_," S. M. Thesis, Massachusetts
|
||||
Institute of Technology (2015).
|
||||
|
||||
- Derek Lax, William Boyd, Nicholas Horelik, Benoit Forget, and Kord Smith, "A
|
||||
memory efficient algorithm for classifying unique regions in constructive
|
||||
solid geometries," *Proc. PHYSOR*, Kyoto, Japan, Sep. 28--Oct. 3 (2014).
|
||||
|
||||
-------------
|
||||
Miscellaneous
|
||||
-------------
|
||||
|
||||
- Shikhar Kumar, Benoit Forget, and Kord Smith, "Analysis of fission source
|
||||
convergence for a 3-D SMR core using functional expansion tallies," *Proc.
|
||||
M&C*, 937-947, Portland, Oregon, Aug. 25-29 (2019).
|
||||
|
||||
- Faisal Qayyum, Muhammad R. Ali, Awais Zahur, and R. Khan, "`Improvements in
|
||||
methodology to determine feedback reactivity coefficients
|
||||
<https://doi.org/10.1007/s41365-019-0588-0>`_," *Nucl. Sci. Tech.*, **30**: 63
|
||||
(2019).
|
||||
|
||||
- M. Sajjad, Muhammad Rizwan Ali, M. Naveed Ashraf, Rustam Khan, Tasneem Fatima,
|
||||
"`KANUPP Reactor Core Model and its Validation
|
||||
<https://doi.org/10.1109/PGSRET.2018.8685948>`_," International Conference on
|
||||
Power Generation Systems and Renewable Energy Technologies, Islamabad,
|
||||
Pakistan, Sep. 10-12 (2018).
|
||||
|
||||
- Muhammad Waqas Tariq, Muhammad Sohail, and Sikander Majid Mirza, "`Calculation
|
||||
of Neutronic Parameters using OpenMC for Potential Dispersed Fuels of MNSR
|
||||
<https://doi.org/10.1109/PGSRET.2018.8685927>`_," International Conference on
|
||||
Power Generation Systems and Renewable Energy Technologies, Islamabad,
|
||||
Pakistan, Sep. 10-12 (2018).
|
||||
|
||||
- Amanda L. Lund and Paul K. Romano, "`Implementation and Validation of Photon
|
||||
Transport in OpenMC <https://doi.org/10.2172/1490825>`_", Argonne National
|
||||
Laboratory, Technical Report ANL/MCS-TM-381 (2018).
|
||||
|
||||
- Bruno Merk, Dzianis Litskevich, R. Gregg, and A. R. Mount, "`Demand driven
|
||||
salt clean-up in a molten salt fast reactor -- Defining a priority list
|
||||
<https://doi.org/10.1371/journal.pone.0192020>`_", *PLOS One*, **13**,
|
||||
e0192020 (2018).
|
||||
|
||||
- Adam G. Nelson, Samuel Shaner, William Boyd, and Paul K. Romano,
|
||||
"Incorporation of a Multigroup Transport Capability in the OpenMC Monte Carlo
|
||||
Particle Transport Code," *Trans. Am. Nucl. Soc.*, **117**, 679-681 (2017).
|
||||
|
||||
- Youqi Zheng, Yunlong Xiao, and Hongchun Wu, "`Application of the virtual
|
||||
density theory in fast reactor analysis based on the neutron transport
|
||||
calculation <https://doi.org/10.1016/j.nucengdes.2017.05.020>`_,"
|
||||
*Nucl. Eng. Des.*, **320**, 200-206 (2017).
|
||||
|
||||
- Amanda L. Lund, Paul K. Romano, and Andrew R. Siegel, "Accelerating Source
|
||||
Convergence in Monte Carlo Criticality Calculations Using a Particle Ramp-Up
|
||||
Technique," *Proc. Int. Conf. Mathematics & Computational Methods Applied to
|
||||
Nuclear Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- Antonios G. Mylonakis, M. Varvayanni, D.G.E. Grigoriadis, and N. Catsaros,
|
||||
"Developing and investigating a pure Monte-Carlo module for transient neutron
|
||||
transport analysis," *Ann. Nucl. Energy*, **104**, 103-112 (2017).
|
||||
|
||||
- Timothy P. Burke, Brian C. Kiedrowski, William R. Martin, and
|
||||
Forrest B. Brown, "GPU Acceleration of Kernel Density Estimators in Monte
|
||||
Carlo Neutron Transport Simulations," *Trans. Am. Nucl. Soc.*, **115**,
|
||||
531-534 (2016).
|
||||
|
||||
- Timothy P. Burke, Brian C. Kiedrowski, and William R. Martin, "Cylindrical
|
||||
Kernel Density Estimators for Monte Carlo Neutron Transport Reactor Physics
|
||||
Problems," *Trans. Am. Nucl. Soc.*, **115**, 563-566 (2016).
|
||||
|
||||
- Yunzhao Li, Qingming He, Liangzhi Cao, Hongchun Wu, and Tiejun Zu, "`Resonance
|
||||
Elastic Scattering and Interference Effects Treatments in Subgroup Method
|
||||
<https://doi.org/10.1016/j.net.2015.12.015>`_," *Nucl. Eng. Tech.*, **48**,
|
||||
339-350 (2016).
|
||||
|
||||
- William Boyd, Sterling Harper, and Paul K. Romano, "Equipping OpenMC for the
|
||||
big data era," *Proc. PHYSOR*, Sun Valley, Idaho, May 1-5, 2016.
|
||||
|
||||
- Michal Kostal, Vojtech Rypar, Jan Milcak, Vlastimil Juricek, Evzen Losa,
|
||||
Benoit Forget, and Sterling Harper, "`Study of graphite reactivity worth on
|
||||
well-defined cores assembled on LR-0 reactor
|
||||
<https://doi.org/10.1016/j.anucene.2015.10.010>`_," *Ann. Nucl. Energy*,
|
||||
**87**, 601-611 (2016).
|
||||
|
||||
- Qicang Shen, William Boyd, Benoit Forget, and Kord Smith, "Tally precision
|
||||
triggers for the OpenMC Monte Carlo code," *Trans. Am. Nucl. Soc.*, **112**,
|
||||
637-640 (2015).
|
||||
|
||||
- Kyungkwan Noh and Deokjung Lee, "Whole Core Analysis using OpenMC Monte Carlo
|
||||
Code," *Trans. Kor. Nucl. Soc. Autumn Meeting*, Gyeongju, Korea,
|
||||
Oct. 24-25, 2013.
|
||||
|
||||
- Timothy P. Burke, Brian C. Kiedrowski, and William R. Martin, "Flux and
|
||||
Reaction Rate Kernel Density Estimators in OpenMC," *Trans. Am. Nucl. Soc.*,
|
||||
**109**, 683-686 (2013).
|
||||
|
||||
-----------------------------------
|
||||
Multigroup Cross Section Generation
|
||||
-----------------------------------
|
||||
|
||||
- William Boyd, Adam Nelson, Paul K. Romano, Samuel Shaner, Benoit Forget, and
|
||||
Kord Smith, "`Multigroup Cross-Section Generation with the OpenMC Monte Carlo
|
||||
Particle Transport Code <https://doi.org/10.1080/00295450.2019.1571828>`_,"
|
||||
*Nucl. Technol.* (2019).
|
||||
|
||||
- William Boyd, Benoit Forget, and Kord Smith, "`A single-step framework to
|
||||
generate spatially self-shielded multi-group cross sections from Monte Carlo
|
||||
transport simulations <https://doi.org/10.1016/j.anucene.2018.11.017>`_,"
|
||||
*Ann. Nucl. Energy*, **125**, 261-271 (2019).
|
||||
|
||||
- Kun Zhuang, Xiaobin Tang, and Liangzhi Cao, "`Development and verification of
|
||||
a model for generation of MSFR few-group homogenized cross-sections based on a
|
||||
Monte Carlo code OpenMC <https://doi.org/10.1016/j.anucene.2018.09.037>`_,"
|
||||
*Ann. Nucl. Energy*, **124**, 187-197 (2019).
|
||||
|
||||
- Changho Lee and Yeon Sang Jung, "Verification of the Cross Section Library
|
||||
Generated Using OpenMC and MC\ :sup:`2`-3 for PROTEUS," *Proc. PHYSOR*, Cancun,
|
||||
Mexico, Apr. 22-26 (2018).
|
||||
|
||||
- Zhaoyuan Liu, Kord Smith, Benoit Forget, and Javier Ortensi, "`Cumulative
|
||||
migration method for computing rigorous diffusion coefficients and transport
|
||||
cross sections from Monte Carlo
|
||||
<https://doi.org/10.1016/j.anucene.2017.10.039>`_," *Ann. Nucl. Energy*,
|
||||
**112**, 507-516 (2018).
|
||||
|
||||
- Gang Yang, Tongkyu Park, and Won Sik Yang, "Effects of Fuel Salt Velocity
|
||||
Field on Neutronics Performances in Molten Salt Reactors with Open Flow
|
||||
Channels," *Trans. Am. Nucl. Soc.*, **117**, 1339-1342 (2017).
|
||||
|
||||
- William Boyd, Nathan Gibson, Benoit Forget, and Kord Smith, "`An analysis of
|
||||
condensation errors in multi-group cross section generation for fine-mesh
|
||||
neutron transport calculations
|
||||
<https://doi.org/10.1016/j.anucene.2017.09.052>`_," *Ann. Nucl. Energy*,
|
||||
**112**, 267-276 (2018).
|
||||
|
||||
- Hong Shuang, Yang Yongwei, Zhang Lu, and Gao Yucui, "`Fabrication and
|
||||
validation of multigroup cross section library based on the OpenMC code
|
||||
<https://doi.org/10.11889/j.0253-3219.2017.hjs.40.040502>`_,"
|
||||
*Nucl. Techniques* **40** (4), 040504 (2017). (in Mandarin)
|
||||
|
||||
- Nicholas E. Stauff, Changho Lee, Paul K. Romano, and Taek K. Kim,
|
||||
"Verification of Mixed Stochastic/Deterministic Approach for Fast and Thermal
|
||||
Reactor Analysis," *Proc. ICAPP*, Fukui and Kyoto, Japan, Apr. 24-28, 2017.
|
||||
|
||||
- Zhauyuan Liu, Kord Smith, and Benoit Forget, "Progress of Cumulative Migration
|
||||
Method for Computing Diffusion Coefficients with OpenMC,"
|
||||
*Proc. Int. Conf. Mathematics & Computational Methods Applied to Nuclear
|
||||
Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- Geoffrey Gunow, Samuel Shaner, William Boyd, Benoit Forget, and Kord Smith,
|
||||
"Accuracy and Performance of 3D MOC for Full-Core PWR Problems,"
|
||||
*Proc. Int. Conf. Mathematics & Computational Methods Applied to Nuclear
|
||||
Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- Tianliang Hu, Liangzhi Cao, Hongchun Wu, and Kun Zhuang, "A coupled neutronics
|
||||
and thermal-hydraulic modeling approach to the steady-state and dynamic
|
||||
behavior of MSRs," *Proc. Int. Conf. Mathematics & Computational Methods
|
||||
Applied to Nuclear Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- William R. D. Boyd, "Reactor Agnostic Multi-Group Cross Section Generation for
|
||||
Fine-Mesh Deterministic Neutron Transport Simulations," Ph.D. Thesis,
|
||||
Massachusetts Institute of Technology (2017).
|
||||
|
||||
- Zhaoyuan Liu, Kord Smith, and Benoit Forget, "A Cumulative Migration Method
|
||||
for Computing Rigorous Transport Cross Sections and Diffusion Coefficients for
|
||||
LWR Lattices with Monte Carlo," *Proc. PHYSOR*, Sun Valley, Idaho, May
|
||||
1-5, 2016.
|
||||
|
||||
- Adam G. Nelson and William R. Martin, "Improved Monte Carlo tallying of
|
||||
multi-group scattering moments using the NDPP code," *Trans. Am. Nucl. Soc.*,
|
||||
**113**, 645-648 (2015)
|
||||
|
||||
- Adam G. Nelson and William R. Martin, "Improved Monte Carlo tallying of
|
||||
multi-group scattering moment matrices," *Trans. Am. Nucl. Soc.*, **110**,
|
||||
217-220 (2014).
|
||||
|
||||
- Adam G. Nelson and William R. Martin, "Improved Convergence of Monte Carlo
|
||||
Generated Multi-Group Scattering Moments," *Proc. Int. Conf. Mathematics and
|
||||
Computational Methods Applied to Nuclear Science and Engineering*, Sun Valley,
|
||||
Idaho, May 5--9 (2013).
|
||||
|
||||
|
||||
------------------
|
||||
Doppler Broadening
|
||||
------------------
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, Kord S. Smith, and Forrest B. Brown,
|
||||
"`On-the-fly Doppler broadening of unresolved resonance region cross sections
|
||||
<https://doi.org/10.1016/j.pnucene.2017.05.032>`_," *Prog. Nucl. Energy*,
|
||||
**101**, 444-460 (2017).
|
||||
|
||||
- Colin Josey, Pablo Ducru, Benoit Forget, and Kord Smith, "`Windowed multipole
|
||||
for cross section Doppler broadening
|
||||
<https://doi.org/10.1016/j.jcp.2015.08.013>`_," *J. Comput. Phys.*, **307**,
|
||||
715-727 (2016).
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, Kord S. Smith, and Forrest B. Brown,
|
||||
"On-the-fly Doppler Broadening of Unresolved Resonance Region Cross Sections
|
||||
via Probability Band Interpolation," *Proc. PHYSOR*, Sun Valley, Idaho, May
|
||||
1-5, 2016.
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, Kord S. Smith, Brian C. Kiedrowski, and
|
||||
Forrest B. Brown, "`Direct, on-the-fly calculation of unresolved resonance
|
||||
region cross sections in Monte Carlo simulations
|
||||
<http://hdl.handle.net/1721.1/108644>`_," *Proc. Joint Int. Conf. M&C+SNA+MC*,
|
||||
Nashville, Tennessee, Apr. 19--23 (2015).
|
||||
|
||||
- Colin Josey, Benoit Forget, and Kord Smith, "`Windowed multipole sensitivity
|
||||
to target accuracy of the optimization procedure
|
||||
<https://doi.org/10.1080/00223131.2015.1035353>`_,"
|
||||
*J. Nucl. Sci. Technol.*, **52**, 987-992 (2015).
|
||||
|
||||
- Paul K. Romano and Timothy H. Trumbull, "`Comparison of algorithms for Doppler
|
||||
broadening pointwise tabulated cross sections
|
||||
<https://doi.org/10.1016/j.anucene.2014.08.046>`_," *Ann. Nucl. Energy*,
|
||||
**75**, 358--364 (2015).
|
||||
|
||||
- Tuomas Viitanen, Jaakko Leppanen, and Benoit Forget, "Target motion sampling
|
||||
temperature treatment technique with track-length esimators in OpenMC --
|
||||
Preliminary results," *Proc. PHYSOR*, Kyoto, Japan, Sep. 28--Oct. 3 (2014).
|
||||
|
||||
- Benoit Forget, Sheng Xu, and Kord Smith, "`Direct Doppler broadening in Monte
|
||||
Carlo simulations using the multipole representation
|
||||
<https://doi.org/10.1016/j.anucene.2013.09.043>`_," *Ann. Nucl. Energy*,
|
||||
**64**, 78--85 (2014).
|
||||
|
||||
------------
|
||||
Nuclear Data
|
||||
------------
|
||||
|
||||
- Jonathan A. Walsh, "Comparison of Unresolved Resonance Region Cross Section
|
||||
Formalisms in Transport Simulations," *Trans. Am. Nucl. Soc.*, **117**,
|
||||
749-752 (2017).
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, Kord S. Smith, and Forrest B. Brown,
|
||||
"`Uncertainty in Fast Reactor-Relevant Critical Benchmark Simulations Due to
|
||||
Unresolved Resonance Structure
|
||||
<https://www.kns.org/files/int_paper/paper/MC2017_2017_3/P197S03-09WalshJ.pdf>`_,"
|
||||
*Proc. Int. Conf. Mathematics & Computational Methods Applied to Nuclear
|
||||
Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- Vivian Y. Tran, Jonathan A. Walsh, and Benoit Forget, "Treatments for Neutron
|
||||
Resonance Elastic Scattering Using the Multipole Formalism in Monte Carlo
|
||||
Codes," *Trans. Am. Nucl. Soc.*, **115**, 1133-1137 (2016).
|
||||
|
||||
- Paul K. Romano and Sterling M. Harper, "Nuclear data processing capabilities
|
||||
in OpenMC", *Proc. Nuclear Data*, Sep. 11-16, 2016.
|
||||
|
||||
- Jonathan A. Walsh, Benoit Froget, Kord S. Smith, and Forrest B. Brown,
|
||||
"`Neutron Cross Section Processing Methods for Improved Integral Benchmarking
|
||||
of Unresolved Resonance Region Evaluations
|
||||
<https://doi.org/10.1051/epjconf/201611106001>`_," *Eur. Phys. J. Web Conf.*
|
||||
**111**, 06001 (2016).
|
||||
|
||||
- Jonathan A. Walsh, Paul K. Romano, Benoit Forget, and Kord S. Smith,
|
||||
"`Optimizations of the energy grid search algorithm in continuous-energy Monte
|
||||
Carlo particle transport codes
|
||||
<https://doi.org/10.1016/j.cpc.2015.05.025>`_", *Comput. Phys. Commun.*,
|
||||
**196**, 134-142 (2015).
|
||||
|
||||
- Amanda L. Lund, Andrew R. Siegel, Benoit Forget, Colin Josey, and
|
||||
Paul K. Romano, "Using fractional cascading to accelerate cross section
|
||||
lookups in Monte Carlo particle transport calculations," *Proc. Joint
|
||||
Int. Conf. M&C+SNA+MC*, Nashville, Tennessee, Apr. 19--23 (2015).
|
||||
|
||||
- Ronald O. Rahaman, Andrew R. Siegel, and Paul K. Romano, "Monte Carlo
|
||||
performance analysis for varying cross section parameter regimes,"
|
||||
*Proc. Joint Int. Conf. M&C+SNA+MC*, Nashville, Tennessee, Apr. 19--23 (2015).
|
||||
|
||||
- Jonathan A. Walsh, Benoit Forget, and Kord S. Smith, "`Accelerated sampling of
|
||||
the free gas resonance elastic scattering kernel
|
||||
<https://doi.org/10.1016/j.anucene.2014.01.017>`_," *Ann. Nucl. Energy*,
|
||||
**69**, 116--124 (2014).
|
||||
|
||||
-----------
|
||||
Parallelism
|
||||
-----------
|
||||
|
||||
- Paul K. Romano and Andrew R. Siegel, "`Limits on the efficiency of event-based
|
||||
algorithms for Monte Carlo neutron transport
|
||||
<https://www.kns.org/files/int_paper/paper/MC2017_2017_2/P099S02-02RomanoP.pdf>`_,"
|
||||
*Proc. Int. Conf. Mathematics & Computational Methods Applied to Nuclear
|
||||
Science and Engineering*, Jeju, Korea, Apr. 16-20, 2017.
|
||||
|
||||
- Paul K. Romano, John R. Tramm, and Andrew R. Siegel, "Efficacy of hardware
|
||||
threading for Monte Carlo particle transport calculations on multi- and
|
||||
many-core systems," *PHYSOR 2016*, Sun Valley, Idaho, May 1-5, 2016.
|
||||
|
||||
- David Ozog, Allen D. Malony, and Andrew R. Siegel, "A performance analysis of
|
||||
SIMD algorithms for Monte Carlo simulations of nuclear reactor cores,"
|
||||
*Proc. IEEE Int. Parallel and Distributed Processing Symposium*, Hyderabad,
|
||||
India, May 25--29 (2015).
|
||||
|
||||
- David Ozog, Allen D. Malony, and Andrew Siegel, "Full-core PWR transport
|
||||
simulations on Xeon Phi clusters," *Proc. Joint Int. Conf. M&C+SNA+MC*,
|
||||
Nashville, Tennessee, Apr. 19--23 (2015).
|
||||
|
||||
- Paul K. Romano, Andrew R. Siegel, and Ronald O. Rahaman, "Influence of the
|
||||
memory subsystem on Monte Carlo code performance," *Proc. Joint
|
||||
Int. Conf. M&C+SNA+MC*, Nashville, Tennessee, Apr. 19--23 (2015).
|
||||
|
||||
- Hajime Fujita, Nan Dun, Aiman Fang, Zachary A. Rubinstein, Ziming Zheng, Kamil
|
||||
Iskra, Jeff Hammonds, Anshu Dubey, Pavan Balaji, and Andrew A. Chien, "Using
|
||||
Global View Resilience (GVR) to add Resilience to Exascale Applications,"
|
||||
*Proc. Supercomputing*, New Orleans, Louisiana, Nov. 16--21, 2014.
|
||||
|
||||
- Nicholas Horelik, Benoit Forget, Kord Smith, and Andrew Siegel, "Domain
|
||||
decomposition and terabyte tallies with the OpenMC Monte Carlo neutron
|
||||
transport code," *Proc. PHYSOR*, Kyoto Japan, Sep. 28--Oct. 3 (2014).
|
||||
|
||||
- John R. Tramm, Andrew R. Siegel, Tanzima Islam, and Martin Schulz, "XSBench --
|
||||
the development and verification of a performance abstraction for Monte Carlo
|
||||
reactor analysis," *Proc. PHYSOR*, Kyoto, Japan, Sep 28--Oct. 3, 2014.
|
||||
|
||||
- Nicholas Horelik, Andrew Siegel, Benoit Forget, and Kord Smith, "`Monte Carlo
|
||||
domain decomposition for robust nuclear reactor analysis
|
||||
<https://doi.org/10.1016/j.parco.2014.10.001>`_," *Parallel Comput.*,
|
||||
**40**, 646--660 (2014).
|
||||
|
||||
- Andrew Siegel, Kord Smith, Kyle Felker, Paul Romano, Benoit Forget, and Peter
|
||||
Beckman, "`Improved cache performance in Monte Carlo transport calculations
|
||||
using energy banding <https://doi.org/10.1016/j.cpc.2013.10.008>`_,"
|
||||
*Comput. Phys. Commun.*, **185** (4), 1195--1199 (2014).
|
||||
|
||||
- Paul K. Romano, Benoit Forget, Kord Smith, and Andrew Siegel, "`On the use of
|
||||
tally servers in Monte Carlo simulations of light-water reactors
|
||||
<https://doi.org/10.1051/snamc/201404301>`_," *Proc. Joint International
|
||||
Conference on Supercomputing in Nuclear Applications and Monte Carlo*, Paris,
|
||||
France, Oct. 27--31 (2013).
|
||||
|
||||
- Kyle G. Felker, Andrew R. Siegel, Kord S. Smith, Paul K. Romano, and Benoit
|
||||
Forget, "`The energy band memory server algorithm for parallel Monte Carlo
|
||||
calculations <https://doi.org/10.1051/snamc/201404207>`_," *Proc. Joint
|
||||
International Conference on Supercomputing in Nuclear Applications and Monte
|
||||
Carlo*, Paris, France, Oct. 27--31 (2013).
|
||||
|
||||
- John R. Tramm and Andrew R. Siegel, "`Memory Bottlenecks and Memory Contention
|
||||
in Multi-Core Monte Carlo Transport Codes
|
||||
<https://doi.org/10.1051/snamc/201404208>`_," *Proc. Joint International
|
||||
Conference on Supercomputing in Nuclear Applications and Monte Carlo*, Paris,
|
||||
France, Oct. 27--31 (2013).
|
||||
|
||||
- Andrew R. Siegel, Kord Smith, Paul K. Romano, Benoit Forget, and Kyle Felker,
|
||||
"`Multi-core performance studies of a Monte Carlo neutron transport code
|
||||
<https://doi.org/10.1177/1094342013492179>`_," *Int. J. High
|
||||
Perform. Comput. Appl.*, **28** (1), 87--96 (2014).
|
||||
|
||||
- Paul K. Romano, Andrew R. Siegel, Benoit Forget, and Kord Smith, "`Data
|
||||
decomposition of Monte Carlo particle transport simulations via tally servers
|
||||
<https://doi.org/10.1016/j.jcp.2013.06.011>`_," *J. Comput. Phys.*, **252**,
|
||||
20--36 (2013).
|
||||
|
||||
- Andrew R. Siegel, Kord Smith, Paul K. Romano, Benoit Forget, and Kyle Felker,
|
||||
"`The effect of load imbalances on the performance of Monte Carlo codes in LWR
|
||||
analysis <https://doi.org/10.1016/j.jcp.2012.06.012>`_," *J. Comput. Phys.*,
|
||||
**235**, 901--911 (2013).
|
||||
|
||||
|
||||
- Paul K. Romano and Benoit Forget, "Reducing Parallel Communication in Monte
|
||||
Carlo Simulations via Batch Statistics," *Trans. Am. Nucl. Soc.*, **107**,
|
||||
519--522 (2012).
|
||||
|
||||
- Paul K. Romano and Benoit Forget, "`Parallel Fission Bank Algorithms in Monte
|
||||
Carlo Criticality Calculations <https://doi.org/10.13182/NSE10-98>`_,"
|
||||
*Nucl. Sci. Eng.*, **170**, 125--135 (2012).
|
||||
|
||||
---------
|
||||
Depletion
|
||||
---------
|
||||
|
||||
- Jose L. Salcedo-Perez, Benoit Forget, Kord Smith, and Paul Romano, "Hybrid
|
||||
tallies to improve performance in depletion Monte Carlo simulations," *Proc.
|
||||
M&C*, 927-936, Portland, Oregon, Aug. 25-29 (2019).
|
||||
|
||||
- Zhao-Qing Liu, Ze-Long Zhao, Yong-Wei Yang, Yu-Cui Gao, Hai-Yan Meng, and
|
||||
Qing-Yu Gao, "`Development and validation of depletion code system IMPC-Burnup
|
||||
for ADS <https://doi.org/10.1007/s41365-019-0560-z>`_," *Nucl. Sci. Tech.*,
|
||||
**30**: 44 (2019).
|
||||
|
||||
- Colin Josey, Benoit Forget, and Kord Smith, "`High order methods for the
|
||||
integration of the Bateman equations and other problems of the form of y' =
|
||||
F(y,t)y <https://doi.org/10.1016/j.jcp.2017.08.025>`_," *J. Comput. Phys.*,
|
||||
**350**, 296-313 (2017).
|
||||
|
||||
- Matthew S. Ellis, Colin Josey, Benoit Forget, and Kord Smith, "`Spatially
|
||||
Continuous Depletion Algorithm for Monte Carlo Simulations
|
||||
<http://hdl.handle.net/1721.1/107880>`_," *Trans. Am. Nucl. Soc.*, **115**,
|
||||
1221-1224 (2016).
|
||||
|
||||
- Anas Gul, K. S. Chaudri, R. Khan, and M. Azeen, "`Development and verification
|
||||
of LOOP: A Linkage of ORIGEN2.2 and OpenMC
|
||||
<https://doi.org/10.1016/j.anucene.2016.09.016>`_," *Ann. Nucl. Energy*,
|
||||
**99**, 321--327 (2017).
|
||||
|
||||
- Kai Huang, Hongchun Wu, Yunzhao Li, and Liangzhi Cao, "Generalized depletion
|
||||
chain simplification based of significance analysis," *Proc. PHYSOR*, Sun
|
||||
Valley, Idaho, May 1-5, 2016.
|
||||
|
||||
--------------------
|
||||
Sensitivity Analysis
|
||||
--------------------
|
||||
|
||||
- Abdulla Alhajri and Benoit Forget, "Eigenvalue Sensitivity in Monte Carlo
|
||||
Simulations to Nuclear Data Parameters using the Multipole Formalism," *Proc.
|
||||
M&C*, 1895-1906, Portland, Oregon, Aug. 25-29 (2019).
|
||||
|
||||
- Xingjie Peng, Jingang Liang, Benoit Forget, and Kord Smith, "`Calculation of
|
||||
adjoint-weighted reactor kinetics parameters in OpenMC
|
||||
<https://doi.org/10.1016/j.anucene.2019.01.007>`_", *Ann. Nucl. Energy*,
|
||||
**128**, 231-235 (2019).
|
||||
|
||||
- Zeyun Wu, Jingang Liang, Xingjie Peng, and Hany S. Abdel-Khalik, "`GPT-Free
|
||||
Sensitivity Analysis for Monte Carlo Models
|
||||
<https://doi.org/10.1080/00295450.2018.1556062>`_", *Nucl. Technol.* (2019).
|
||||
|
||||
- Xingjie Peng, Jingang Liang, Abdulla Alhajri, Benoit Forget, and Kord Smith,
|
||||
"`Development of continuous-energy sensitivity analysis capability in OpenMC
|
||||
<https://doi.org/10.1016/j.anucene.2017.06.061>`_", *Ann. Nucl. Energy*,
|
||||
**110**, 362-383 (2017).
|
||||
222
docs/source/pythonapi/base.rst
Normal file
222
docs/source/pythonapi/base.rst
Normal file
|
|
@ -0,0 +1,222 @@
|
|||
------------------------------------
|
||||
:mod:`openmc` -- Basic Functionality
|
||||
------------------------------------
|
||||
|
||||
Handling nuclear data
|
||||
---------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.XSdata
|
||||
openmc.MGXSLibrary
|
||||
|
||||
Simulation Settings
|
||||
-------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Source
|
||||
openmc.VolumeCalculation
|
||||
openmc.Settings
|
||||
|
||||
Material Specification
|
||||
----------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Nuclide
|
||||
openmc.Element
|
||||
openmc.Macroscopic
|
||||
openmc.Material
|
||||
openmc.Materials
|
||||
|
||||
Cross sections for nuclides, elements, and materials can be plotted using the
|
||||
following function:
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
openmc.plot_xs
|
||||
|
||||
Building geometry
|
||||
-----------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Plane
|
||||
openmc.XPlane
|
||||
openmc.YPlane
|
||||
openmc.ZPlane
|
||||
openmc.XCylinder
|
||||
openmc.YCylinder
|
||||
openmc.ZCylinder
|
||||
openmc.Sphere
|
||||
openmc.Cone
|
||||
openmc.XCone
|
||||
openmc.YCone
|
||||
openmc.ZCone
|
||||
openmc.Quadric
|
||||
openmc.Halfspace
|
||||
openmc.Intersection
|
||||
openmc.Union
|
||||
openmc.Complement
|
||||
openmc.Cell
|
||||
openmc.Universe
|
||||
openmc.RectLattice
|
||||
openmc.HexLattice
|
||||
openmc.Geometry
|
||||
|
||||
Many of the above classes are derived from several abstract classes:
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Surface
|
||||
openmc.Region
|
||||
openmc.Lattice
|
||||
|
||||
.. _pythonapi_tallies:
|
||||
|
||||
Constructing Tallies
|
||||
--------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Filter
|
||||
openmc.UniverseFilter
|
||||
openmc.MaterialFilter
|
||||
openmc.CellFilter
|
||||
openmc.CellFromFilter
|
||||
openmc.CellbornFilter
|
||||
openmc.SurfaceFilter
|
||||
openmc.MeshFilter
|
||||
openmc.MeshSurfaceFilter
|
||||
openmc.EnergyFilter
|
||||
openmc.EnergyoutFilter
|
||||
openmc.MuFilter
|
||||
openmc.PolarFilter
|
||||
openmc.AzimuthalFilter
|
||||
openmc.DistribcellFilter
|
||||
openmc.DelayedGroupFilter
|
||||
openmc.EnergyFunctionFilter
|
||||
openmc.LegendreFilter
|
||||
openmc.SpatialLegendreFilter
|
||||
openmc.SphericalHarmonicsFilter
|
||||
openmc.ZernikeFilter
|
||||
openmc.ZernikeRadialFilter
|
||||
openmc.ParticleFilter
|
||||
openmc.RegularMesh
|
||||
openmc.RectilinearMesh
|
||||
openmc.Trigger
|
||||
openmc.TallyDerivative
|
||||
openmc.Tally
|
||||
openmc.Tallies
|
||||
|
||||
Geometry Plotting
|
||||
-----------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Plot
|
||||
openmc.Plots
|
||||
|
||||
Running OpenMC
|
||||
--------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
openmc.run
|
||||
openmc.calculate_volumes
|
||||
openmc.plot_geometry
|
||||
openmc.plot_inline
|
||||
openmc.search_for_keff
|
||||
|
||||
Post-processing
|
||||
---------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.Particle
|
||||
openmc.StatePoint
|
||||
openmc.Summary
|
||||
|
||||
The following classes and functions are used for functional expansion reconstruction.
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.ZernikeRadial
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
openmc.legendre_from_expcoef
|
||||
|
||||
|
||||
Various classes may be created when performing tally slicing and/or arithmetic:
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.arithmetic.CrossScore
|
||||
openmc.arithmetic.CrossNuclide
|
||||
openmc.arithmetic.CrossFilter
|
||||
openmc.arithmetic.AggregateScore
|
||||
openmc.arithmetic.AggregateNuclide
|
||||
openmc.arithmetic.AggregateFilter
|
||||
|
||||
Coarse Mesh Finite Difference Acceleration
|
||||
------------------------------------------
|
||||
|
||||
CMFD is implemented in OpenMC and allows users to accelerate fission source
|
||||
convergence during inactive neutron batches. To use CMFD, the
|
||||
:class:`openmc.cmfd.CMFDRun` class executes OpenMC through the C API, solving
|
||||
the CMFD system between fission generations and modifying the source weights.
|
||||
Note that the :mod:`openmc.cmfd` module is not imported by default with the
|
||||
:mod:`openmc` namespace and needs to be imported explicitly.
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
openmc.cmfd.CMFDMesh
|
||||
openmc.cmfd.CMFDRun
|
||||
|
||||
At the minimum, a CMFD mesh needs to be specified in order to run CMFD. Once the
|
||||
mesh and other optional properties are set, a simulation can be run with CMFD
|
||||
turned on using :meth:`openmc.cmfd.CMFDRun.run`.
|
||||
51
docs/source/pythonapi/capi.rst
Normal file
51
docs/source/pythonapi/capi.rst
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
------------------------------------------------------
|
||||
:mod:`openmc.lib` -- Python bindings to the C/C++ API
|
||||
------------------------------------------------------
|
||||
|
||||
.. automodule:: openmc.lib
|
||||
|
||||
Functions
|
||||
---------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
calculate_volumes
|
||||
finalize
|
||||
find_cell
|
||||
find_material
|
||||
hard_reset
|
||||
init
|
||||
iter_batches
|
||||
keff
|
||||
load_nuclide
|
||||
next_batch
|
||||
num_realizations
|
||||
plot_geometry
|
||||
reset
|
||||
run
|
||||
run_in_memory
|
||||
simulation_init
|
||||
simulation_finalize
|
||||
source_bank
|
||||
statepoint_write
|
||||
|
||||
Classes
|
||||
-------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
Cell
|
||||
EnergyFilter
|
||||
MaterialFilter
|
||||
Material
|
||||
MeshFilter
|
||||
MeshSurfaceFilter
|
||||
Nuclide
|
||||
RegularMesh
|
||||
Tally
|
||||
202
docs/source/pythonapi/data.rst
Normal file
202
docs/source/pythonapi/data.rst
Normal file
|
|
@ -0,0 +1,202 @@
|
|||
--------------------------------------------
|
||||
:mod:`openmc.data` -- Nuclear Data Interface
|
||||
--------------------------------------------
|
||||
|
||||
.. module:: openmc.data
|
||||
|
||||
Core Classes
|
||||
------------
|
||||
|
||||
The following classes are used for incident neutron data, decay data, fission
|
||||
and product yields.
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
IncidentNeutron
|
||||
Reaction
|
||||
Product
|
||||
FissionEnergyRelease
|
||||
DataLibrary
|
||||
Decay
|
||||
FissionProductYields
|
||||
WindowedMultipole
|
||||
ProbabilityTables
|
||||
|
||||
The following classes are used for storing atomic data (incident photon cross
|
||||
sections, atomic relaxation):
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
IncidentPhoton
|
||||
PhotonReaction
|
||||
AtomicRelaxation
|
||||
|
||||
|
||||
The following classes are used for storing thermal neutron scattering data:
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
ThermalScattering
|
||||
ThermalScatteringReaction
|
||||
CoherentElastic
|
||||
IncoherentElastic
|
||||
|
||||
|
||||
Core Functions
|
||||
--------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
atomic_mass
|
||||
gnd_name
|
||||
linearize
|
||||
thin
|
||||
water_density
|
||||
zam
|
||||
|
||||
One-dimensional Functions
|
||||
-------------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
Function1D
|
||||
Tabulated1D
|
||||
Polynomial
|
||||
Combination
|
||||
Sum
|
||||
Regions1D
|
||||
ResonancesWithBackground
|
||||
|
||||
Angle-Energy Distributions
|
||||
--------------------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
AngleEnergy
|
||||
KalbachMann
|
||||
CorrelatedAngleEnergy
|
||||
UncorrelatedAngleEnergy
|
||||
NBodyPhaseSpace
|
||||
LaboratoryAngleEnergy
|
||||
AngleDistribution
|
||||
EnergyDistribution
|
||||
ArbitraryTabulated
|
||||
GeneralEvaporation
|
||||
MaxwellEnergy
|
||||
Evaporation
|
||||
WattEnergy
|
||||
MadlandNix
|
||||
DiscretePhoton
|
||||
LevelInelastic
|
||||
ContinuousTabular
|
||||
CoherentElasticAE
|
||||
IncoherentElasticAE
|
||||
IncoherentElasticAEDiscrete
|
||||
IncoherentInelasticAEDiscrete
|
||||
|
||||
Resonance Data
|
||||
--------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
Resonances
|
||||
ResonanceRange
|
||||
SingleLevelBreitWigner
|
||||
MultiLevelBreitWigner
|
||||
ReichMoore
|
||||
RMatrixLimited
|
||||
ResonanceCovariances
|
||||
ResonanceCovarianceRange
|
||||
SingleLevelBreitWignerCovariance
|
||||
MultiLevelBreitWignerCovariance
|
||||
ReichMooreCovariance
|
||||
ParticlePair
|
||||
SpinGroup
|
||||
Unresolved
|
||||
|
||||
ACE Format
|
||||
----------
|
||||
|
||||
Classes
|
||||
+++++++
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
ace.Library
|
||||
ace.Table
|
||||
|
||||
Functions
|
||||
+++++++++
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
ace.ascii_to_binary
|
||||
|
||||
ENDF Format
|
||||
-----------
|
||||
|
||||
Classes
|
||||
+++++++
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myclass.rst
|
||||
|
||||
endf.Evaluation
|
||||
|
||||
Functions
|
||||
+++++++++
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
endf.float_endf
|
||||
endf.get_cont_record
|
||||
endf.get_evaluations
|
||||
endf.get_head_record
|
||||
endf.get_tab1_record
|
||||
endf.get_tab2_record
|
||||
endf.get_text_record
|
||||
|
||||
NJOY Interface
|
||||
--------------
|
||||
|
||||
.. autosummary::
|
||||
:toctree: generated
|
||||
:nosignatures:
|
||||
:template: myfunction.rst
|
||||
|
||||
njoy.run
|
||||
njoy.make_pendf
|
||||
njoy.make_ace
|
||||
njoy.make_ace_thermal
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue