openmc-dev / openmc Goto Github PK

Currently unresolved resonance data is read in but is not used. During the calculate_nuclide_xs routine, the data would need to be sampled to get a cross section.

Looks like it doesn't currently sample secondary energy distributions for fission and instead just assumes a U-235 thermal fission spectrum. Energies should be sampled and passed through the banks to the next cycle.

This issue occurs as far back as ae9ef6 and affects both tallies and reported keff. It seems like it is likely an issue in the physics itself, not the tally system.

The sampling of a chi-squared distribution is currently only possible for a number of degrees of freedom from 1 to 4. However, it is very easy to extend the sampling to any number of degrees of freedom using rule C64 for odd n and rule C45 for even n (rules are from the Los Alamos Monte Carlo Sampler, LA-9721-MS).

It is important to account for the velocity distribution of target particles when the energy of the neutron is thermal or epithermal (<400kT). Assuming the target material has a particle velocity distribution that is Maxwellian, one can develop a formulation for the effect on the cross-section and the scattering kinematics.

Doesn't seem to be working. Taking examples/basic and changing the outer z-cylinder to reflective hangs after reflecting the first particle.

For working with real geometries, universe transformations will be very helpful. In particular, for the MITR model, universe translation and rotation is used heavily in the MCNP model.

After adding the Shannon entropy capability, it is fairly straightforward to do a dominance ratio calculation via the noise propagation matrix method outlined in T. M. Sutton, P. K. Romano, and B. R. Nease, "On-the-Fly Monte Carlo Dominance Ratio Calculation Using the Noise Propagation Matrix," Progress in Nuclear Science and Technology, 2, pp. 749-756 (2011).

At some point, it would be nice to have the capability to do delta tracking. Jaakko Leppanen has found that delta tracking speeds up certain problems greatly (those with high mfp?).

Right now we are using the xsdata format for looking up cross section tables that is used by Serpent. I'd like to move away from this and have an XML format for the cross section library as well. That way no special reading of the xsdata format would be needed and the standard xml-fortran reading could be used instead. Of course, converters would be supplied that could convert xsdata or xsdir files to the XML format.

Lattices may not work correctly if surfaces within the contained universe or within the parent cell are coincident with the lattice boundaries. Additional logic should be added to handle these cases.

Some reactions specify multiple scattering laws. This is mainly used for (n,xn) reactions. In such reactions, the emission of each neutron corresponds to a different excitation energy of the compound nucleus and thus they have different observed energy spectra.

This could be done by having a pointer at the end of the AceEnergyDist pointing to another AceEnergyDist (as many times as necessary).

If you select a cross-section that doesn't exist, e.g. 92235.00c when it should be 92235.03c, OpenMC does not realize it and will fail.

Currently, OpenMC can only read ASCII ACE files. Extending to binary shouldn't be too difficult, but will need special handling of Fortran records.

Currently, the sampling of the Maxwell fission spectrum is done by a rejection sampling technique as in MCNP. This was historically done because evaluating a cos or sin used to be an expensive operation, so rejection sampling could be done faster. Nowadays with highly optimized trigonometric intrinsics, it makes more sense to just to direct sampling both because the performance is likely better and in the interest of clarity.

Runs ok with DEBUG turned on, but with DEBUG off and -traceback manually added, we get:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC        Routine            Line        Source             
openmc             08074FBE  xml_data_geometry          88  xml_geometry.f90
openmc             08074F2C  xml_data_geometry          58  xml_geometry.f90
openmc             08074765  xml_data_geometry         674  xml_geometry.f90
openmc             0805D30A  input_xml_mp_read         119  input_xml.f90
openmc             0805CBF0  input_xml_mp_read          26  input_xml.f90
openmc             0805C906  initialize_mp_ini          66  initialize.f90
openmc             0805FF0C  MAIN__                     26  main.f90
openmc             08049EC4  Unknown               Unknown  Unknown
libc.so.6          B7611E37  Unknown               Unknown  Unknown
openmc             08049DD1  Unknown               Unknown  Unknown

It would be nice to be able to catch interrupt signals when running in serial like MCNP is able to.

When running the input_sample problem, you just get the generic error:

 ERROR: Multiple interpolation regions not supported while attempting to sample 
        secondary energy distribution.                                          

When I created a slab reactor, I forgot to add in the material tags. When I ran openmc I got the following message:

===========================================================================
========================>     INITIALIZATION     <=========================
===========================================================================

Missing data on lattice_ - at or near line          41
Missing data on sab - at or near line           8
Missing data on material_ - at or near line           9
Segmentation fault

