Known issues (Updated August 14, 2013)

Report any suspected bugs and unexpected behavior here

Known issues (Updated August 14, 2013)

Postby Jaakko Leppänen » Tue Mar 23, 2010 7:04 pm

There are several known problems and limitations that do not affect most calculations, but may become a problem in some particular case. If you suspect a new bug or encounter any unexpected behavior, report it by starting a new thread. This topic is reserved for discussion concerning the confirmed problems listed below, and I will update the list whenever a new bug is identified or an old problem is fixed.

1) Universes cannot be used at multiple levels: If you need identical structures at several levels, you need a duplicate definition using a different universe number. The surfaces may be the same.

2) Lattices are not allowed directly inside other lattices: For example, if you have lattice 10 defining the loading pattern of fuel assemblies inside the core and lattice 20 defining the pin array inside one of the assemblies, you cannot put lattice 20 directly inside lattice 10. Instead you need to define an additional universe (21) that contains lattice 20 and use that in the definition of lattice 10. So the hierarchy is: "LAT 10 -> UNIV 21 -> LAT 20", not: "LAT 10 -> LAT 20". An error message stating the problem was added in update 1.1.10, earlier versions simply lead to strange geometry errors.

3) Fission cross sections and nubar data is assumed to exist for all actinides (Z > 89): This data may be missing in some ACE libraries for the highest actinides (Z ~ 100) or otherwise rarely used isotopes, which will cause the calculation to fail.

4) Complicated ENDF decay modes are converted to single reactions: The decay data for some short-lived nuclides lists multiple reactions combined together (two consecutive beta-decays, etc.). These reactions are handled separately, i.e. by considering only the first decay mode. This should not be a problem, provided that data exists for the daughter nuclide(s) as well (I am assuming it does). NOTE 2/17/2013: this looks like a major issue after all (see related post).

5) Relativistic speeds are taken into account only in the calculation of kinetic parameters (1/v), not in physics: The approximation probably leads to errors in the alpha eigenvalue mode.

6) Division of fuel pins into annular depletion zones works only for simple pins: If the pin contains multiple material regions that are involved in burnup calculation, only the innermost region is divided. More complicated structures must be defined manually.

7) Nuclides with thermal scattering data are not depleted: If a depleted material contains moderator with associated thermal scattering data, the composition of the nuclide remains constant. [Fixed in update 1.1.14]

8) Serpent cross section libraries lack data for C-14.

9) Calculation of assembly discontinuity factors fails when group constant data is calculated in multiple universes: I wrote this note some time ago and forgot what it actually means. It must be related to multiple entries in the "set gcu" parameter. [Fixed in update 1.1.11]

10) Geometry plotter plots surface lines incorrectly if the range is extended over reflective or periodic boundaries: This is a feature of the plotter only, and not a problem in the tracking routine.[Fixed in update 1.1.14]

11) Energy dependence of the fission yields of Xe-135 and its precursors is not taken into account in equilibrium xenon calculation: The code reads the first yield encountered in the data, which for fissile isotopes is usually for thermal energies.

12) Equilibrium xenon calculation may not work with unresolved resonance probability table data: You may get an answer that is close to the correct value but there is a methodological problem in the routines. (8/25/2010: This may not be a problem after all)

13) Unresolved resonance probability table treatment fails for natural elements (40000.06c, etc.): The energy binning for probability table data has a different format for single nuclides and natural elements and there is a difference to MCNP results if the sampling is enabled for natural elements. The treatment was disabled for natural elements in update 1.1.10, which seems to fix the problem (I suspect that MCNP is actually not using this data either, as negative energy boundaries are printed in the output).

14) Branching ratios to isomeric states after neutron capture are not read from data: The branching ratios are not included in ACE format cross section libraries, and Serpent uses fixed values instead. Parent nuclides that produce isomeric states are: Am-241 (0.885), Am-243 (0.950), Pm-147 (0.530) and Ag-109 (0.059). The numbers are probabilities to produce the daughter nuclide in ground state. If you have additional branching data that you think should be included in the burnup calculation, please let me know.

15) The initialization of random number generator in parallel calculation (MPI) mode: I'm not exactly sure how the random number generator should be initialized when the calculation is divided into multiple tasks. To retain independence, each parallel task should start its own random number sequence, without repeating the values used by other tasks. There was a problem in the initialization before update 1.1.10, that caused clear bias in the results when the number of MPI tasks was very large. The corrected routine now takes the seed number given by the user or taken from system time, and adds a large integer multiplied by the MPI task number to get the seed for each individual task. This is a somewhat unfamiliar territory for me, and any comments and better suggestions are most welcome.

[Added March 31, 2010:]

