SCALE v6.2.4, released in June 2020, is a maintenance update to the 6.2 series. Please see the 6.2.4 README for installation instructions and additional details about the changes listed below, or the 6.2.4 manual for a complete code reference. New users of the SCALE 6.2 series may obtain the software by following these instructions. Existing users with an up-to-date licenses should contact scalehelp@ornl.gov for the latest production release.
Significant Software Errors
SCALE CSAS5S+CE+SOLN (9/1/2022)
In SCALE 6.2.2–6.2.4, the use of the SOLN material composition input specification in the CSAS5S sequence with CE nuclear data can lead to significant underprediction of keff. This issue only occurs in the CSAS5S sequence, where the “S” denotes the search capability to find optimal moderation conditions. There is no issue with CSAS5, the standard criticality safety analysis, without the search capability. Additionally, this issue is triggered by the user’s specification of the legacy SOLN input format instead of using the contemporary “solution … end solution” input approach. The use of the input shown in Figure 1(left) leads to a significant underprediction of keff. Note that there is no unexpected keff discrepancy when using the contemporary “solution” material input format or when performing multigroup (MG) transport. This user notice confirms the potential SSE that was identified to users via email from the SCALENEWS mailing list on May 13, 2022.
Please find a full description of the error in this software error report. Users should review their CSAS5S inputs; if they use a CE cross section library and the legacy SOLN material input specification, then their results may be affected. For any further clarification, please contact scalehelp@ornl.gov.
SCALE 3D General Geometry and CHORDs (4/1/2021)
In SCALE 4.4-6.2.4, the SCALE 3D General Geometry Package (SGGP) which provides the engine for "KENO-VI-style" geometry, may not correctly process the specification of multiple CHORD modifiers when defining a truncated shape. This problem occurs due to a memory error. Tests with the official SCALE 6.2.4 release binaries for Linux and Mac result in an abrupt termination of the calculation. Release binaries for Windows appear to use the intended geometry, but caution is advised given the behavior is compiler-specific and the underlying error still is present in the code. For users of sequences downstream of SGGP, including CSAS6, MAVRIC, TRITON (t6-depl), TSUNAMI (tsunami-3d-k6), STARBUCS (with KENO-VI geometry), and MCDANCOFF, who have built SCALE from source, the recommendation is to run the sample problems provided herein and to examine the results. Note this error does not affect CSAS5 which uses KENO V.a.
Please find a full description of the error in this software error report. For those users who have recompiled from source, we would be interested to know if you can reproduce the defect with your custom build (run the input in Figure 3 in the software error report). For any further clarification, please contact scalehelp@ornl.gov.
Polyethylene Hydrogen Thermal Scattering (2/26/2021)
In SCALE 6.1.0-6.1.3 and 6.2.0-6.2.4, h1 poly incoherent elastic scattering can cause k-eff underprediction approaching 1% in criticality problems with polyethylene as the primary moderator. Note that there is no discrepancy for hydrogen-1 in h2o. Users should review their problems for the use of h1-poly as a significant moderator and understand the bias that is introduced.
Please find a full description of the error in this software error report. The fixed h-poly data, examples on how to use the fixed data, and an FAQ are available in these supporting files. For any further clarification, please contact scalehelp@ornl.gov.
SCALE v6.2.4 includes the following fixes:
STDCOMP
Missing element isotopic distribution check
An issue has been fixed in SCALE 6.2.4 where the Standard Composition Library (STDCOMP) and related functions did not include an input check that certain elements must have user-defined isotopics. The elements listed in Table 7.2.2 have natural abundances which define a default isotopic distribution. Elements not listed in table include Tc, Pm, Po, At, Fr, Ac, Pa, and all actinides with atomic numbers greater than 92 (Np, Pu, Am, Cm, Bk, Cf, Es, etc.). For these elements, which are referred to as non-naturally occurring elements, the isotopic distribution is strongly dependent on the production source and decay time of the material, and the user is required to enter isotopic distributions for these elements or to simply enter the isotopic number densities directly. In SCALE versions 6.2.0-6.2.3, this check was not operating as intended.
The main area of concern, and why this was elevated to a high-priority fix, was that in SCALE 6.1 and previous versions, non-naturally occurring Pu was mapped to a fictitious “natural” abundance of 100% 239Pu, mainly as a shortcut for defining limiting, maximum reactivity systems. This artificial behavior was removed in the SCALE 6.2 feature release. Because of the change in default behavior for Pu and the lack of a complete input check, an incomplete input that does not specify the isotopic distribution for materials with a non-naturally occurring element could have generated a non-conservative result in versions 6.2.0-6.2.3.
KENO
Doppler broadening rejection correction on Windows
An issue has been fixed in SCALE 6.2.4 where DBRC data was not being correctly loaded on Windows in 6.2.3, and with the DBR=2 option there was no indication that the data was not loaded and the calculation proceeded without warning. The easiest way to verify whether a calculation was affected was to rerun with DBR=0, and if the random walk was identical, then the DBRC was not successful. Note that there was no such defect on Linux and Mac systems.
Kinematics data setup
An issue has been fixed in SCALE 6.2.4 where including a thermal moderator nuclide (e.g., H-1) at multiple temperatures in the input was not handled correctly. This issue was introduced in 6.2.2 and affects both TRITON and CSAS calculations which utilize KENO as the transport solver. It was discovered when inconsistent results were observed in TRITON as a function of the addnux parameter. H-1 existed in the moderator (585K) as expected but was also introduced into the fuel at 900K, as part of the automatic depletion setup with the addnux parameter. The bias introduced in eigenvalue is estimated to be less than 200 pcm.
ORIGEN
Large decay steps may lead to certain (alpha-n) sources not being included
An issue has been fixed in SCALE 6.2.4 where in ORIGEN calculation of (alpha,n) sources for 10 million years decay, ORIGEN did not include Am-241 in the results. This issue was due to floating point comparisons applied to the final time isotopics where very little Am-241 was left, leaving out Am-241 in early times. The parameter alphan_cutoff has a default to include all potential sources, so this was unexpected behavior. Although it is recommended to update to SCALE 6.2.4 for ORIGEN users, a workaround for SCALE 6.2.0-6.2.3 users is to use a single case for each decay step, effectively forcing the (alpha,n) source criteria to be applied at each time step.
ORIGAMI
Zero decay length in cycle
An issue has been fixed in SCALE 6.2.4 where ORIGAMI did not allow some valid power histories which occur when one wants to model a fine-grained power history with no intermittent decay as shown below.
cycle{ power=30 burn=1 down=0 }
cycle{ power=31 burn=1 down=0 }
In SCALE 6.2.3 only, the calculation would end with an error if “down=0” were used. A workaround in that case was to use “down=1e-5”, which will not alter results on the important time scales.
TRITON
Material Swap
An issue with the TRITON swap capability has been fixed in SCALE 6.2.4, where the TRITON swap capability did not function correctly in many scenarios. The extent of the error was not fully categorized but the error is due to incorrect bookkeeping of the volume of mixtures involved in the swap. All users of the TRION swap capability are encouraged to update to 6.2.4.
MAVRIC
Response generation from CE cross-sections
An issue was fixed in SCALE 6.2.4 where MAVRIC could not perform CE responses for nu-fission. The nu-fission reaction (mt=1452) is useful as a response and is supported for MG simulations. However, this reaction is not present in CE libraries directly; rather it is calculated as a multiplication of nu-bar (mt=452) and σf (mt=18) fission cross sections during the response generation. MAVRIC CE responses for the nu-fission reaction are now enabled in 6.2.4.
Although they are not as common as flux-to-dose conversion factors or neutron cross section responses, photon cross section responses may be defined in MAVRIC. However, a defect was identified in 6.2.3 when using macroscopic cross sections for responses with photon cross sections. This issue has been fixed in 6.2.4.
Other Minor Miscellaneous Issues Fixed in SCALE 6.2.4
- A minor formatting issue in the MCNP card output of ORIGAMI was fixed. This MCNP card enables users to generate MCNP sources directly in the MCNP format based on ORIGAMI-calculated spent fuel isotopics.
- A minor issue was corrected in Fulcrum where the mesh viewer could fail to remove loaded mesh files, requiring a restart of Fulcrum to deallocate program memory associated with mesh data.
- A minor issue was fixed in MAVRIC where some input blocks required lower case, even though SCALE is case insensitive for keywords.
- A minor issue was fixed in the legacy “solution” composition input where an upper-case composition name failed to be processed. The issue was due to a missing case conversion on the “solution” composition name that was used for the standard composition library composition STDCOMP lookup.
- A minor issue was fixed where CSAS printed the incorrect atomic weight for 18O in the mixing table output when running in MG mode. The correct atomic weight is now printed.
- A minor issue was fixed in ORIGEN when using “previous=0” to load isotopics from a previous “case” in the input.
- A minor issue was fixed in ORIGEN’s FIDO interface, in which data file paths were truncated to 80 characters. When reading files in the SCALE installation directory, data directory, or temporary directory plus the file path of more than 80 characters, the code would terminate with a “file not found” error. The only workaround was to move or symbolically link the relevant directories to shorter paths. The paths have been extended to 1,024 characters in 6.2.4.
- A minor issue was fixed in which the ZA column in the CSAS mixing table output edits did not show the correct value for the free gas hydrogen (nuclide ID 8001001), for example. The ZA should have shown 1001, but instead it just repeated the nuclide ID.
- A minor issue was fixed in all MG calculations in which the incorrect atomic weight for 18O was shown in mixing tables as 18.1551 instead of 17.9992. This cannot affect a calculation because the 18O cross section is zero in ENDF/B-VII.
- A minor issue was fixed in which the CSAS5 mesh tally capability did not function correctly, especially for the grid flux and fission source distribution mesh tallies, if the specified mesh in the grid geometry block covered only a fraction of the global geometry.
- A minor issue was fixed in the AmpxMGConverter utility, which allows SCALE 6.2 MG libraries to be converted to the previous SCALE 6.1 MG format. The conversion of SCALE 6.2 formatted macroscopic MG libraries to SCALE 6.1 formatted MG libraries has not been operational in SCALE 6.2.0-6.2.3. It now works as expected in SCALE 6.2.4.
- A minor issue was corrected in SCALE's installation testing. SCALE deploys with a test suite of regression and sample problems designed to verify the installation on a particular computer. Due to small differences in the way different CPUs round and perform basic mathematical operations, the random particle histories of the Monte Carlo transport codes in SCALE cannot be made identical for two different systems. In order to overcome this difficult on installation testing, a fuzzy tolerance is used to check the local machine result (a) versus the deployed baseline result (b). In the case both results have uncertainty, the check was looser than intended doing a simple overlap of the uncertainty bands. The check was updated to
where N=3 is typically used and σ is a standard deviation reported by the code. The previous test criteria used 
with most tests at the N=2 sigma level. With the new, better test criteria but the old N=2, there was a handful of failures on Windows when the baseline was generated on Linux. Given we are running hundreds of tests, this is statistically within expectations. Users should not be concerned that the old testing was incorrect. With either test criteria, a failure indicates either an installation failure or an "unlucky" random walk far outside expectations.