I would also suggest, having a better error statement for the user, especially since I do not have any lattices or sab info. In addition, maybe something along the lines of a warning if a material is associated with any cells.

Makes it up to reading geometry XML file and then fails with:

 Reading settings XML file...
 Reading geometry XML file...
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
openmc             00000000004E03D2  Unknown               Unknown  Unknown
openmc             00000000004DA022  Unknown               Unknown  Unknown
openmc             00000000004D98B9  Unknown               Unknown  Unknown
openmc             00000000004DBBA2  Unknown               Unknown  Unknown
openmc             00000000004E05DF  Unknown               Unknown  Unknown
openmc             00000000004A9005  Unknown               Unknown  Unknown
openmc             000000000040333C  Unknown               Unknown  Unknown
libc.so.6          00007FD154CF4EFF  Unknown               Unknown  Unknown
openmc             0000000000403239  Unknown               Unknown  Unknown

This will be based on directly sampling S(a,b) data from the ACE format given as equiprobable cosine and outgoing energy bins for a given incoming energy. Interestingly, MC21 empoys a direct S(a,b) sampling method whereby the original ENDF data tabulated on an a,b mesh is turned into pdfs p(b|E,T) and p(a|b,E,T) which can be directly sampled in the MC simulation. This eliminates some non-physical effects (observed by Bjorn Becker). See Clint Ballingers 1995 M&C paper.

The Shannon entropy has emerged as the primary means of detecting fission source (eigenfunction) convergence in a criticality calculation. The implementation is quite simple and is detailed in a number of papers by Forrest Brown. For a diagnostic criterion, the stochastic oscillator developed by Romano should be used.

The capability to calculate cell volumes is both an essential and non-trivial capability. It can generally be broken down into three types of calculations:

1. Rotationally symmetric bodies
2. Arbitrary polyhedra
3. All others (which must be calculated stochastically)

The algorithm for calculating cell volumes is outlined in LA-8113-MS.

Currently, although (n,xn) reactions are sampled, the secondary neutrons are not actually produced to be simulated during the cycle.

Currently, if ACE data specifies multiple interpolation regions, OpenMC cannot handle the data.

I did a simple test, homogeneous cube 10 cm in each direction. The material is half U-235, half Pu-239 by atom. My final k-effective is:

Final Keff (also kinf here) = 2.73037 +/- 5.58283E-04

I tally all macro reaction rates in this cube and get the following:

Cell 1
Total Reaction Rate 5.44065 +/- 2.81300E-03
Scattering Rate 4.41040 +/- 2.32543E-03
Scattering Production Rate 4.41392 +/- 2.79901E-03
Absorption Rate 1.03025 +/- 4.94128E-04
Fission Rate 0.951405 +/- 4.38750E-04
Nu-Fission Rate 2.73125 +/- 1.23006E-03

Looking at the neutron balance equation:

TotalRate = NuScatterRate + NuFissionRate/kinf

Computing: kinf = NuFissionRate/(TotalRate - NuScatterRate)
kinf = 2.73125/(5.44065 - 4.41392) = 2.66014

This is about a 1000 pcm difference, which is too large here. Also should the total reaction rate minus the scattering production rate be 1.00? Usually the denominator of the kinf calculation in MC is 1 and therefore Nu-Fission Rate is k-inf.

Do you see this same difference?

For commits between 3404aa and d5bc1a, the code successfully compiles with gfortran but when running the basic example problem halts with an error:

ERROR: No neutron emission data for table: 1001.03c

This is related to the addition of cross section caches, and more importantly the fissionable flag on each nuclide.

Would avoid all the USE statements all over the place, and would be pretty awesome in and of itself!

Currently the PRNG used is exactly that from MCNP. There is nothing wrong but it would be nice if the syntax were OpenMC-specific.

As far as I'm aware, this is the only remaining scattering law that is not implemented in OpenMC that actually occurs in data. However, it only exists for the (n,2n) reaction in H-2 so can be ignored safely for the time being.

From using the code, you are forced to have the xsdata file named xsdata. Wouldn't it be easier to just have the user specify the full path including filename?

Having the ability to plot geometry would be very nice for debugging geometry issues... Not sure what the best/established method is for doing 2D slice plots.

Currently, any data for discrete energy of photons emitted from Law 4, 44, or 61 data is disregarded. This is not important for us now because we don't have any photon transport, but if that were ever to be added in, we would need to be able to read those discrete photon energy distributions.

