Running a steady state simulation

[arfc]

Running a steady state simulation

[gridley]

Well, it looks to me like the problem is subcritical under these conditions. The error sounds like it’s related to the splines. I checked your data, and your ordinate data does seem to be strictly increasing. Maybe you could try changing the interpolation method in GenericMoltresMaterial around. Also, I think the lack of benchmarked coupled input on using the eigenvalue solvers is a big deficiency in MOOSE. This seems like a great case for improving upon that. Gavin Ridley

…

On Oct 26, 2018, at 7:45 PM, Sun Myung Park ***@***.***> wrote: 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 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lindsayad]

Straight to a 3D simulation for a first run...that's not a strategy I would try when getting started. Is their any way you can approximate the geometry and try solving in 2D cartesian or 2D axisymmetric?

Also, I think the lack of benchmarked coupled input on using the eigenvalue solvers is a big deficiency in MOOSE.

@gridley what do you mean by coupled input? Feedback with temperature? A benchmark example of this would not really belong in MOOSE, at least not in the framework. In a world where INL wasn't worried about export control, one could envision a neutronics module. But for now almost all of INL's physics work involving SLEPc is in Rattlesnake.

[smpark7]

Thanks for your input Alex and Gavin!

@lindsayad I actually started with a 2D axisymmetric model before swapping to the 3D model, because I was getting similar erroneous results and I thought maybe I got the axis of symmetry and the velocity axes wrong. The 2D model gives a similar resulting flux distribution.

@gridley The k_eff values from Serpent are all slightly super critical for most of the relevant temperature range. I'll check the input values and geometry again though just in case I made a mistake somewhere (which is something that has been happening rather frequently). I've changed the interpolation method to least_squares which doesn't seem to give the strictly increasing error anymore.

With the changed interp_type, now I'm encountering a new error with the NonlinearEigen executioner where it says |Bx| = 0!. Steady state input file. I somewhat understand from a mathematical perspective why this isn't supposed to be zero but I'm don't know what's causing it.

As for the Transient executioner run, the flux distribution is sinusoidal from the very start at small time steps and just tends to zero as time increases. Would this be a result of incompatible initial conditions? Or boundary conditions? I'm concerned about the fact that the neutron flux distribution just varies in z, as opposed to a higher fission rates at the center area than the peripheral area (which is what we would expect as we observe in the MSRE moltres tutorial example).

[gridley]

@lindsayad sorry, I was in a rush making the comment about the "lack of benchmarks". I meant that we don't have any unit-tested (or even shown working) coupled eigenmode solves for moltres, which would be good to work on. I'm definitely going to download this and give a 2D solve a shot with the group constants you generated tomorrow @smpark7. I'm pretty excited to see work on MSFRs in Moltres! :D

This could be related to the fact that when people use diffusion for fast systems, they add large reflectors around it in the calculation to get the right answer. Could be worth seeing if you can get an eigenvalue solve with reflective boundary conditions to work first.

[smpark7]

@gridley Cool! I've updated the README in the input-file directory for clarity. The input-data directory, on the other hand, is in a mess but I recommend using the /input-data/base_config/data3/ data for 6 groups and /input-data/fuelcore/data2/ for 2 groups. They were generated from Serpent for the geometry in question.

Also, I'm not sure if using reflective BCs will help because I ran Serpent specially with only the central fuel salt region, as opposed to running it with the whole core geometry.

[gridley]

Well, I meant run Moltres with reflective. Then you could check that approaches a reasonable k_eff at a few different temperatures, without having to worry about leakage effects being your problem and the influence of diffusion coefficients. Gavin Ridley

…

On Oct 28, 2018, at 12:48 AM, Sun Myung Park ***@***.***> wrote: @gridley Cool! I've updated the README in the input-file directory for clarity. The input-data directory, on the other hand, is in a mess but I recommend using the /input-data/base_config/data3/ data for 6 groups and /input-data/fuelcore/data2/ for 2 groups. They were generated from Serpent for the geometry in question. Also, I'm not sure if using reflective BCs will help because I ran Serpent specially with only the central fuel salt region, as opposed to running it with the whole core geometry. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[smpark7]

