Outline EVER Archetype

[nsryan2]

This issue is for discussion and outlining of the Enrichment Versatile non-Equilibrium Reactor (EVER) archetype. 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.

Notes/Discussion

• [6/7] The more I look at the C++ archetypes, the more I think it would be good for me to do this first in python and then translate it to C++ so that I can better understand how it all fits together. The end goal is to have these archetypes be in C++.
  • [6/10] I take it back, the C++ archetype for the reactor will be the template. Using it was much easier than I thought it would be.
• [6/10] I think there are some unintended consequences of the optional preference branch I added to the low fidelity case. It's going to require some thought, but, if users can specify the fuel at every time, I need to think more precisely what they are defining.
  • [6/10] It could be that the user defines the change in isotopics with a "change_recipe", or the "burnt" fuel is destroyed and replaced with a new recipe that updates the isotopes.
  • [6/10] Depending on how this is done, users might be able to change preferences without another preference tag? I'll have to think about it more.
• [6/17] The first fuel_incommods value must be the recipe for the recipe_update scheme. The process will only update the first one as fuel, this way you can have other inputs without needing a separate tag.

[nsryan2]

General Description: [in progress]

This archetype will function very similarly to the cycamore reactor archetype, but we will modify the depletion step of each cycle to give the user greater versatility in their implementation of the reactor.

We intend for this archetype to achieve this versatility at x levels of fidelity, and the additions to the archetype will follow from the lowest level of fidelity to the highest:

1. The user can specify time steps at which the recipe for spent fuel will change (this functionality exists to some extent in the cycamore archetype, we plan to expand it formally for this purpose such that users have greater access to this use).
2. User can specify burnup at specific time steps, and coupled code will calculate the recipes/isotopes to get there.
3. [some ill-defined middle ground] (maybe interpolation of some kind, or a user could pregenerate core-averaged cross sections instead of using equilibrium values).
4. The archetype can be coupled to outside codes to perform depletion calculations (a la OpenMCyclus, we will add in additional features to increase the fidelity beyond one-group).

[nsryan2]

Pseudo Code: [in progress]

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

[Low Fidelity] Pre-defined recipes

Added by PR #17

We'll show where this feature diverges from the cycamore reactor archetype, you can assume that a process not pictured will behave the same way as how cycamore would do it.

From a user perspective, this is the workflow I envision:

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

Loading

Which means from a feature perspective, we'll need to update the tags for input recipe, maybe preferences, and create this list of change times (where the user specifies how many time steps the fuel has this recipe).

Example reactor using this feature:

<facility>
    <name>EVER_Update_Reactor</name>
    <lifetime>720</lifetime> <!-- in months -->
    <config>
      <Ever> <!-- note the Ever tag -->
        <!-- same as reactor -->
        <fuel_incommods> <val>fresh_uox</val> </fuel_incommods>
        <fuel_inrecipes> <val>fresh_uox</val> </fuel_inrecipes>
        <fuel_outcommods> <val>spent_uox</val> </fuel_outcommods>
        <fuel_outrecipes> <val>spent_uox</val> </fuel_outrecipes>
        <recipe_update_times> <val>68</val> <val>268</val> </recipe_update_times> <!-- in months -->

        <!-- specific to EVER -->
        <recipe_update_commods>
          <val>fresh_otr</val> <val>fresh_uox</val> <!-- switches to some OTheR fuel and back to UOx -->
        </recipe_update_commods>
        <recipe_update_in>
          <val>fresh_otr</val> <val>fresh_uox</val>
        </recipe_update_in>
        <recipe_update_out>
          <val>spent_otr_u</val> <val>spent_uox</val>
        </recipe_update_out>

        <!-- same as reactor -->
        <cycle_time>18</cycle_time> <!-- in months -->
        <refuel_time>1</refuel_time>
        <assem_size>33000</assem_size> <!-- in kg -->
        <n_assem_core>3</n_assem_core>
        <n_assem_batch>1</n_assem_batch>
        <power_cap>1000</power_cap> <!-- in MWe -->
      </Ever>
    </config>
  </facility>

[Medium Fidelity]

OpenMCyclus

[Highest Fidelity] Coupled n-group

[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.

• Review OpenMCyclus, Ann LWR, and the cycamore reactor archetype (.cc and .h) to understand their components.
• Identify which functions from the cycamore reactor archetype can stay the same.
• Identify which functions from the cycamore reactor archetype need to change to achieve our goal.

Added:

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

• [6/10] On Chewy, I've created the outline of the EVER reactor based on the Cycamore reactor. I'll make a deployment scenario to show that it is the same, but all tests pass.
• [6/19] PR Add in Recipe Update functionality to EVER #17 adds the basic functionality to EVER

[nsryan2]

Graveyard

I like to keep an area for scraps that are eliminated, sometimes with justification as to why they were changed or eliminated to preserve the thought process.