16) Unresolved resonance probability table sampling not fully implemented with transmutation cross section calculation mode 2: When transmutation coefficients are generated for burnup calculation using the spectrum method ("set xscalc 2", see Sec. 8.4 of the User's Manual), probability table sampling affects only the micro-group spectrum that is used for collapsing the cross sections. The point-wise cross section data used by the routine is infinite-dilute. [Fixed in update 1.1.11]

[Added June 6, 2010:]

17) Reflective boundary conditions with hexagonal surface types: Reflective boundary conditions make no physical sense when used with hexagonal surfaces, unless there is certain symmetry in the geometry. In such case, however, both reflective and periodic boundary conditions produce the same result, and serpent always handles repeated hexagonal boundaries as periodic. Two hexprismatic surfaces were added in the code at a later stage, and the coding was not changed to accomodate for the fact that reflections and translations may produce different results in the axial direction. The result is that the boundary conditions are always periodic with hexagonal cylinder and prismatic boundaries, even if the condition is set to reflective. [Fixed in update 1.1.12]

[Added June 9, 2010:]

18) ENDF law 67 is not supported: Sampling from ENDF reaction law 67 (laboratory angle-energy law) is not implemented. This reaction law is rarely used, and nuclides using it must be replaced with other data. [Partially fixed in update 1.1.12 (the data is read without stopping but the reaction is omitted in the physics)]

[Added June 17, 2010:]

19) Memory usage is limited to 16 Gb: Serpent defines various local pointer variables as 32 bit integers and cannot access data beyond 16 Gb in the main data array. [Fixed in update 1.1.12]

[Added July 29, 2010:]

20) Small discrepancies in probability table treatment: When running a very large number of neutron histories, results of criticality calculations sometimes show small systematic discrepancies in k-eff (in the order of 20 pcm) compared to reference MCNP calculations. These discrepancies most likely originate from some small error in probability table sampling. In most cases the discrepancies are below statistical accuracy. The problem is probably related to problem 34 below.

[Added August 25, 2010:]

21) Cross section calculation mode 2 with probability table sampling in parallel burnable calculation: The calculation of transmutation cross sections using mode 2 (xscalc 2) doesn't work with unresolved resonance probability table sampling when the code is run in the parallel calculation mode. [Fixed in update 1.1.13]

[Added September 2, 2010:]

22) Time steps in constant flux burnup calculation: When reaction rates are normalized to flux and depletion steps given in units of burnup, the predictor-corrector method fails to calculate correct time steps. The problem doesn't concern constant power burnup calculation or depletion steps in days. [Fixed in update 1.1.14]

23) PN scattering cross sections and P1 diffusion parameters in geometries with voids: When there are void regions in the geometry, PN scattering cross sections (SCATT0, SCATT1, SCATT2 ... SCATT5) and P1 diffusion parameters (P1_TRANSPXS, P1_DIFFCOEF, P1_MUBAR) are over-estimated. The same problem has been identified and fixed for all the other group constants (see description). [Fixed in update 1.1.14]

24) Comment sections and line numbers: The code prints error messages refering to line numbers in the input file. The line numbers are wrong if the input error occurs after a comment section consisting of mutiple line between C-style separators, '/*' and '*/'. [Fixed in update 1.1.14]

[Added November 23, 2010:]

25) Equilibrium Xe-135 calculation in burnup mode: Equilibrium xenon calculation fails after the first depletion step in burnup calculation mode in versions 1.1.13 and 1.1.14 (see description and quick fix). [Fixed in update 1.1.15]

26) Fuel shuffling one step too early: Fuel shuffling in burnup calculation mode is perfomed one step too early (see description).

[Added December 10, 2010:]

27) Pu-239 fission data in JEF-2.2 cross section library: There is a known flaw in the the fission spectra of partial fission channels of Pu-239 in the JEF-2.2 evaluated nuclear data file (see description in page 120 of JEFF Report 17). This problem is reproduced in the ACE format data if the file is processed with the default options of NJOY. This is the case with the JEF-2.2 cross section libraries distributed with Serpent base versions 1.1.0 and 1.1.7.

[Added June 2, 2011:]

28) Non-fissile burnable materials: Burnup calculation may end up in an error message if there are non-fissile burnable materials in the geometry and fissile nuclides in the inventory list. (see description and fix). [Fixed in update 1.1.15]

[Added June 10, 2011:]

29) Coincident energy points and Doppler-broadening routine: Coincident energy points in the ACE format data will cause the Doppler-broadening preprocessor routine to fail. (see description and fix). [Fixed in update 1.1.15]

[Added August 10, 2011:]

30) Errors in inelastic scattering at high energy: There are several minor problems in the sampling of ENDF reaction laws for inelastic scattering at high energy, that might affect the results of external source calculations. (see description). [Fixed in update 1.1.16]

[Added August 18, 2011:]

