MSR Flows Testing Initial Commit

[LukeSeifert]

This PR is my work on generating Serpent inputs that allow for functional cyclical flow. The code isn't terribly clean because this is more of a testing phase. I am currently trying to determine the best way to get flows working with Serpent so the method can be incorporated into a more complex geometry.

The input.py file contains the user defined terms (i.e. cycles and such).

The complex_serpent_builder.py and serpent_builder.py files contain the scripts used by input.py to build the Serpent inputs, where complex_serpent_builder.py uses the multiple core approach while serpent_builder.py uses a cyclic flow approach. Due to the Serpent bug in cyclic flows, the functionality of serpent_builder.py has been suppressed and it only sends flow through the core once.

The res_dep_analysis.py file is used to analyze the results and depletion outputs, and is used to generate the plots.

I plan on adding my next, and hopefully fully successful, approach using restart scripts in my next PR. These approaches are flawed due to the aforementioned Serpent bug and the excessive run time with the multiple core approach.

To run these scripts, the sss2 executable is put into the same directory as the rest of the scripts. Then, the input.py script is run, and the plots will be generated along with the various Serpent output files.

The msr_cycle_test directory contains all of the Serpent outputs as well as the generated plots.

[pep8speaks]

Hello @LukeSeifert! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:

Comment last updated at 2021-04-02 17:03:32 UTC

[robfairh]

Thanks for your PR @LukeSeifert. I will take a look at your PR later. In the meantime, try fixing the PEP8 issues.

[robfairh]

I have the following general comments:

• See my comments on the pep8 issues
• Consider always linking a PR to an issue. The issue should describe what problem you are trying to solve, and the PR should solve it. You added a lot of description in the PR that is helpful to the reviewer and future Lukes. Having a linked issue is still necessary. Having open issues helps other people avoid overdoing things. With the issue, people will know what you are working on and will focus on something else. For future PRs, make issues before even opening a PR.
• You are PRing from master. Avoid working on the master branch. It is easy to screw up. A good practice is to keep the master branch always reflecting what is in arfc:master. Then, you make your changes in a separate branch, and then you PR from that separate branch. This time is okay because I don't think there is anyone else working on this simultaneously, but avoid it in the future.
• Refrain from doing git add <folder-name>. You have several hidden files uploaded in this PR. __pycache__ is an example of that. Those files should be removed from the PR.
• Consider adding a README.md. This will make clearer what every file in flow-tests/ does and why it is necessary. Additionally, it will enhance the reproducibility of your work. And it will also help you remember what you did after a few months have passed.
• The PR is quite big. This complicates the review a little bit, it will take time. In the future try to make smaller PRs that address specific issues.

A more specific comments:

• I am not sure I like running serpent from a python script. I have no idea what is happening while waiting. In my case, I run python input.py. The last print in the terminal told me that I have created a msr_cycle_test, and that was it. I stopped the process cause I have no clue how long it was going to take. I thought I was running the input file, so I checked my CPU and RAM usage to discover nothing was happening. I opened the output file to find the following error: Unable to locate cross section directory file "/home/luke/serp/xsdata/jeff312/sss_jeff312.xsdata" Of course, I got that error! I could have gotten any other errors and I would still be here waiting for the script to complete the run. I suggest one of two things: raise an exception if there is an error while running serpent or see the way to output in the terminal what serpent is doing.

I will continue later with the review. I'm sorry but the PR is quite big.

Finally, you mentioned the following in the description of the PR:

To run these scripts, the sss2 executable is put into the same directory as the rest of the scripts.

This is Okay, but this is better:

• Add an executable “sss2” to the search path by doing: sudo update-alternatives --install /usr/bin/sss2 sss2 /home/roberto/Serpent2/src/sss2 1 (change /home/roberto/Serpent2/src/sss2 with the absolute path of your executable)
• To see if it works, do: which sss2
• If the result is something like usr/bin/sss2/, it worked, and now you should be able to run serpent from any directory without making links or copies of the executables.

[LukeSeifert]

Thank you for your comments! I will go through and address the things you brought up.

[LukeSeifert]

I made some fixes and also changed the restart run type so it will move the material as I wanted it to. However, in order to not get an error while running, the error code in burnmaterials.c in the Serpent source code has to be suppressed. That is why in the code instead of using sss2 to run the code, sss2_test is used, which is a recompiled version of Serpent I used that has that error suppressed.

[robfairh]

@LukeSeifert let me know when this is ready for the second review

[LukeSeifert]

@LukeSeifert let me know when this is ready for the second review

@robfairh thank you for reminding me, I forgot to let you know! It is ready, but I would recommend if you try running it to read through the readme first. I had to change part of the Serpent source code to get my script to run (planning on writing an issue on it in a bit). Thanks!

[robfairh]

Great job! Thanks for addressing all of my comments @LukeSeifert. Merging.