idaholab / virtual_test_bed Goto Github PK

Each app can be installed in app/ using the git submodule system.
If we had a run_tests script that could fetch the desired app, would facilitate development

I expect we dont need to change much from the run_tests script in the framework.

Description

A new example using Griffin to show temperature feedback during a nuclear pulse is proposed when the feedback is a mixture of Doppler broadening and spectrum hardening with microscopic fuel grains generating the heat. This example is a graphite reactor surrounded by a graphite reflector. The graphite reactor has heat producing nuclear grains (spheres) of UO2. The enrichment is HALEU.

The example uses MultiApp to create an initial neutron state from which to insert reactivity causing the pulse to occur. The reactor heats up and the increased temperature removes reactivity forcing the pulse to come back down. Microscopic MultiApp simulation determine the temperature feedback of the microscopic materials.

Cross section libraries for Griffin for the macroscopic and microscopic simulations will be provided. Material properties are from public sources and included in the input files. As this example is from a published PhD that was public, there are no export controls as the inputs are already public. But I'm will to discuss that in more detail if needed.

Questions

This is my first time contributing a model, so I was wondering if I should put this in a particular place since it doesn't fit in any of the current folders for reactors? I was going to put it in a misc/transient/neutron_thermal_feedback.

I'm sure I'll have more questions as I get closer to the pull request.

NEAMS Logo is out of date - updating website with new logo.

• make code names consistent everywhere
• add computational resources to every input documentation
• consider a separate indexing for computational resources
• add more on cross section generation. Probably in the indexing

The Mk1-FHR has most of the salt flow exiting through the plenum rather than the defueling chute or the bypass in the outer reflector. Modeling this flow path will reduce the pressure drop and improve the temperature distribution.

This has been implemented. This needs new (ongoing) development to the finite volume navier stokes implementation to improve the numerical solution.

It triggers errors and warnings because of the 1D meshes currently generated by these inputs
I ll disable them for testing

Cardinal currently only supports the following conjugate heat transfer coupling mode of NekRS to MOOSE:

• NekRS sends temperature to MOOSE
• MOOSE sends heat flux to NekRS

At the time of writing the FHR bypass model, it seemed imminent that Cardinal would also support the reverse data transfers (NekRS sends heat flux to MOOSE, MOOSE sends temperature to NekRS). Such a data transfer would be necessary for MOOSE to get a heat flux from NekRS, and superimpose it with a radiation heat flux between blocks. However, this development is still in progress and I realized while putting together my winter ANS talk that it does not make sense to have a MatchedValueBC (for temperature) with any type of weak flux imposition (because the Dirichlet nodes are "removed" from the solve altogether).

For correctness, we should remove the radiation BCs from the FHR bypass model.

Subchannel code benchmarks should include:

• ORNL 19 pin benchmark
• Toshiba 37 pin benchmark

The workbench is our preferred interface/GUI for using NEAMS tool and provides a lot of additional capability with regards to helping users create input files and exploit results. The VTB can be a powerful to feature the workbench, facilitating its deployment and the deployment of NEAMS tools

The vtb could be an introduction to NEAMS tools (and git) for some users. In which case what we have now is really not clear as to how this all should be used. We will add a short tutorial and feature it prominently on the website

Up until we perform a full clone of the gitlab internal repository, the issue numbers will not match.
Please contact the support team if you need more information about a particular issue

Syntax checks are a good start, but they dont prevent the models from breaking
Even a RunApp which actually runs the input will not prevent erroneous results. Only comparisons to known data points are robust enough. These are unfortunately too expensive for most inputs, so only a few time steps will be compared. And only using CSV output to avoid large files in the repository

• MSFR Griffin-Pronghorn
• MSFR Nek (too expensive?)
• MSRE SAM
• PBMR-400
• mHTGR SAM
• FHR Griffin-Pgh
• FHR Nek (too expensive?)
• FHR SAM
• mrad (coupled multiphysics excluded for now, too expensive)
• SFR griffin-bison

Max cores is 16
Max time is 300s (could be increased)

This doesnt not allow for many timesteps or fixed point iterations, especially for large models.
The tests should be mindful of this and only check the first few iterations to see if the input runs and if the results match so far.

The goal is to use SAM to model a generic Pebble-Bed High Temperature Gas-Cooled Reactor (PB-HTGR):

• The model will primarily utilize SAM's PbCoreChannel component to model the pebble bed core of the reactor. This will enable the model to capture the thermal hydraulics behavior of the core in both axial and radial directions.
• A steady-state and a transient simulations will be provided as demonstrations.

A better measure of the delta temperature would be weighted by the mass flow rate

An even better measure would use the energy to compute the effective dT in terms of energy

Issue foe a model including:

• Pronghorn + Griffin modeling of the MSFR core
• coupled with SAM model of the core and balance of plant via domain overlapping approach

We will add Bison TRISO examples and documents.

Import an INL VTR core model to the VTB. See https://www.sciencedirect.com/science/article/pii/S0306454922001013.

