arfc/moltres

Repository for Moltres, a code for simulating Molten Salt Reactors

Moltres

Moltres is an open-source MOOSE-application code designed for simulation of molten salt reactors and other advanced reactors.

Documentation

Moltres documentation can be found at https://arfc.github.io/moltres/ and https://arfc.github.io/software/moltres. Outlines of the kernels and boundary conditions used to construct the Moltres governing equations can be found on the Moltres wiki. Breakdown of a full-fledged Moltres input file can be found here. New Moltres users who have never used MOOSE before are encouraged to check-out the MOOSE website and workshop slides for tutorials and examples to help understand the underlying Moltres components.

Install

Installation instructions can be found at https://arfc.github.io/moltres/getting_started/installation.html

Development

If you ever want to contribute changes to the Moltres repository, make sure you run scripts/install-format-hook.sh before making any commits. This will ensure that any commits you make adhere to the MOOSE/Moltres C++ style. Pull requests should be submitted to the devel branch of the arfc/moltres repository. Each pull request is automatically tested for style and for whether it breaks any of the core Moltres physics capabilities.

A full list of contributing guidelines can be found here.

Contact

Please post to our GitHub Discussions tab.

moltres's Issues

Need Nusselt boundary condition

Nusselt boundary condition will be essential in simulations where we don't want to resolve the boundary layer

Link to the ARFC Code of Conduct in the CONTRIBUTING.md document

EDIT 1: The first comment below specifies an easier solution by linking to the existing ARFC code of conduct. The issue has been updated to reflect this.

The CONTRIBUTING.md document should link to the expected code of conduct for contributors.

This issue can be closed when a link to the ARFC Code of Conduct has been added to the document.

The original issue is preserved below

Original title: Create a Contributor Code of Conduct

Moltres does not have a Contributor Code of Conduct. A Contributor Code of Conduct defines expected behaviors for all contributing members to a project as well as consequences for not following the behavior. A code of conduct is important for open source projects like Moltres to ensure constructive interactions between contributors in general, and especially when there are conflicts of opinion.

The Contributor Code of Conduct should specify

