SPN Convergence Analysis for Reactor Problems

[sslattery]

The convergence behavior of the SPN equations for Reactor problems has been observed to be poor for the block Jacobi preconditioning strategy studied. Given real reactor problems, the goal of this task is to find a preconditioning strategy that yields fewer iterations and therefore shorter Markov chains.

[sslattery]

In addition to parallel parameters, I forgot to add that we should also be looking at solver parameters here including weight cutoff and number of histories per MCSA iteration.

[sslattery]

First thing to do here is define a good problem to test this out with. My first thoughts are to do an infinite medium problem of reasonable size. For cross sections, perhaps we should consider a reactor/assembly-type group structure with homogenization so we know what to expect for real problems.

Any suggestions Tom?

[sslattery]

So I've pulled Tom's 3x3 pin problem from Orthanc and will start there as the character of the linear operator will be in line with that observed for other reactor problems. Reflecting and vaccumm boundaries are used here on 3 sides to effectively construct 1/8 of the problem. It has UO2 with cladding and moderator and 7 energy groups with upscatter and fission. I can mesh it pretty fine to test scaling, which will work well as many Jacobi blocks must be inverted for the preconditioning. I'll run it on dionysus next to verify.

[tmdelellis]

Stuart,

We have some full core problems with real cross section we can run when
you're ready.

Tom

On Wed, Mar 20, 2013 at 4:59 PM, Stuart Slattery
notifications@github.comwrote:

First thing to do here is define a good problem to test this out with. My
first thoughts are to do an infinite medium problem of reasonable size. For
cross sections, perhaps we should consider a reactor/assembly-type group
structure with homogenization so we know what to expect for real problems.

Any suggestions Tom?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-15203091
.

[sslattery]

Ok. I'm going to need a day or two with these assembly problems to make sure all types of MSOD parallelism are functioning correctly through the Thyra interfaces. Its easy to do without Thyra but might require some more intrusive code in Denovo to get the communicator structure correct. Once I determine if that's necessary I'll be ready to merge my branch.

[sslattery]

So I ran into this:

Denovo - pyspn Python Front-End
-------------------------------
Release      :     denovo-3_0_0
Release Date :       3-MAR-2011
Build Date   :         20130321

Traceback (most recent call last):
  File "fs_mcls.py", line 412, in <module>
    (r, z, mixids, cleanids, table) = build_mesh(10)
  File "fs_mcls.py", line 209, in build_mesh
    uo2_pin  = Pincell()
  File "/local.hd/cnergg/stuart/builds/Exnihilo/release/python/denovo_utils.py", line 1136, in __init__
    this = _denovo_utils.new_Pincell(*args)
NotImplementedError: Wrong number or type of arguments for overloaded function 'new_Pincell'.
  Possible C/C++ prototypes are:
    rtk::PyPincell< rtk::PyCyl_Pin_Geom >::PyPincell(rtk::PyCyl_Pin_Geom const &,rtk::PyRTK_Tag const &,denovo::PyCompositions const &,double,double)
    rtk::PyPincell< rtk::PyCyl_Pin_Geom >::PyPincell(rtk::PyRTK_Tag const &,denovo::PyComposition const &,double,double)

Looks like the RTK code base has changed since Tom ran these problems. I'll have to figure out how to update the python input.

[sslattery]

It looks like the assembly inputs are out of date with respect to RTK definitions for pincells and material compositions.

Tom - Do you have a more up-to-date input for these spn assembly problems that are compatible with the current Exnihilo master branch?

[tmdelellis]

Stuart,

Let me get in touch with you this afternoon.

Tom

On Thu, Mar 21, 2013 at 12:49 PM, Stuart Slattery
notifications@github.comwrote:

It looks like the assembly inputs are out of date with respect to RTK
definitions for pincells and material compositions.

Tom - Do you have a more up-to-date input for these spn assembly problems
that are compatible with the current Exnihilo master branch?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-15250668
.

[sslattery]

So it looks like I can go through the pyneutronics interface in the Insilico package to run SPn with RTK geometry. The issue here is that Scale (Fulcrum) is a required dependency for this build and makes this much more complicated than I would like at this point. I might just have to make my own problems for now so I can get something working with the software/machines available to me.

[tmdelellis]

Stuart,

Sorry, had to work on some emergencies yesterday. I will call to help you
with this later today.

Tom

On Fri, Mar 22, 2013 at 10:31 AM, Stuart Slattery
notifications@github.comwrote:

So it looks like I can go through the pyneutronics interface in the
Insilico package to run SPn with RTK geometry. The issue here is that Scale
(Fulcrum) is a required dependency for this build and makes this much more
complicated than I would like at this point. I might just have to make my
own problems for now so I can get something working with the
software/machines available to me.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-15299587
.

[sslattery]

That sounds good. Thanks Tom.

[sslattery]

So I decided to just bite the bullet on this one and get a Scale 6.1 license so I can build. I'm working with Mark Baird to get that setup. Once I have that I'll build the pyneutronics front-end and run through the AMA benchmark xml inputs and cross sections Steven Hamilton gave me. There's too much good stuff here not to do the Scale build and it will help me in the long run. This probably means no more laptop builds but those were getting pretty epic as it was.

[sslattery]

Everything is building now. Here's the group 19 neutron flux at the centerline of benchmark 3 - a 17x17 pin PWR assembly criticality calculation.

I solved this problem with Aztec GMRES with ILUT preconditioning. I'm having some issues with MCSA convergence and I think it might be the adjoint solver giving a bad correction. I'm looking at it now.

[tmdelellis]

Is it just failing to converge?

I'm glad u got scale installed, it will make life much easier to set these
up.

Tom Evans
(865)748-8190
Sent from my iPhone

On Mar 27, 2013, at 3:00 PM, Stuart Slattery notifications@github.com
wrote:

[image: g19p3]https://f.cloud.github.com/assets/755901/309983/71d0aa64-9710-11e2-9c19-fd341289e90d.png

I solved this problem with Aztec GMRES with ILUT preconditioning. I'm
having some issues with MCSA convergence and I think it might be the
adjoint solver giving a bad correction. I'm looking at it now.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/28#issuecomment-15546224
.