This issue can be closed when a simple full core model of the MOSART reactor has been run with Serpent on Blue Waters.

• Start with serpent input file for similar reactor
• Define geometry
• Define materials
• Run simulation

If a flow regime is defined which has a complete cycle, even if the flows are set to move no mass, then no depletion will occur. Because this does not cause an error in Serpent, it is more difficult to figure out exactly what is going wrong. Found in v2.31.

• For example, imagine a geometry that has 3 materials in it named 1, 2, and 3, respectively. If the flow regime is defined such that 1 → 2 -> 3 → 1 or 1 → 2 → 3 → 2, then the flow is cyclic in nature and will not allow depletion to occur.

• Find a workaround
• Determine issue in Serpent
• Find a workaround in Serpent
• Fix in Serpent

Type 2 flows in Serpent by themselves can raise errors if used improperly due to the equation for flow rate that they follow in BurnMaterials.c. However, even if used properly, if depletion is active, the mass can go negative, hence this bug. Based off current results, it seems that this bug occurs due to the order in which Serpent handles depletion and moving materials. Specifically, Serpent seems to read material masses, deplete, and then move masses based on the pre-depletion masses. The result of this is that if someone creates a flow regime which moves 100% of mass out of a material when depletion is not active, then upon enabling depletion there will be some amount of negative mass proportional to the time step used (since the amount of material moved and the amount of depletion which occurs are both proportional to the size of the time step). A temporary fix in Serpent to this is to comment out the lines which check if the mass is less than -1E-12. A fix for Serpent would be to find where Serpent depletes and where Serpent moves masses with flows and change the order (though this would likely be more difficult in practice). A workaround which enables users to bypass this bug is to simply use smaller time steps, though depending on the situation that can prove to be impractical.

• For example, imagine a geometry that has 2 materials in it named 1 and 2. In this example, say we have a flow regime 1 → 2. Initially, say there is no depletion in the system and we design the flows such that material 1 is completely empty at the end of some time step. Now, if we enable depletion and run this same example, we may encounter this bug if our time step is sufficiently large to cause enough depletion to make the mass flow fail.

• Find a workaround
• Determine issue in Serpent
• Find a workaround in Serpent
• Fix in Serpent

The task (equilibrium state becoming) more and more challenging. There is the table from Robertson with reprocessing time frames:

This one is step 1 and should happen before the complex reactor case.

For validation, create appropriate serpent input files for the simplified geometries defined in the document. For example:

• cube
• cube with fuel
• cube with fuel and moderator
• cylinder
• with fuel
• cylinder with fuel and moderator (e.g. reflector geometry)

Do these with various (vacuum or reflective where appropriate) BCs.

This is most likely a Serpent bug that very infrequently occurs, since the error message simply states "Shouldn't happen" from MakeBurnMatrixMSR.c. This bug is caused by having a set of materials which are all connected by flows, including flows which move no mass. Then, a restart script is used to save the material compositions. Then, the input script which takes the restart output (.wrk file) makes use of a different flow regime. In the Serpent code, the "Shouldn't happen" error message arises from a check which confirms that indexing matches. This leads me to believe that, because all of the materials involved are present, they are given a specific index, which is changed when the new input file tries to change the flow regime, causing the index mismatch error. This makes sense since the bug does not seem to occur if all of the flow materials are not connected. Since the materials are different, I think that Serpent changes the indexing, avoiding the error. Someone might encounter this bug if they are trying to use a workaround to the cyclic flow problem but also want every material to be present in the depletion output file.

• For example, imagine a geometry that has 3 materials in it named 1, 2, and 3, respectively. In this example, say we have a flow regime 1 → 2 → 3. We run this, then take a restart (.wrk) output from it. We then read the restart in the new input and change the flow regime to 3 → 2 → 1. This will cause the bug to occur.

• Find a workaround (with all materials present in depletion output)
• Find a workaround (without all materials present in depletion output)
• Determine issue in Serpent
• Find a workaround in Serpent
• Fix in Serpent

This issue can be closed when a simple full core model of the TAP MSR reactor has been run with Serpent on Blue Waters.

• Start with serpent input file for similar reactor
• Define geometry
• Define materials
• Run simulation

This issue could be closed when whole-core neutronic calculations with Li-6 weight fraction from 0.0005% to 5% will be finished

• Use homogenezation to define material for radial reflector
• Use true geometry without approximation
• Use simplified geometry for reflector

Robertson

Park

Python code should open output Serpen2 file, load isotope concentration in the end of the cycle.
Then generate input file with fuel salt composition.
Probably, it should also generate script to run jobs on Campus Cluster

Park et al. found that optimal time step is 3 day which required 121 iterations to simulate 1 year.
Probably longer time step also works, multiple cases testing needed.

Testing simulations in Serpent2 to understand how burn-up calculation works. Check isotope list and number density after depletion for different cycle length (1,3,10,30,100 days).

Looks like Serpent2 working very slowly on both my machine and Campus Cluster. All compile options should be checked and all tweak input options should be checked.
Fastest build and input file needed for equilibrium calculations.

msr-neutronics/msr-flows/msbr_compare/readme.md feels unclear to me.
It says:
These scripts are designed to generate a Serpent2 input deck, run the deck, and then generate plots. Currently, the MSBR is analyzed with SaltProc and then compared with different approximations using Serpent2's built-in reprocessing functionality.

Do you mean that these scripts generate serpent 2 input files with Serpent2's built-in reprocessing functionality? Then compared with saltproc results?

nitpick: you should stay consistent with dir naming in terms of capitalizing the first letter and using _ vs -.

Since the names (mosart1_1 etc) are not particularly meaningful (how do these runs differ? are they slight variations on the same input?), can you add a README to MOSART describing:

