@katyhuff has mentioned this

The proposed scaling test is very limited. Proper scaling tests would require weak and strong scaling tests, an assessment on the impact of the size of problem per core, a separate assessment of intra-node and extra-node scaling, etc. In addition, information should be provided on the employed numerical algorithms and on the parallelization strategy. The authors should either extend significantly the section, or remove it completely.

Maybe other MOOSE results could presented, and then present some Moltres results in the same terms. This would show that the solvers and parallelization provided by MOOSE work well for the physics exhibited by MSRs.

This issue can be closed when the three deployment scheme plots
are reduced to two plots that show the difference between installed capacity of LWR and FR
from the base-case

For the Europe paper.
The implementation didn't actually use the growth region.
This issue can be closed when :

• a new simulation is run that uses commodity demand to drive SFR deployment and the results are integrated into this paper
• OR if the above strategy is abandoned, this can be closed when the text no longer refers to the growth region.

• Are all equations solved on the same mesh? In this case, is this a strict requirement? Please clarify.

• The heat generation in the graphite is calculated as a fraction of that in the fuel. How exactly is this achieved considering that the two sources are spatially separated?

• It is not clear how the domain is discretized. Is there a radial discretization in graphite and channels? Was the mesh convergence checked? Please discuss.

• The MSRE had Reynolds numbers very close to the laminar-turbulent transition. Did you use a laminar model? In case, did you encounter convergence problems ?
  Or did you include turbulence? More generally, is Moltres capable of turbulent simulations?

• The authors are required to use the international system of units (meters, Kelvin, etc).

• The authors should briefly describe what "MSRE design models" are. Otherwise it is very difficult for the readers to assess the accuracy of the model.

• Is the heat generation in the hottest channel the same for the Moltres and the MSRE model?

• The authors claim an unprecedented accuracy of their model? How the results of their model compare with previous results from other authors? The presented results do not seem sufficient to support such claim.

• The differences between the MSRE and the Moltres model are significant and should be discussed in more details. In particular the difference between fast fluxes is suspicious.

The moltres paper deserves its own repo. (maybe it should have been in its own repo this whole time). In any case, I want to have a logical naming convention for all of the paper repos in this org... so I'm thinking I'll :

• create a repo called 2017-lindsay-moltres
• move the 2017-lindsay-moltres_init branch (along with all its history) to the master branch of that repo
• add a 'topic' label to that repo called 'paper' so that I can search my repositories for all the papers.
• and maybe try to divorce myself from this publications repo idea entirely....

Thoughts (@lindsayad @andrewryh @gridley ) ? Better naming convention ideas? I don't love super long repo names, so maybe we can skip the year? Hopefully we choose this name cleverly enough that I can use this as a model for all future papers in the ARFC group...

Hello,

Chapter 1 (literature review) draft ready for review.

The repository tag is ch1-draft-1.1
https://github.com/andrewryh/MScThesis-MSBR/releases/tag/ch1-draft-1.1

Please, ignore Chapter 2.
Thanks!

Tag here: https://github.com/andrewryh/MScThesis-MSBR/releases/tag/ch3-draft-1
PDF file: https://github.com/andrewryh/MScThesis-MSBR/blob/master/msbr.pdf

That is cumulative thesis code/PDF
Thanks!

Compare monolithic and segregated solves with Moltres. Will require three multi-apps for:

• Neutronics
• Temperature
• Precursors

Or optionally two:

• Neutronics & precursors
• Temperature

Get a new doi before submission.

@jbae11 The introduction of the paper needs one to three paragraphs of concise literature review. According to Whitesides et al.:

The first paragraph or two should be written out completely. Pay particular attention to the opening sentence. Ideally, it should state concisely the objective of the work, and indicate why this objective is important. In general, the Introduction should have these elements:

• The objectives of the work.
• The justification for these objectives: Why is the work important?
• Background: Who else has done what? How? What have we done previously?
• Guidance to the reader: What should the reader watch for in the paper? What are the interesting high points? What strategy did we use?
• Summary/conclusion: What should the reader expect as conclusion? In advanced versions of the outline, you should also include all the sections that will go in the Experimental section (at the level of paragraph subheadings) and indicate what information will go elsewhere...