• expected behavior and conduct of contributors (in a sentence, don't be a hostile person)
• ethical responsibilities of contributors (in a sentence, cite when you use a resource)
• consequences (rules without consequences cannot be enforced)

This list is not comprehensive and should be updated as necessary. The Contributor Code of Conduct should use clear, concise, and easy to read language. A good place to start for inspiration might be the Contributor Covenant or the ARFC Code of Conduct

This issue can be closed once a Contributor Code of Conduct that addresses the above items exists.

Eigenvalue calculation fails with reflectors

When I try to run an eigenvalue calculation, the flux shape I get is clearly wrong.
The geometry is very simple. It is a 1D version of a reactor that has a bottom reflector, fuel, and a top reflector.
I am comparing the Moltres results with a 1D Finite-Difference (FD) solver (and a plot from Serpent from the 3D version of the same reactor).
The predicted eigenvalue is close to what the FD solver predicts, so I don't know if the eigenvalue predicted by Moltres is also wrong or not.

These are the fluxes predicted by Moltres (both fluxes are divided by the group 1 flux max value):

These are the fluxes predicted by the FD solver (both fluxes are divided by the group 1 flux max value):

These are the fluxes predicted by Serpent in the 3D-reactor (both fluxes are divided by the group 1 flux max value):

This issue can be closed when I figure out (or someone tells me) what is wrong with the Moltres input file.
This is my Moltres input file, and it can be found in this link.

Separate chi_d from chi_p

Currently, moltres has delayed neutron precursors emit neutrons in the same spectrum as fission neutrons. Obviously, this is incorrect, since DNPs emit in the resonance range. CHI_D output from Serpent should be parsed and considered by moltres.

Bring Moltres into the present with Python 3 compatibility

This issue can be closed with either:

• a PR that converts Moltres to python3 compatibility (python3.6 or above)
• a reason that we can't move forward in time (e.g. .... is the moose framework still using python 2.7?)

Demonstrate DistributedMesh in Moltres

Will be essential for larger reactor simulations like MSBR

extractSerpent2GCs.py precursor groups

The current script assumes by default that there are 8 precursor groups. It should be edited to allow for an arbitrary number of groups depending on the type of cross-section data (e.g. ENDF, JEFF) used.

Also, the checking for secondary branch names could be automated for ease of use.

CONTRIBUTING.md document has broken links

Links in the CONTRIBUTING.md document are broken. This issue can be closed when the links are fixed to direct to the intended resource.

Loss of flow transient

Simulate loss of flow transient

Fission spectra, CHI vs CHIP vs CHID

Currently, the two common material kernels for Moltres, GenericMoltresMaterial and MoltresJsonMaterial, import CHIT and CHID values from Serpent output data.

MSBR Diffusion Coefficient Generation

In addition to group constants, the diffusion coefficients for the array of temperatures must be generated. This issue can be closed when a reasonable method for generating (or approximating) these diffusion coefficients (perhaps with newt, perhaps with heuristics & serpent) has been achieved and these diffusion coefficients have been calculated for the MSBR.

MoltresJsonMaterial.C doesn't work 1) with Serpent 2 XS and 2) in a precursor loop simulation

MoltresJsonMaterial.C currently has three known bugs.

Firstly, it doesn't work with Serpent 2 XS data because it does not recognize that Serpent 2 provides the overall BETA_EFF and LAMBDA data in addition to the six or eight individual precursor group data. The extra data entry in each dataset triggers a mooseError when a function in MoltresJsonMaterial.C checks the length of the datasets with the user-provided num_precursor_groups.

Secondly, it triggers a mooseError when it is used in a SubApp for looping precursors because the SubApp has no group_fluxes and unlike GenericMoltresMaterial, MoltresJsonMaterial doesn't have an exception for this case.

Thirdly, when interp_type = SPLINE, it erroneously calls for linearComputeQpProperties instead of splineComputeQpProperties.

I'm working on this issue in conjunction with #108

Problems is a maintenance problem

The problems directory is a maintenance problem. Users come and use Moltres and they use input files in that directory as jumping off points for their work, which is great. The problem is that at least some of them (probably most) won't run with modern Moltres/MOOSE. We should at least be running syntax checks on any input file in that directory (and sub-directory) in order to ensure that a new user who comes along and wants to run one of the inputs will actually be able to run the input.

Any untested input file is a ticking bomb for failure. I'm the one to blame...but I also doubt I will have time to address this.

In summary, every git tracked file should be getting touched by a test, even if it is just a syntax test.

Link to MOOSE code standards in CONTRIBUTING.md

EDIT 1: The first comment below specifies a new style guide is not necessary and linking to the MOOSE code standards should be sufficient. The title of this issue has been updated to reflect this.

The current CONTRIBUTING.md file's link to the MOOSE code standards is broken.

This issue can be closed when the CONTRIBUTING.md document links to the correct MOOSE code standards page.

The original issue is preserved below

Original title: Create a Style Guide

Moltres does not have a Style Guide. A Style Guide defines the appropriate style for writing (code, documentation, etc.) for a project. A style guide is important for open source projects like Moltres to ensure that the project remain consistent in both code and documentation as new features are added and old ones updated/revised.

The Style Guide should specify

• code structure
• documentation practices
• file structure

Some of these items already exist in the current CONTRIBUTING.md document.

This list is not comprehensive and should be updated as necessary. The Style Guide should use clear, concise, and easy to read language (this sentence is an example of one you might find in a style guide). A good place to start for inspiration might be the ARFC Guides, the OpenMC style guide, or the MOOSE code standards

This issue can be closed once a Style Guide that addresses the above items exists.

"PrecursorAction.C" precursor scaling not applied

It seems that the PrecursorAction.C action file does not apply a scaling factor to any delayed neutron precursor group variable.

It currently takes in a parameter called "prec_scale" but it does not apply the scaling factor.

Physics Addition: Radiative heat transfer behavior

This issue can be closed when a capability for modeling radiative heat transfer in the context of molten salt reactors is implemented in moltres. This may require treating the transport as a relationship between surfaces, and may require sensitivity analyses.

Need a logo with appropriate usage license.

I know you like this image: https://yt3.ggpht.com/-m228mYexdB0/AAAAAAAAAAI/AAAAAAAAAAA/BUb24swAfxw/s900-c-k-no-mo-rj-c0xffffff/photo.jpg

But, I'm concerned it might be copyrighted or restricted use.
This issue can be closed, either:

• when the rights to this image have been found and comply with our needs (free reuse with modification)
• when a logo has been found (or made perhaps with autodraw) to which we have appropriate rights

paper Makefile broken (pandoc --smart/-S has been removed)

Line 6 of Makefile in moltres/paper/ is currently broken. Running make all returns following error message:

$ pandoc -s -S --bibliography paper.bib --filter pandoc-citeproc paper.md -o paper.pdf
--smart/-S has been removed. Use +smart or -smart extension instead.

Upon review of the pandoc user guide, I found that the -s -S flags are now redundant, as both flags are automatically included for markdown input and pdf output.

I have opened #123 to fix this issue

Error getting pre-concs values from previous run for restart

This error appears in the LOSCA example problem in /MOLTRES/problems/LOSCA as well as other input files that attempted to retrieve pre-concs values from previous simulations (.e files).

To replicate the error:

1. cd to /MOLTRES/problems/LOSCA
2. Mesh the geo file. (Follow the same step as described in https://github.com/arfc/moltres/tree/devel/problems/LOSCA)
3. Run the input file "auto_diff_rho.i". (also described above)
4. cd to /MOLTRES/problems/LOSCA/HXFailure
5. Run the input file "auto_diff_rho.i". (also described above). You will encounter the unrelated errors pertaining to missing parameters "group_number" and "block" within the "delayed_group1" kernel.
6. To proceed, open the input file and add "group_number = 1" and "block = 'fuel'" into the "delayed_group1" kernel.
7. Run the input file again. You will receive the following error message: "Error getting elemental values.
   [0] ../src/mesh/exodusII_io_helper.C, line 1055, compiled Sep 25 2018 at 14:47:44".
8. (7) is the main error of this topic. This error message also appears when one tries to use SolutionUserObject to obtain the pre-concs values from a previous simulation (.e file).
   Note: Sep 25 2018 was probably the day when I built MOLTRES on that computer.

External salt loop only couples on timestep_begin

In PrecursorAction.C, the code which controls coupling to the external salt loop should be updated so that inlet and outlet connections between the reactor and salt loop get updated at time appropriate for each solve. In particular, the coupling currently only gets updated now at timestep_begin, since we typically run long adaptive timestep transients to obtain the steady state. A (the one) user outside UIUC (yay!) desires to run InversePowerIteration solves with the external salt loop, so some code to automatically switch postprocessor transfers from timestep_begin to nonlinear iterations should be added. It would go around line 381 of PrecursorAction.C. This is more of a TODO for me, unless someone else wants to get it.

Fission spectra, CHIT vs CHIP vs CHID

Serpent outputs the fission spectra data as INF_CHIT, INF_CHIP, and INF_CHID, which are the total effective, prompt and delayed fission spectra.

Currently, the two common material kernels for Moltres, GenericMoltresMaterial and MoltresJsonMaterial, import INF_CHIT and INF_CHID values from Serpent output data. They're imported and renamed into chi and chi_d respectively. chi is subsequently (erroneously) used in the CoupledFissionKernel as the prompt fission spectra value.

I believe this is wrong because INF_CHIT represents the total effective fission spectra. This error may have occurred due to the fact that older examples did not have CHIP and CHID as separate data entities.

@katyhuff If my analysis is correct, I'll go ahead and make the fixes (which should be pretty straightforward).

Edit: Maybe not so straightforward to maintain backward compatibility with old input files

Create templates for issues and pull requests

EDIT 1: The first comment below strongly discourages an entire new document be created for contributing and suggests using GitHub templates instead along with editing he CONTRIBUTING.md document. I agree this is a much more efficient approach. The issue has been updated to reflect this.

Moltres development could be improved by adding templates for issues and pull requests. The existence of these templates can be noted in the CONTRIBUTING.md document.

This issue can be closed when templates for issues and pull requests exist, and the existence of these templates is specified in the CONTRIBUTING.md document.

Original issue preserved below

Original Title: Create a Contributing Guide

Moltres does not have a Contributing Guide. A Contributing Guide defines the appropriate procedure for making contributions to a project. A contributing guide is important for open source projects like Moltres to ensure that code issues are dealt with appropriately and efficiently.

The Contributing Guide should specify

• steps for submitting a bug report/feature request/other misc. project thingy and the expected structure of such a report/request/thingy
• steps for reviewing a bug report/feature request/other misc. project thingy and the expected structure of such a review of said report/request/thingy

Many of these items already exist in the current CONTRIBUTING.md document.

This list is not comprehensive and should be updated as necessary. The Contributing Guide should use clear, concise, and easy to read language. A good place to start for inspiration might be the ARFC Guides or the OpenMC contributing guide

This issue can be closed once a Contributing guide that addresses the above items exists.

Physics Addition: Salt Freeze Plug

This issue can be closed when a capability for modeling salt freeze plugs in the context of molten salt reactors is implemented in moltres.

Aqueous homogeneous reactor experiment benchmarking

Initial goals are to benchmark moltres on the MSRE. We forgot one thing by narrowing our view to molten salt: there is one more reactor to benchmark against. ORNL, in its glorious Weinberg days, built this bad boy:

I don't see any transient data for this, but maybe some of the ORNL people have data. Shoudn't be hard to model: Wigner called it "a pot, a pipe, and a pump". This could provide better evidence that moltres is reliably transporting DNPs.

https://info.ornl.gov/sites/publications/files/Pub20808.pdf

k-epsilon model

was accidentally previously filed in the wrong repo (arfc/publications#44).

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.

Use of uninitialized values in GenericMoltresMaterial

@gridley, git blame tells me that this is your code in GenericMoltresMaterial::monotoneCubicConstruct (and also similarly in GenericMoltresMaterial::linearConstruct):

  Real value;
  int tempLength;
  bool onewarn = false;
  for (decltype(xsec_names.size()) j = 0; j < xsec_names.size(); ++j)
  {
    std::vector<Real> temperature;
    std::string file_name = property_tables_root + _file_map[xsec_names[j]] + ".txt";
    const std::string & file_name_ref = file_name;
    std::ifstream myfile(file_name_ref.c_str());
    auto o = _vec_lengths[xsec_names[j]];
    std::map<std::string, std::vector<std::vector<Real>>> xsec_map;
    xsec_map[xsec_names[j]].resize(o);
    _xsec_monotone_cubic_interpolators[xsec_names[j]].resize(o);

    //chi_d backwards compatibility on unit tests:
    if (xsec_names[j]=="CHI_D" and not myfile.good())
    {
      for (decltype(o) k = 0; k < o; ++k)
        for (int i = 0; i < tempLength; ++i)

In that last line, tempLength is used uninitialized. What should its value be?

Generate XSEC tables for moltres that are functions of control rods

Essential for transient scenarios. Need to determine whether we're using:

• Serpent: Current drawback: How to handle diffusion coefficients
• Newt/Scale: Current drawback: How to handle control rod heights with 2D simulation?

Add input file checking to continuous integration

The current (large) set of example input files seems to include a handful that don' t work due to backwards incompatibility (see moltres-users list). These files should be checked (e.g. syntax checked by the moose/moltres input parser), but not run, in the continuous integration system.

"use_exp_form = true" flag often causes simulations to fail

The use_exp_form = true flag allows users to track neutron flux values as exponent values instead of raw values (e.g. e^10 -> 10). Refer to moltres/src/base/ScalarTransportBase.C for the source code.

However, this flag requires careful use because it easily triggers the DIVERGED_FNORM_NAN error on nonlinear solve iterations. The error message does not indicate that use_exp_form is responsible for the failed solve.

I suspect that it triggers the error because Moltres tries to evaluate exp(x) and the value can easily exceed the maximum representable float/double.

This issue is more of a PSA for future users who encounter the DIVERGED_FNORM_NAN with this flag, which is true by default.

Set constant_on default back to NONE in NuclearMaterial

For some reason NuclearMaterial inherits from GenericConstantMaterial. As an optimization I'm working of defaulting GenericConstantMaterial to be evaluated only once per subdomain (it is supposed to be constant by design). However, the Moltres materials that derive from it are not constant. Thus, we need to set the default for the constant_on option back to NONE in there.

See idaholab/moose#15423

Add test for precursor looping capability

There is currently no test for the precursor looping capability. The existing test for the general precursor functionality checks for the movement of precursors in a 2-D MSRE-like model but it does not loop the out-flowing precursors back into the core.

We can implement the test by adopting the same 2-D MSRE-like model and a separate 1-D pipe through which the precursors flow into, decay, and flow back into the core region.

Need InterfaceKernel that will be used in conjunction with Nusselt BC

Essential for coupling fuel-moderator heat transfer when not resolving fuel boundary layers

Decay heat

Moltres shows great strength in its ability to run transients. In order to simulate more exciting transients, it seems that some kernel sort of like the gamma heating kernel could be used in order to approximate this. The kernel could take parameters calculated from power history as given in this document.

Implementing this, Moltres could be used to ensure that passive cooling ability works as expected in shutdown states.

Denatured MSR demonstration

This issue can be closed when a denatured molten salt reactor design has been modeled with Moltres. Steady state and transient problems should both be demonstrated and verified.

One suggestion is the design discussed in : "Lattice optimization for graphite moderated molten salt reactors using low-enriched uranium fuel" http://www.sciencedirect.com/science/article/pii/S0306454917301627

Sparse documentation?

EDIT 1: The first comment below pointed out the language of the original issue had a bit of a critical and disrespectful tone. I generally agree and have updated the issue to reflect this.

The MOOSE code standards recommends that documentation be used often. Here is the example of the level of documentation expected from the MOOSE code standards for a .C file:

/**
 * The Kernel class is responsible for calculating the residuals for various
 * physics.
 *
 */
class Kernel
{
public:
  /**
   * This constructor should be used most often.  It initializes all internal
   * references needed for residual computation.
   *
   * @param system The system this variable is in
   * @param var_name The variable this Kernel is going to compute a residual for.
   */
  Kernel(System * system, std::string var_name);

  /**
   * This function is used to get stuff based on junk.
   *
   * @param junk The index of the stuff you want to get
   * @return The stuff associated with the junk you passed in
   */
  int returnStuff(int junk);

protected:
  /// This is the stuff this class holds on to.
  std::vector<int> stuff;
};

As far as I have seen (please feel free to correct me on this) Moltres documentation is not at this level of detail. I would recommend that this level of documentation be added to Moltres to better align with the MOOSE code standards as specified in the CONTRIBUTING.md document.

Use of a plugin in your code editor of choice for creating comments that can be used to generate Doxygen documentation will make this process more efficient.

This issue can be closed when Moltres code has been documented to a level that meets the MOOSE code standards.

Original issue preserved below

Original Title: Insufficient documentation throughout Moltres

Moltres documentation appears to be generally insufficient. As an open source project, well written and correctly used documentation enables new developers to easily familiarize themselves with the Moltres. This issue depends on the following:

• Update the CONTRIBUTING.md document (Issue 132)
• Create a Style Guide (Issue 131)

This issue can be closed once all code in the repository adheres to the specifications outlined in the new CONTRIBUTING.md document and the Style Guide.

Function velocity for precursors in Loop App

I am trying to simulate a ULOF scenario, by exponentially coasting down the pump with a time constant of 5sec.

I first tried using u_func, v_func, w_func to define the velocities as a function of time in PrecursorAction. I got the following error:

Variable, looped precursor advection requires that variable velocity has the values uu, vv, ww set through the controls module, NOT simply specifying functions through the precursors block.

So I tried using u_def, v_def, w_def as instructed in the PrecursorAction.C file, and using the Controls module to vary the velocities with time.

[./flowControl]  
  type = RealFunctionControl  
  parameter = '*/*/u_def'
  function = nullFunc
  execute_on = 'timestep_begin'
[../]

The main input file runs fine for the first time step. But for the "sub.i" input file that I use for the Loop App (inspired by the LOSCA and LOFA problems in Moltres), I get this error:

The desired parameter '*/*/u_def' was not located for the 'flowControl' object, it either does not exist or has not been declared as controllable.

Neither LOSCA nor LOFA apply time-varying velocities to the precursor flow, so I'm not sure how to implement this.

'extractSerpent2GCs.py' does not work

I am trying to follow the tutorial to create the XS for the moltres input and trying to reproduce the tutorial:
https://github.com/arfc/moltres/tree/devel/tutorial/step01_groupConstants

and this is the error I get:

Making properties for materials:
['fuel', 'moder']
Traceback (most recent call last):
  File "extract2.py", line 213, in <module>
    unimapFile, serp1=args.serp1, fromMain=True)
  File "extract2.py", line 77, in makePropertiesDir
    uniMap[currentMat]), 0, 0].gc[goodMap['BETA_EFF']]
KeyError: (2, 0, 0)

The issue can be closed when 'extractSerpent2GCs.py' works again for the example in the tutorial.

transatomic-like reactor

This issue can be closed when a Transatomic-like reactor design has been modeled with Moltres. Steady state and transient problems should both be demonstrated and verified.

i.e. http://www.transatomicpower.com/wp-content/uploads/2015/04/Neutronics-White-Paper-v1.1.pdf

Simulate MSRE model and demonstrate non-oscillatory temperature profiles

'extractSerpent2GCs.py' should allow more flexible input data naming convention

The tutorial:
https://github.com/arfc/moltres/tree/devel/tutorial/step01_groupConstants

defines serpent input files for the materials 'fuel' and 'moder' with the same names. Then, serpent produces the XS in the .coe files with the same names ('fuel.coe' and 'moder.coe'). In the case I have only one serpent input file, the .coe file won't have the same name as the materials, casing 'extractSerpent2GCs.py' to fail.

This issue can be closed when 'extractSerpent2GCs.py' allows a more flexible naming convention.

Simulate simplified MSR model and demonstrate non-oscillatory temperature profiles

Serpent 2 output converter

The Serpent 2 output converter file extractSerpent2GCs.py (written by @gridley) is a python script that parses and converts Serpent 2 .coe output files created using the branch card into a format suitable for use in Moltres.

This file is a very convenient tool for the above operation due to the large number of parameters and values that Moltres requires.

It is currently incomplete and not compatible to .coe files in general other than the .coe file in the Moltres tutorial example.

Add openmc interface to moltres_xs.py

This issue can be closed when the capability to extract homogenized group constants from OpenMC to Moltres is added.
This should be added to https://github.com/arfc/moltres/blob/devel/python/moltres_xs.py

Update CONTRIBUTING.md

The CONTRIBUTING.md document has not been changed since 2017. Since then, the project has grown and many more lines of code have been added. The CONTRIBUTING.md document should be updated to ensure high quality contributions. This issue depends on the following:

• A contributor Code of Conduct (Issue #129)
• A Contributing Guide (Issue #130)
• A Style Guide (Issue #131)

These dependent issues are inspired by the structure of the OpenMC CONTRIBUTING.md document. This list is not comprehensive and additions can be made as needed. In any case, the document should be easy to read and have a clean, clear structure.

This issue can be closed once the new CONTRIBUTING.md document exists.

terrapower-like reactor demonstration

This issue can be closed when a terrapower-like reactor design has been modeled with Moltres. Steady state and transient problems should both be demonstrated and verified.

Details, of course, about the terrapower design are markedly difficult to obtain. Approximations can be made as long as they appropriately capture key geometry, spectrum, and material characteristics of the reactor.

Physics Addition: Xenon tracking

This issue can be closed when a capability for xenon-135 tracking is implemented in moltres

Running a steady state simulation

I'm currently trying to get a steady state temperature and neutron flux distribution of the central region of the EVOL MSFR (molten salt fast reactor). For simplicity, I am only considering the inner "pool" fuel salt region of the MSFR with a 2cm thick structural layer that separates the fuel salt from the blanket salt as shown in the figure (height = 188cm and radius = 112.75cm, including the 2cm of structural layer). I also reduced the number of neutron groups to 2 from 6 in a paper that has done transient studies on this reactor geometry.

I used the twod_axi_coupled test input file in moltres/tests/twod_axi_coupled/ as reference and built up an input file for the problem above (inputfile). I ended up with a sinusoidal neutron flux distribution (positive & negative fluxes) that tends to zero as t increases.

I am not sure how to run the input file as a steady state problem instead of transient. I think that getting a steady state result would help with analysing what is wrong with my input file. I've tried using the NonlinearEigen and InversePowerMethod Executioner types but they both gave me the same error x-values are not strictly increasing.

Can I get any advice on how I should proceed with my debugging?

@katyhuff @achubbz @andrewryh

Fast Spectrum MSR demonstration

This issue can be closed when a fast spectrum MSR design has been modeled with Moltres. Steady state and transient problems should both be demonstrated and verified.

Get rid of comment cruft in various input files

Some of the input files in the examples and tests need a little cleanup. I know @smpark7 is doing some spring cleaning. This issue can be closed with a PR that removes commented out parameter assignments in those input files.

e.g. https://github.com/arfc/moltres/blob/devel/tests/laminar_flow/tests

Demonstrate heat transfer in 3D

• Initial model will have reflective boundary conditions for heat flux at the edge of the domain.
• This will use just recently generated solution of fluid flow in a single MSRE channel