Looks like it violates an array out-of-bounds check:

forrtl: severe (408): fort: (2): Subscript #1 of the array ENERGY has value 251 which is greater than the upper bound of 250

Image              PC                Routine            Line        Source             
openmc             000000000061C67A  Unknown               Unknown  Unknown
openmc             000000000061B1F5  Unknown               Unknown  Unknown
openmc             00000000005CEEE6  Unknown               Unknown  Unknown
openmc             0000000000590AF5  Unknown               Unknown  Unknown
openmc             0000000000590F49  Unknown               Unknown  Unknown
openmc             0000000000478966  energy_grid_mp_ad         138  energy_grid.f90
openmc             0000000000475F3D  energy_grid_mp_un          40  energy_grid.f90
openmc             00000000004DCE6F  MAIN__                     83  main.f90
openmc             00000000004033CC  Unknown               Unknown  Unknown
libc.so.6          00007F09DE196D8E  Unknown               Unknown  Unknown
openmc             00000000004032C9  Unknown               Unknown  Unknown

Problem: 20cm cube now with 0.5 a% U-235, 0.25 a% Pu-239 and 0.25 a% H-1.

Tallying nu-scatter and nu-fission in the following energy groups
3: 0.0 0.625ev
2: 0.625eV to 500keV
1: 500 keV to 20.0MeV

The exact same numbers are shown for nu-scatter and nu-fission tallies in the tally.out file. Since there is no transfer of neutrons from a lower number group to a higher number group, I am guessing these numbers represent nu-scatter since there must be group to group transfer from g3 to g1 in nu-fission.

The path for cross-section files as specified in xsdata is currently hardwired at 100 characters. This should be expanded to allow for long paths.

As originally written, outgoing energy distributions using Law 1 did not perform scaled interpolation as specified in the MCNP manual. Law 1 doesn't appear to occur often in ENDF/B-VII data so this shouldn't affect results much at all.

Running Bryan's problem of a 50cm x 20cm x 20cm box, reflective boundary conditions in y and z, and a single mesh cell that covers the geometry. There are two problems with the reported results:

1. No outgoing current is shown on the left or right faces even though vacuum boundary conditions are used there. This is because the particle is killed before any surface currents are tallied.
2. Positive currents are reported on front/back/top/bottom even though there should be no current through those surfaces. When a particle is reflected off the y and z surfaces, surface currents are not scored until the particle reaches a collision, thus making xyz and last_xyz not very meaningful.

The results are:

Mesh Index (1, 1, 1)
    Outgoing Current to Left       0.0            +/- 0.0
    Incoming Current from Left     0.0            +/- 0.0
    Incoming Current from Right    0.0            +/- 0.0
    Outgoing Current to Right      0.0            +/- 0.0
    Outgoing Current to Back       0.0            +/- 0.0
    Incoming Current from Back     0.234552       +/- 8.86087E-04
    Incoming Current from Front    2.67500E-04    +/- 2.65489E-05
    Outgoing Current to Front      0.0            +/- 0.0
    Outgoing Current to Bottom     0.0            +/- 0.0
    Incoming Current from Bottom   0.235355       +/- 7.78403E-04
    Incoming Current from Top      2.42500E-04    +/- 2.49719E-05
    Outgoing Current to Top        0.0            +/- 0.0

Currently unresolved resonance data is read in but is not used. During the calculate_nuclide_xs routine, the data would need to be sampled to get a cross section.

Currently, timing is only done via MPI_WTIME(). This should be changed to Fortran intrinsics for time rather than MPI calls and expanded to measure common data, e.g. total run time, total time loading cross sections, total time reading input, total time in compute, total communication time, etc.

For a 1-D reactor (x-direction) I surrounded the y- and z- directions with reflective boundaries and vacuum in x-direction. Openmc gave me the following error:

 ===========================================================================
 =======================>     BEGIN SIMULATION     <========================
 ===========================================================================

 ERROR: After particle crossed surface -4, it could not be located in any cell a
       nd it did not leak.   

When I replace all the boundary conditions to vacuum, the simulation runs properly.

I realized today that if you take the union of the energy grids of all the nuclides in ENDF/B-VII, you end up with a union energy grid of about 4.5 million points. The pointer scheme may need to be modified- there is a strong motive to do some kind of thinning of the energy grid with that many points.

Really need some kind of unit testing framework for V&V.

Tom and Kord seem to have gotten very good results reducing variance in low flux regions by doing a uniform fission source weighting scheme. This would be nice to add to the code eventually.