here are a bunch of grammar things I plan to handle in an upcoming pr.

• The sentence "Table 6 lists EU inventory and history at year 2050, and the used UOX will be reprocessed." makes no sense.
• "Listed are the metrics from the historical nuclear operation of EU nations." -> This sentence could mean anything. What year is this? 2050? If so, say this sentence differently. Perhaps "Projected nuclear material inventory in the EU in the year 2050 is summarized."
• Instead of "timeseries of tails and used fuel inventory accumulation" perhaps "accumulation of tails and used fuel over time"
• Table 7, The TOTAL row, should appear at the bottom, for clarity. Consider making it bold. It's easier to see it as a summation of the other rows that way. Plutonium From UNF Inventory.
• Phrases like "This figure" "This table" etc. really don't need to appear in table and figure captions. We know the topic at hand is the figure/table being captioned.
• The section "Historical Operation of EU Reactors" is not really about "Historical Operation of EU Reactors" at all. It's about mass accumulation. Specifically, "UNF and tails Generated in the European Union."
• "Tailings" still appears all over the place. I generally prefer "tails."
• Random words are capitalized in various places. For example, in the middle of one sentence, there's a parenthetical that capitalizes the M in minor actinides.
• add middle initials and institutional affiliation for all authors.

This issue can be closed with one or more PRs that address the comments in the second round of review.

europe_nuclear_paper.pdf

@katyhuff You mentioned something about adding a mammoth definition table. Can you elaborate more? Do you mean something along the lines of Cammi's definition table? Or was this taken care of by your nice in-line equation definitions?

I'm submitting a ...

• feature request

Expected Behavior

There should be a LICENSE file that covers the entire repository.

Actual Behavior

The ms-thesis-template directory contains a license file, but I don't believe that it covers the rest of this repository.

How can this issue be closed?

First, a determination has to be made about the type of License under which to cover this repository.
Second, that License should then be added through a pull request to this repository.

Address:

It's somehow interesting that "For some three-dimensional simulations, the number of elements in the mesh and total number of degrees of freedom exceed one million and ten million respectively. To handle problems of this size, we ran Moltres on up to 608 cores." Normally problems of few million degrees of freedom can be handled with few tens of cores. The authors should discuss more extensively the performances of their code in order to give the reader the possibility to compare them with those of other tools. In particular, it is possible that slow performances may derive from trying to achieve a fully coupled solution (i.e., all the equations in the same matrix), which seems to be the case in this work. In this sense and to better support the claims of the paper, it would be important to compare the performances of a segregated and a fully coupled solver, both in terms of accuracy and computational time. In addition to helping supporting the claims of the paper, this
would represent a significant contribution to the scientific community, since many of the currently available tools employ segregated solvers, and since the advantages and disadvantages of a fully coupled solver are often a subject of discussion.

Maybe we could get in contact with Ben Collins at ORNL who presented on CASL's MSR efforts. They implemented MOC neutronics on a fluid-fueled system described here. Since Dr. Collins's group used some fancy transport approximations, their code likely has far-superior fidelity per unit computation. We could argue that Moltres should serve as a testbed for various computational approaches to MSRs before developing high performance, lower level codes that don't rely on explicitly forming a problem matrix.

Also, a note on comparing fully coupled and decoupled calculation: IIRC, CASL-VERA running LWR full-core depletion simulation takes a week on 1000 cores for decoupled calculations, and three weeks on the same number of cores for fully coupled mode. We may be able to get some data from our ORNL friends for comparison.