31) Problem in conversion script: The xsdirconvert.pl script distributed with the NEA/RSICC installation package with code version 1.1.7 has a flaw in the processing of atomic masses. The problem has been fixed in a new version. (see description).

[Added August 24, 2011:]

32) Handling of erroneous ACE data: When the ACE format data libraries contain errors, the outcome may differ signifiantly from other codes (see description).

33) Partial reaction modes to excited states: Serpent doesn't identify partial reaction modes that lead to the formation of excited states (except for two-body inlastic scattering). For most nuclides these reaction modes are redundant, as the data contains the corresponding total cross sections that can be used in the transport calculation. There are, however, a few exceptions, such as Be-9 in JEFF-3.1 and -3.1.1, which is entirely missing the total (n,2n) cross section. This is a very important reaction at high energy, and the data should be used with caution.

[Added October 27, 2011:]

34) Probability table sampling and fission nubars: Unresolved resonance probability table sampling has a methodological flaw that results in erroneous values for fission nubars and fission neutron and energy production cross sections. The impact is most likely insignificant for most nuclides, but large errors have been encountered at least for Pu-238 (see related post). The problem affects at least group constants NSF, B1_NSF, NUBAR and FISSE, some point-kinetic parameters and all k-eff estimates except ANA_KEFF. The error is also carried into normalization, which may affect the relation between flux and fission power, which in turn may affect burnup calculations. This methodological flaw is probably related to the small reactivity discrepancies reported in problem 20. [Fixed in update 1.1.17]

35) DBRC with double-indexing: The Doppler-broadening rejection correction method (DBRC) fails when used with double-indexing. The failure is caused by a pointer error, which may produce completely unphysical results. [Fixed in update 1.1.17]

[Added April 23, 2012:]

36) Incorrect branching ratio for Am-243: The isomeric branching ratio for the neutron capture of Am-243 is incorrect. (see description). [Fixed in update 1.1.18]

[Added June 6, 2012:]

37) Reflected boundary conditions for cube and cuboidal boundaries: Axial reflections in cube and cuboidal outer boundaries are incorrectly handled as periodic transition. (see description). [Fixed in update 1.1.18]

[Added August 4, 2012:]

38) Umlauts not recognized: Umlauts (å, ä, ö, etc.) in input files, even in comment lines, may result in an error message claiming that the file is not in ASCII format.

[Added August 8, 2012:]

39) MPI and statistics: Running the calculation in parallel MPI mode may lead to statistical problems if the population size is not sufficiently large. (see related post).

[Added October 16, 2012:]

40) Doppler-broadening and thermal scattering libraries: The Doppler-broadening preprocessor routine does not work with materials associated with S(a,b) thermal scattering data. If the temperature is adjusted, the code fails to link the thermal scattering libraries to the bound scatterer.[Fixed in update 1.1.19 (calculation terminates with error)]

[Added November 28, 2012:]

41) Double-indexing with unresolved resonance probability table sampling: The transmutation cross sections of nuclides with unresolved resonance probability table data are over-estimated when both double-indexing and ures probability table sampling are used in burnup mode (see related post).[Fixed in update 1.1.19]


[Added February 13, 2013:]

42) Conversion script fails for Co-58m: The xsdirconvert.pl script writes an incorrect ZA value for Co-58m in the directory file when applied to the Serpent data libraries (see related post). [Fixed in the new version of xsdirconvert.pl]

[Added March 21, 2013:]

43) Resolution of Serpent cross section libraries: In some systems, the relatively high NJOY reconstruction tolerance used for generating the Serpent ACE libraries may cause small but noticeable differences compared to high-resolution data (see related post).

[Added August 13, 2013:]

44) Error caused by surface current detectors: Re-use of a variable causes error in other detectors if surface current detectors are defined (see related post).

[Added August 14, 2013:]

45) Segmentation fault in long calculations: Some very long calculations may cause segmentation fault or other memory-related error at the beginning of active cycles (see related post).

[Added April 2, 2014:]

46) Incorrect branching ratio for Ag-109: The isomeric branching ratio for the neutron capture of Ag-109 is incorrect. (see related post).
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby bingham » Fri Mar 26, 2010 12:58 am

in response to
15) The initialization of random number generator in parallel calculation (MPI) mode: I'm not exactly sure how the random number generator should be initialized when the calculation is divided into multiple tasks. To retain independence, each parallel task should start its own random number sequence, without repeating the values used by other tasks. There was a problem in the initialization before update 1.1.10, that caused clear bias in the results when the number of MPI tasks was very large. The corrected routine now takes the seed number given by the user or taken from system time, and adds a large integer multiplied by the MPI task number to get the seed for each individual task. This is a somewhat unfamiliar territory for me, and any comments and better suggestions are most welcome.


Perhaps you can use a different random number generator algorithm to seed each parallel calculation then the algorithm you use within SERPENT. By doing this you avoid overlapping random number generation if the stride on your random number generator within SERPENT is sufficiently large.