1. the files in the MOSART folder
2. the differences between them
3. what was learned from these runs
4. any relevant references used
5. potential future areas of exploration, if someone were to pick these up again.

That is, this work doesn't need to be lost to history (it could even be an ARFC report, if you want to give it some official documentation.).

Summary

The current continuous reprocessing comparison used to compare against SaltProc's batchwise process (which uses 3 day steps) in the MSBR uses a single 3000 day step. This provides results that are not entirely accurate, and comparison with different numbers of steps would also be a useful visualization tool.

Solution

PR needed that allows for any N-steps to be used for Serpent2 continuous reprocessing input. Only requires minor changes to the current code for rerunning and reading previous depletion data.

Background

Serpent2's continuous reprocessing functionality can be useful in running reactor simulations where removal of wastes or addition of fuelsalt is required. Particularly, the continuous nature means that larger step sizes can be used rather than the small step sizes needed in batch-wise removal. However, since the implementation of continuous removal is performed by an additional "decay" term to the Bateman equation, conventional removal efficiencies aren't accurately applicable. The continuous implementation can potentially be integrated with SaltProc's batch-wise design to allow for larger time steps in general by continuously removing xenon, or it can be used when the change in masses is sufficiently small such that larger time steps do not greatly impact overall accuracy. PR #51 offers the initial design for generating the Serpent2 deck and running it, but it does not have implementation of different approximations.

Functionality Needed

In order to apply the removal efficiencies, different approximations can be made, such as approximating linear fission product accumulation or approximating the removal using the "half-life" of the cycle times of elements.

The first step to this process is to generate the approximations in an organized manner such that future implementation and usage of the code will be more straightforward.

Write up full geometry definition for detailed reactor model, to be simulated in Serpent.

• consider the detailed reactor design,
• identify symmetries,
• make simplifications,
• and define all material compositions
• define temperatures for operation
• define densities
• etc.

I am uploading my Python scripts to GitHub. The scripts are currently used to generate a set of Serpent inputs to model flows in a simple MSR-type model using Serpent's built-in flow and restart functionality.

This is the initial adding of the code, so more functionality and fixes will be made as the work progresses.

For the geometry in issue #1, create an input file for serpent.

• What is the content of the control rods? Really just pure graphite? Find a reference?
• What if line 91 is "void" or "outside" or "moder" option
• What is k_eff if you comment line 160?
• What happens if there is no space before the first character on line 179? or, if all on 1 line?
• fix comment in line 189. want black boundary condition (as is coded)
• look into decreasing 233U percentage (0.232 mole %, Robertson p.30)
• determine if your fuel is really 3.33 g/cm^3 <-- if wrong, check density
• Is there a scattering kernel available that knows about the scattering in fuel salt isotopes?
• brainstorm: why is it only calculating a tiny volume of fuel and moderator? is it only doing multiplication in a zone 2 cell? Consider changing line 199. See what happens?
• What happens with more neutron groups?

The reflectors at the top and the bottom of the core must be added to the existing Serpent geometry.

I suppose that this repository contains design details for export-controlled neutronics, whereas the pre-existing MSR-design repository will be for everything else?

PyNE should be installed in project/arfc folder for further using by everyone

Manu features added, probably online reprocessing will works better

This issue can be closed when an MSFR equilibrium fuel composition is made available, defined by negligible change in TRU composition over a long period of time.

This issue can be closed when a simple full core model of the MSFR reactor has been run with Serpent on Blue Waters.

• Start with serpent input file for similar reactor
• Define geometry
• Define materials
• Run simulation

The MSFR directory is getting messy due to the increasing number of files. Having a systematic way of naming and arranging files would be helpful, along with READMEs.

Expect to be PRed concurrently with the current issue of running a steady state simulation of the MSFR (issue 77 in the arfc/moltres repo)

In this issue, I leave my comments for msr-neutronics/msr-flows/Notes/mass_balance.ipynb. This issue can be closed when @LukeSeifert addresses them.

If only continuous reprocessing is used, a balanced mass is not achievable without steady state. However, in the MSBR, only a partial steady state is achieved, so exact mass balance is not fully achievable.: Could you clarify these statements? Why can't you balance the mass without steady state?

The feed has a constant input rate (i.e. type 0 feed or type 1 with a large mass and small reprocessing constant).: Could you define type 0 and type 1? I see you defined it later, move it to the top :) Also, what's the difference between large and medium source mass?

For the Decreasing Feed Example, could you describe the significance of this example compared to constant feed example? Is it because MSBR only achieves partial steady state?
I'm confused. If feed rate is decreasing, how can the plot have a legend for a constant feed rate value?

Hybrid Reprocessing Mass Balance: I suggest numbering the four methods, so that it's clearer which of the following examples refer to which method.

Overall comments

• include x,y labels for all your plots, even during solo experimentation, it makes it clearer to you and minimizes random mistakes.
• Just for my own understanding, this mass balance exercise was just a sanity check to confirm that the net mass fluctuations are insignificant and do not need to be accounted for using batch adjustments to the feed rates. Will you be implementing a hybrid mass balance method for your eventual goal of the MSBR continuous reprocessing model (assuming this is your eventual goal)?

Try "grep -r 'grj3.12j'". This appears to be the thermal scattering library in use for several input files, which is graphite at 600 kelvin. This is below flibe's liquidus.

There are two approaches which have been introduced in msr-flows/Notes, but they have yet to be incorporated into the code.

The first approach takes the cycle times from the MSBR data, uses a linear approximation to convert them to efficiency rates, and then turns those rates into reprocessing constants.

The second approach takes the efficiency rates from SaltProc's MSBR example, converts them into per second rates, and then turns those into reprocessing constants.