I just realised that there is zero heat transfer across the fuel/struc boundary throughout the whole transient. So the fuel salt is thermally insulated from the temperature Dirichlet BC that I set on the outer_wall.

Is there something I have to do in Trelis to enable heat transfer across boundaries?

[katyhuff]

probably if you add material properties somewhere in the mesh or in the material definition add a realistic heat transfer coefficient for that material.

…

On Mon, Nov 5, 2018 at 5:13 PM Sun Myung Park ***@***.***> wrote: I just realised that there is zero heat transfer across the fuel/struc boundary throughout the whole transient. So the fuel salt is thermally insulated from the temperature Dirichlet BC that I set on the outer_wall. Is there something I have to do in Trelis to enable heat transfer across boundaries? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYCq394ycUtx-Dwa9o39JrSL72aF3oSks5usMYfgaJpZM4X9H1R> .

-- http://katyhuff.github.com

[gridley]

Yep, you can do that for pure conduction with discontinuous conductivity, or use an interface kernel to give it a heat transfer coefficient. The latter is better since you won’t cheaply resolve the thermal boundary layer that otherwise exists in real life. Dittus-Boelter would probably work well here. Good luck!

…

On Nov 5, 2018, at 9:39 PM, Katy Huff ***@***.***> wrote: probably if you add material properties somewhere in the mesh or in the material definition add a realistic heat transfer coefficient for that material. On Mon, Nov 5, 2018 at 5:13 PM Sun Myung Park ***@***.***> wrote: > I just realised that there is zero heat transfer across the fuel/struc > boundary throughout the whole transient. So the fuel salt is thermally > insulated from the temperature Dirichlet BC that I set on the outer_wall. > > Is there something I have to do in Trelis to enable heat transfer across > boundaries? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#77 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAYCq394ycUtx-Dwa9o39JrSL72aF3oSks5usMYfgaJpZM4X9H1R> > . > -- http://katyhuff.github.com — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[smpark7]

Thanks for the help guys!

I'm considering using SCALE to get neutronics and steady state data to compare with what I've done on Serpent and Moltres thus far.

While getting SCALE to work on my desktop, I tried a simple Moltres simulation with a very simple geometry, a cylinder of height = 100cm and radius = 50cm, with no flow and reflective BCs. It is a single region with LiF - UF - ThF salt, the same fuel salt used for the MSFR. I obtained supercritical compositions (k_eff = ~1.05 & ~1.20) and the neutronics data from Serpent.

When I ran the transient simulation until steady state (i.e. multiplication factor = 1 and constant temp distribution), I simply got a final result with zero flux and the spatial temperature distribution being constant throughout according to the temperature Dirichlet BCs that I set. The troubling thing I observed was that at the very first timestep (dt = .001s), I got negative group1 fluxes and positive group2 fluxes.

I thought maybe the flux initial conditions are wrong but I can't think of a way to change them to output a positive group1 flux. Input file.

I'm now starting to think that perhaps I didn't generated the exodus mesh file properly. For the test I described above, I generated a rectangular surface in Trelis, then applied a meshing scheme to it, then assigned a block for the fuel region and sidesets for the boundaries. Is there anything I missed out?

[lindsayad]

For a simple geometry like this, have you considered just using MOOSE's GeneratedMesh capabilities?

[smpark7]

Oh yes I could try using that. I've been using Trelis because I expected that I'd move on to more complex geometries. But I guess using GeneratedMesh is good for debugging.

Katy mentioned that there could be something wrong with my Serpent cross sections so I'll be focusing on that for now. We got to this hypothesis because when I tried modifying the MSRE input file part by part to match the MSFR model, changing the cross section data seemed to make the results go haywire, relative to other changes in the input file.

[andrewryh]

@smpark7 Have you consider use OpenMC to generate multigroup cross sections and diffusion coefficients? Those guys have done it: https://www.sciencedirect.com/science/article/pii/S0306454917303754

[smpark7]

I have managed to get a transient simulation of the MSFR towards steady state using a simplified 2D axisymmetric geometry. Thus, I'll consider this issue solved.

The scope for work beyond this level is covered by issue #21

[lindsayad]

Good to hear!