I think it is important that MPI runs be just as reproducible as single processor runs. If you were to use system time as a seed then you would lose exact reproducibility. Admittedly, I am not expert on this subject, but I think it may be a solution.
bingham
 

Re: Known issues

Postby Jaakko Leppänen » Fri Mar 26, 2010 3:57 am

bingham wrote:Perhaps you can use a different random number generator algorithm to seed each parallel calculation then the algorithm you use within SERPENT. By doing this you avoid overlapping random number generation if the stride on your random number generator within SERPENT is sufficiently large.

I think it is important that MPI runs be just as reproducible as single processor runs. If you were to use system time as a seed then you would lose exact reproducibility. Admittedly, I am not expert on this subject, but I think it may be a solution.


Thanks for the comment!

Actually, all Serpent calculations are reproducible since the random number seed is taken from system time only by default. The value can also be set by the user, using the "set seed" input parameter. The code writes the value in variable SEED in the <input>_res.m output file and also in a separate seed file (<input>.seed). Running the calculation with "-replay" command line argument forces the code to read the value from an existing seed file, and the previous random number sequence is repeated.

The problem with using a different algorithm for each MPI task is that the number of tasks is not limited, and there probably is only a limited number of algorithms for generating (pseudo) random numbers. Currently the code uses the standard C-function "drand48()" for generating the values and "srand48(seed)" for initializing the generator.

To retain reproducibility in parallel calculation, the code uses a single seed value in the MPI mode as well. In an effort to make the random number sequences for each task independent of each other, a large integer (mpiid*10000000000000, where mpiid is the task number) is added to the main value before initializing the generator for the MPI tasks. The idea is that the sequences are independent, as long as they are less than 10000000000000 samples long.

Or at least that's my reasoning. Actually I haven't really had the time to look into the problem more thoroughly, so any expert comments are most welcome!
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby Jaakko Leppänen » Wed Mar 31, 2010 10:12 pm

I added item 16 in the list above (this message is just to get your attention)
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby aarnio » Tue Apr 06, 2010 1:29 pm

Hi,
There are high quality rendom number generators with inherent
capability for generating paralled random number sequences that
do not overlap, for instance, Mersenne twister and PRNG.

http://stat.fsu.edu/pub/diehard/


http://www.springerlink.com/content/dr6k2t51816w4471/

Pertti Aarnio
aarnio
 
Posts: 1
Joined: Tue Apr 06, 2010 1:00 pm

Re: Known issues

Postby Jaakko Leppänen » Wed Apr 07, 2010 5:37 pm

aarnio wrote:Hi,
There are high quality rendom number generators with inherent
capability for generating paralled random number sequences that
do not overlap, for instance, Mersenne twister and PRNG.

http://stat.fsu.edu/pub/diehard/


http://www.springerlink.com/content/dr6k2t51816w4471/

Pertti Aarnio


Thanks!

I'll start looking into that, and hopefully have a better random number generator in the next update.

The basic description of Mersenne twister (with example implementation in pseudo-code) is found even in Wikipedia. I don't exactly know how the parallel version would be implemented, but I can think of two options:

1) Use a different seed number for each MPI task in the initializator routine (are the sequences independent if the seed for each task is calculated from the be base seed: "seed(n) = seed(0) + n*large_integer"?)

2) Take different numbers from the array of 624 values for each task (what if the user initiates more than 624 tasks?)

It will be some time (at least several weeks) before I can get to the actual coding, so it would really help to have some discussion going on about the methods before that (rather than a discussing afterwards why the method doesn't work). As I mentioned earlier, this is not the most familiar territory for me.
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby Jaakko Leppänen » Thu May 20, 2010 11:30 am

Items 9 and 16 in the list above were corrected in update 1.1.11.
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby Jaakko Leppänen » Thu Jul 01, 2010 3:53 pm

Items 17 and 19 were corrected in update 1.1.12. Item 18 was partially fixed.
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Re: Known issues

Postby Andrei Fokau » Fri Jul 16, 2010 3:52 pm

It can be a good idea to make this post "sticky", so it will be listed above bug posts.
KTH Reactor Physics (Stockholm, Sweden) neutron.kth.se
Andrei Fokau
 
Posts: 77
Joined: Thu Mar 25, 2010 12:25 am
Location: KTH, Stockholm, Sweden

Re: Known issues

Postby Jaakko Leppänen » Thu Jul 22, 2010 2:11 pm

Thanks for the tip!
- Jaakko
User avatar
Jaakko Leppänen
Site Admin
 
Posts: 1982
Joined: Thu Mar 18, 2010 10:43 pm
Location: Espoo, Finland

Next

Return to Bug reports

Who is online

Users browsing this forum: No registered users and 3 guests