The model is multi-physics with Griffin, Bison, and SAM inputs.

• Update and improve model syntax.
• Generate VTB documentation.
• Create regression tests.

PR #112

General issue to tag for improving the documentation website

Right now the precursor advection is lumped in with the NS simulation. This slows down the fluid solve by 3x, unnecessarily.
We can already use a MultiApp to separate the precursor solve and advect them using auxiliary variables.

However, the ideal set up would leverage sibling transfer for the coupling, to have Griffin be the main app and use up-to-date information for precursor advection (latest fission source, latest velocities).

This is a WIP in MOOSE, we will wait till this is ready to update those inputs, and have much more tenable runtimes.

Transition materials to functor material properties that are now necessary for incompressible and weakly compressible fluid flow.
Pronghorn had to be updated first will a lot of new materials.
Checks on SANA and on comparisons of properties over arbitrary T and P fields confirmed the new materials are correct.

FHR inputs are still using PINSFV (incompressible) as of 12/1. Transition should be performed soon though

@freiler

• Add link to previous pages & to main page on all pages
• Add time axis in figure 3 of chapter 5
• Fix formatting of figure 1 & 2 in chapter 5
• Remove VTB prefix from list of reactors in Chapter 3
• Add MOOSE MultiApps tutorial in Chapter 8
• Rework catch_up tips in Chapter 7 as sub_cycling would handle that case just as well
• Link to chapter 8 from Chapter 7
• Finish Chapter 7 by adding more tips and experience from other modeling endeavours

Add MultiApps tutorial into VTB documentation.

Adding hexagonal assembly thermal mechanical model input files, mesh and documentation. Three model input files are included:

• Single assembly bowing, with linear thermal gradient
• Single assembly bowing, with constant thermal gradient
• Assembly bowing into symmetric sector with linear thermal gradient

The models use the Tensor Mechanics, Reactor, and Contact modules to simulate the core bowing of 3D hexagonal assemblies within fast reactors for radial core expansion estimation due to thermal gradients.

add the input file and documentation of MSRE SAM model.

Our policy with regards to lfs files will evolve depending on cost / size of the repo / convenience.
Reference this issue for changes.

The people have been asking.

• Pronghorn for core coarse mesh CFD
• SAM for balance of plant

Allows for lots of interesting transients that are driven from the secondary side, or for modeling the effect on the secondary of changes in the primary (for design studies for example, looking at uprates etc)

MSFR restart isnt preserving the null transient, so a few timesteps have to be taken to stabilize the null transient.
This is wasteful (in CPU & modeler time).

Griffin restart works nicely from Exodus.
I think the issue may lie in either NS restart from exodus OR from remaining transient behavior in the heat equation

All Pgh inputs will be broken as of the idaholab/moose#18395 merge, which paves the way for weakly compressible flow

Updates will be done in two waves, because functor-gradients, necessary for our mixing length turbulence model, are not merged yet

Add a full-assembly HTGR Cardinal tutorial, coupling MOOSE heat conduction, THM, and OpenMC (Via Cardinal).

The figure misses the caption of fluence.

We're leaving a lot of performance behind right now in those MSR sims.
A few to consider:

• initialize the simulations from exodus rather than from a multiapp
• better time stepping scheme for the transient
• known-to-converge large time steps for the initialization
• only do the viscosity rampdown at initalization
• separate precursor advection and fluid advection to avoid paying for a fully coupled solve

Use this issue to pass pre-check when addressing deprecated syntax in the input files, even if it doesnt fail the tests yet

Dont forget to make a clone PR on the gitlab if the same issue is present there

ABTR has public specifications
https://www.ne.anl.gov/eda/ABTR_1cv2_ws.pdf

Currently a SAM standalone model is provided by ANL

This issue is to start a pull request for HTR-10 Griffin model to be merged into VTB.

Examples of data we want to have:

• what does it do
• which application to run this with
• point of contact

Some apps allow warnings, some dont
This variation can happen even within an app and a combined app comprising this app

So a test may pass with an app and fail with the combined app.
By default we should allow warnings to maximize coverage and the chance of capturing real failures in testing

Now that situation has stabilized for other apps, we should get Cardinal inputs tested too

I'm reading through all the models in preparation for the Tech Talk, and found a few typos.

adding docs and input files for the PBMR400 model

Bison MRs failed because of CSV diff of VTB's TRISO input file. We need to loose the tolerance a bit.

The inputs are very similar for many reactor types for the same reactor type. Since we are not likely to host every transient of interest for every reactor soon, we should point users to other reactor inputs

Another idea is to sort by codes. This is less necessary as many example inputs are available with each code

Exceptions actually aren't available on GPUs, so these additional error checks need to be removed from the OCCA kernels for the NekRS inputs so that someone could run them on GPUs if desired.

While we do good work, we dont want to get sued if something goes wrong. So let's have a disclaimer.

This is an issue for adding the HTTF PG-26 transient model PR which requires a ticket reference Refs #125

This is an issue for adding the SNAP8ER PR which requires a ticket reference.