Outline CLOVER Archetype

[nsryan2]

This issue is for discussion and outlining of the Core LOading Versatile non-Equilibrium Reactor (CLOVER). There is no need for a PR to close this issue, but the issue should contain:

• general descriptions of the intended initial design,
• pseudo code of the reactor,
• and some idea of low-hanging vs longer-term goals
  before it is closed.

[nsryan2]

General Description [In Progress]

The goal is for the user to be able to specify, at multiple levels of fidelity, where fuel is and what the impact of its location will be on said location. The levels of fidelity we'll have are:

1. [lowest] Move assemblies during outage or over time (this could be used to loosely model pebbles).
   1. Instead of separate geometry options, we could achieve this using a 2-d Cartesian, and an r- map where appropriate since height is ignored in the Cartesian case as well.
2. [medium] Track rods during outage or over time (you'd still be moving assemblies, but you could do calculations for each rod).
3. [highest] Track pellets during outage or over time (like rods, you'd still move assemblies, but you'd have some idea of height.
   1. You could make one pebble one assembly at this level of fidelity.

[nsryan2]

Pseudo Code [in progress]

Here, we will outline the pseudo code for each level of fidelity as it is developed.

Lowest Fidelity Tracking Assemblies

graph LR
A(Define fuels) --> C
B(Define fuel maps) --> C(List change times)
C -- optional --> D(List preferences)
C --> E(Run)
D --> E

Loading

I'm thinking a map could look something like:

<map>
  <name>Core1</name>
                                     <val>2_5</val>     <val>2_8</val>    <val>2_11</val>
             <val>3_3</val>                                                                      <val>3_13</val>
        <val>5_2</val>     <val>5_5</val>    <val>5_8</val>    <val>5_11</val>     <val>5_14</val>
        <val>8_2</val>     <val>8_5</val>    <val>8_8</val>    <val>8_11</val>     <val>8_14</val>
       <val>11_2</val>    <val>11_5</val>   <val>11_8</val>  <val>11_11</val>    <val>11_14</val>
           <val>13_3</val>                                                                     <val>13_13</val>
                                     <val>14_5</val>   <val>14_8</val> <val>14_11</val>
</map>

Where the name will serve as the initial position.

I don't think xml will care about the spaces and lines, but I'll look into it. This way people can make their inputs a little more human readable, but it can still use the loops that we've been toying around with for EVER. One small change we'd need to make is the iterator, instead of index these maps we'll have to move through by name since subsequent maps will show the updated locations of the fuel and they won't be in the same order anymore.

A simple example of how the maps would work could be like a recipe:

<map>
  <name>Map1</name>
          <val>1_2</val>
  <val>2_1</val>  <val>2_3</val>
</map>
<map>
  <name>Map2</name>
          <val>2_3</val>
  <val>1_2</val>  <val>2_1</val>
</map>
<map>
  <name>Map3</name>
          <val>2_1</val>
  <val>2_3</val>  <val>1_2</val>
</map>

Looking into it more, it might be easier to work with if we instead do something like:

<map>
    <name>Map1</name>
    <coordinates>
      <element name="1_2", x="1", y="2"/>
      <element name="2_1", x="2", y="1"/>
      <element name="2_3", x="2", y="3"/>
    </coordinates>
  </map>

It is less visually compatible in this formulation, but more explicit in the name and coordinate paring. I was looking at making a map on the C++ side, and I think this would be easier to read into said map. Basic C++ map functions like erase and insert are looking like they'd be good at the type of interactions we'd need to do the loading.

Because we are (at least initially) only looking at updating locations when outage happens, the current implementation of Tick will deplete fuel. We want the burden on users to be as minimal as possible, so the name can still be the initial position.

Medium Fidelity Tracking Rods

Highest Fidelity Tracking pellets

To work with EVER

As they are, these ideas work for the lowest fidelity version of EVER. To make NEAR, we'll need to think about how to pass information along between shifts.

[nsryan2]

Planning & Implementation: [in progress]

In this section, we will keep track of PRs and ideas for the direction of the archetype.

Next Steps:

Ideas will be added to this list.

• start

Added:

Accomplishments, with corresponding PRs will be added to this list.

• accomplished