2.4 Material Definitions is a very sparse section. While listing the spent fuel recipes is a bit onerous for a table in the middle of the paper, we should probably list the fresh fuel recipes (enrichments, contents of pu, contents of tails, etc.

To avoid merge conflicts and frustration, consider waiting to get started on this until #48 is closed.

It's good that you saved writing the abstract until the end, @jbae11 -- the abstract is always easier once the paper is written. Now we are at the point that the Europe paper needs an abstract.

It should be no more than 150 words and I generally think it should contain a very concise explanation of :

• the question under investigation
• the methodology
• any analysis
• the results
• any conclusions drawn

Table 3 currently looks like this:

I understand that some entries were positioned across PWR and BWR to indicate that those values apply to both. I like the idea, but unfortunately it's confusing to read. This is complicated by the need to add a caveat to the Lifetime row. Ideally, tables should be set up to avoid lengthy caveats.

I have a few edits and will assign this fix to myself.

And optionally update for a refined mesh.

In the europe paper, the following statement appears:

"Projections of future reactor deployment in this simulation were
assessed based on analysis from references like \gls{PRIS},
\cite{world_nuclear_association_nuclear_2017} \cite{joskow_future_2012} \cite{hatch_politics_2015}."

• If you would like to cite three references, you can do it like this more concisely: \cite{world_nuclear_association_nuclear_2017,joskow_future_2012,hatch_politics_2015}
• The sentence mentions PRIS, but none of the things that were cited. PRIS is left uncited. Instead of "we used hair references like Bob \cite{rob,tom,jon}," it is more explicit for the reader if the author says "we used references such as Bob \cite{bob} for his brown hair, Rob \cite{rob} for his red hair, Tom \cite{tom} for his black hair, and Jon \cite{jon} for his blonde hair."

This issue can be closed when the results of the sensitivity study
is represented as timeseries, not average values.

Don't forget Blue Waters allocation in the acknowledgements.

Imagine you're a stranger trying to reproduce the Europe paper based on the text. Certainly, the input files are available online, but frankly the process is convoluted and it could take quite a while to determine how many of which archetypes were deployed, with what region-instituition-facility models. The paper should include enough information for the reader to know which models we were using (e.g. they should know from reading the paper whether or not we use the growthregion, the deployinst, etc.). It doesn't have to go into enormous detail, but improving the diagram to include region/inst archetype information is appropriate.

From @lindsayad :

The k-epsilon turbulence model was never finished since it really required SUPG stabilization to be relevant. Now, SUPG and PSPG are implemented in the navier-stokes module. So the k-epsilon model could be finished if someone wanted to work on it. It's very close to completion; the major piece remaining are the wall functions.

While Dr. Lindsay is not able to work on this directly, consult with @lindsayad to get appropriate initial direction.

In the europe paper...
Ideally, the source of all numbers in all the tables should be cited if they came from a book or paper. Perhaps it's too cluttered to include those citations next to the values themselves. Other options include:

• put the citations in the column headings (e.g. in Table 3 you could have "BWR [1,2,3]")
• put the citations in the caption (e.g. in Table 3 you could state "Values for PWRs came primarily from references [1], [2], and [3].").

Address this:

Concerning the openness of the code and the possibility to contribute to it, it should be noted that codes solving for neutron transport can be subject to export restrictions (following their potential dual use), and in principle all contributors should get an export control authorization from their own country. The authors are not strictly required to change the manuscript, but they may consider mentioning the fact that the openness of a nuclear code can be somewhat thwarted by national and international laws.

We could possibly find and cite some laws relevant to why neutronics code may typically not be open source. In addition, since the code only models diffusion neutronics, the updated paper could argue that authorities won't bring down the export-control hammer due to its relatively easily-implemented, low order nature.

Overall, improve support for claim that Moltres can provide unmatched fidelity in coupled neutronics / liquid fuel TH.

These important related articles were not reviewed:

• Manuele Aufiero, Antonio Cammi, Olivier Geoffroy, Mario Losa, Lelio Luzzi, Marco E. Ricotti, Hervé Rouch, Development of an OpenFOAM model for the Molten Salt Fast Reactor transient analysis, Chemical Engineering Science, Volume 111, 2014, Pages 390-401, ISSN 0009-2509, http://dx.doi.org/10.1016/j.ces.2014.03.003.
  (http://www.sciencedirect.com/science/article/pii/S0009250914001146)

• Carlo Fiorina, Danny Lathouwers, Manuele Aufiero, Antonio Cammi, Claudia Guerrieri, Jan Leen Kloosterman, Lelio Luzzi, Marco Enrico Ricotti, Modelling and analysis of the MSFR transient behaviour, Annals of Nuclear Energy, Volume 64, 2014, Pages 485-498, ISSN 0306-4549, http://dx.doi.org/10.1016/j.anucene.2013.08.003.
  (http://www.sciencedirect.com/science/article/pii/S0306454913004118)

• Matteo Zanetti, Antonio Cammi, Carlo Fiorina, Lelio Luzzi, A Geometric Multiscale modelling approach to the analysis of MSR plant dynamics, Progress in Nuclear Energy, Volume 83, 2015, Pages 82-98, ISSN 0149-1970, http://dx.doi.org/10.1016/j.pnucene.2015.02.014.

• A. Laureau, D. Heuer, E. Merle-Lucotte, P.R. Rubiolo, M. Allibert, M. Aufiero, Transient coupled calculations of the Molten Salt Fast Reactor using the Transient Fission Matrix approach, Nuclear Engineering and Design, Volume 316, 2017, Pages 112-124, ISSN 0029-5493, http://dx.doi.org/10.1016/j.nucengdes.2017.02.022.

• Chinese (probably SINAP) articles should be reviewed too.

In addition, this point also fits into this github issue:

• The authors write:
  "Moltres is devoted to previously unmatched fidelity in coupled neutronics and thermal hydraulics MSR simulation."
  This is an overstatement as codes with similar degree of fidelity have been written in the past. This is the case of the tools developed in the frame of the Evol project, as well as e.g. the work from Aufiero on the coupling between OpenFOAM and Serpent (that the authors mention earlier in the introduction). The authors are required to modify this sentence based on a better bibliographical research.

I have reviewed the European scenario paper draft and have made scribbles accordingly on this document. europe_nuclear_paper.pdf

This issue can be closed with one or more PRs that address the comments in it.

Chapter 1 edits applied.

Tag link: https://github.com/andrewryh/MScThesis-MSBR/releases/tag/ch2-draft-1

Thanks!

This issue can be closed when @katyhuff has conducted a full review of the EU paper and has made a PR (or opened issues) to make changes necessitated by that review.

In order to get the 'growth trajectory' for future extrapolation of EU nations' nuclear program,

what should be the two points that are taken into account?

ie) Bulgria Example
How would one calculate the slope of such a history?

Reviewer question:

In the introduction, the authors mention that: ``Two key advantages
offered by the fluid-fuelled MSR are improved fuel utilization and no radiation
damage constraint on attainable fuel burn-up. Together, these attributes result
in significantly reduced core fissile inventories and spent nuclear fuel mass''
However, the fissile inventory is not necessarily related to fuel burnup and
fuel utilization. It can actually be very high in chloride-based fast-spectrum
MSRs.

Anyone got a shot at this one?

In the europe paper :

Methodology should include all of the input (historic deployments, predicted european growth, predicted decommissioning, material definitions, reactor details.)

Results should include all of the things that Cyclus and Cycamore produced in the output file and (SFR transition deployment ... which was found through the logic of the Cycamore GrowthRegion.)

Currently, these things are all mixed together. For example:

• All of section 6 should actually be part of section 3.2.
• Section 3.3 (SFR deployment) should actually be part of results.

I have a pretty solid idea of how I want this to be ordered, so I'm going to give the rearrangement a shot. It will be an ugly PR... brace yourself @jbae11 .

@katyhuff I'll work on this unless you have already found some.

Tasks

• Decide whether we want to submit a JOSS paper first
• Adding some comparison with expected results will be necessary. Ideally, MSRE or 1-D analytical solutions. Are the fluxes the appropriate magnitude? How correct is the peak/average flux ratio? Is the temperature profile as was seen in MSRE?
• Performance analysis. It runs fast, but how fast? Is it appropriate to do a scaling study?
• Add description of how the group constants were generated for this particular simulation.

More to be added through comments.

Tag @katyhuff