arfc / moltres Goto Github PK
View Code? Open in Web Editor NEWRepository for Moltres, a code for simulating Molten Salt Reactors
License: GNU Lesser General Public License v2.1
Repository for Moltres, a code for simulating Molten Salt Reactors
License: GNU Lesser General Public License v2.1
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:
This issue can be closed when a capability for modeling salt freeze plugs in the context of molten salt reactors is implemented in moltres.
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.
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.
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.
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
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.
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.
Will be essential for larger reactor simulations like MSBR
Nusselt boundary condition will be essential in simulations where we don't want to resolve the boundary layer
Essential for coupling fuel-moderator heat transfer when not resolving fuel boundary layers
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.
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.
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 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:
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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
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:
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.
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
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:
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.
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
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.
Simulate loss of flow transient
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.
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.
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.
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.
Currently, the two common material kernels for Moltres, GenericMoltresMaterial
and MoltresJsonMaterial
, import CHIT
and CHID
values from Serpent output data.
This issue can be closed when a capability for xenon-135 tracking is implemented in moltres
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.
This issue can be closed with either:
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 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
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.
Links in the CONTRIBUTING.md document are broken. This issue can be closed when the links are fixed to direct to the intended resource.
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
@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?
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.
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.
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
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.
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
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
Essential for transient scenarios. Need to determine whether we're using:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.