1 TRANSP_bugs This document contains information on known significant TRANSP bugs, which may have affected user results. Each bug description contains information on what type of runs are affected, how to distinguish affected runs, and an approximate range of dates when the bug was present in the operational or "production" version of the code. The month-year dates in the subtopics refer to the approximate date of discovery of the bug. 2 Feb_2009_Fast_ion_sawteeth For a long time (apparently at least since 2004) there has been a bug in the Monte Carlo fast ion sawtooth data, in cases where q<1 on axis but sawtooth mixing is suppressed due to multiple q=1 surfaces, a circumstance which the Kadomtsev and Porcelli sawtooth mixing models cannot handle. Instead of preserving the fast ion density through such a suppressed event, it was reset to zero. The internal Monte Carlo particle list is not disturbed; therefore the fast ion density recovers to a correct value by the end of the first fast ion time step after the suppressed event. 2 Jun_2008_FPPMOD_BUGFIX An error in FPPMOD (TRANSP legacy Fokker Planck solver) has been detected. Due to a long standing logic error (dating back to 2003 at least), the FPPMOD collision operator "missed" the contributions to drag and energy diffusion due to the last thermal ion species on the list of thermal ion species provided-- in TRANSP runs, this is always an impurity species. The impurity specie's contribution to pitch angle scattering was not omitted. In TRANSP runs with a single impurity with an integer Z value, this means the entire impurity contribution to drag and energy diffusion on RF minority fast ion distributions was omitted. In TRANSP runs with a single "model" impurity with a non-integer Z value, this is broken into two impurity species with integer Z values for use in FPPMOD; e.g. model Zimp=5.7 => Zimp_1=5, Zimp_2=6 in FPPMOD. The two impurity densities are chosen so as to conserve Zeff and quasineutrality; basically the impurity specie with Z closer to the model Zimp would have higher density. Regardless of the densities, the drag due to the impurity in FPPMOD with charge Zimp_2 was neglected. So, the effect of this bug would vary depending on the value model Z: Zimp=6 -- one impurity (drag & energy diffusion omitted). Zimp=6.1 -- two impurities at Zimp_1=6 and Zimp_2=7; drag & energy diffusion due to impurity Zimp_2=7 omitted, but its density is low. Zimp=6.9 -- two impurities at Zimp_1=6 and Zimp_2=7; drag & energy diffusion due to impurity Zimp_2=7 omitted, and this would account for most of the impurity density in the run. Some runs have a single model impurity with Zimp a function of time, in which case the magnitude of the effect of the error would vary In runs with multiple explicit impurities provided, only the last impurity on the list of impurities was omitted in the FPPMOD collision operator drag and energy diffusion terms. This bug was fixed on June 3, 2008. 2 Mar_2007_NCLASS_VPOL_AVG Flipped the sign on VPOL_AVG to make it consistent with the other VPOL_* outputs. Positive vpol is CW with respect to a slice of the tokamak. Wayne Houlberg's convention is opposite to this. 2 Sept_2006_TORIC5_Antenna_Height It was not noticed in the installation of TORIC4/TORIC5 into TRANSP, as an upgrade to TORIC3, that the definition of the TORIC namelist variable ANTLEN changed from being a half-height to a full height. The net effect of this was that prior to Sept 20 2006, all TRANSP TORIC4/TORIC5 runs had an antenna height parameter lower by a factor of two than was needed to transmit the antenna geometry data provided through the TRANSP namelist. This has now been fixed. 2 Sept_2006_Beam_momentum_balance An error in normalization of beam deposition model outputs caused the momentum balance to look much worse than it really is, when the number of Monte Carlo particles deposited per timestep was below a threshhold number (NDEP0). Some small contributions to beam torque-- JxB torque associated with the FLR step at beam deposition-- were made even smaller by this error in normalization-- now fixed. 2 August_2006_Sauter_Bootstrap_Current The Sauter bootstrap current was being computed with the magnetic diffusion Zeff instead of the plasma composition Zeff. When the magnetic field diffusion equation was not being run (NLMDIF=.false., or, the q profile evolution being specified from data), the Zeff used in the Sauter bootstrap computation was 1, regardless of the plasma composition Zeff. This has now been fixed. In addition, Jon Menard added an additional term to the bootstrap current which is proportional to the gradient of the average ion charge. (RGA 28Aug2006) 2 May_2006_Neutron_collimator Between July 2005 and May 2006, there was an error in the neutron collimator simulation, in which the thermonuclear contribution was increased by a factor related to the plasma volume in cm**3 -- i.e. the thermonuclear contribution is high by 4-5 orders of magnitude. A fix was committed to the TRANSP repository and the PPPL production code on May 2, 2006. 2 Apr_2006_Energy_adjusted_difb A bug was fixed in NUBEAM subroutine ABDIFU. This bug would have caused incorrect results in the fast ion anomalous diffusion model when BOTH the following conditions are satisfied: A. EDIFBE(...) and FDIFBE(...) namelist controls were used to adjust the fast ion anomalous diffusivity as a function of energy, --AND-- B. grad(Db) .ne. 0., where Db = the anomalous diffusivity. Runs with both these conditions are thought to be rare, but, any such run since the creation of abdifu.for (ca. 1990) would have suffered the consequences. A more detailed description follows: The Monte Carlo anomalous diffusivity random walk operator has to use both Db and grad(Db), in order to get a flux that averages to Db*grad(nb), rather than Db*grad(nb)+nb*grad(Db). In the presence of an energy correction, the multiplier was applied only to Db, not grad(Db). As a result, a non-physical radial flow of fast ions affected by FDIFBE < 1 values would have occurred. This bug has also affected the NUBEAM NTCC module. 2 Jul_2004_Bootstrap_current_on_axis Between approximately Sep. 4 2003 and Jul. 27 2004, there was a bug in the subroutine which sets up metric coefficients. This led to a certain formulation for the evaluation of a flux surface averaged gradient to be an order of magnitude high, but only on the first numerical flux surface just outside the magnetic axis; all other surfaces are OK. The most obvious effect of the bug is axially localized spikes in the traditional TRANSP "aspect ratio" bootstrap current, CURBSEPS. The larger the number of zones (NZONES) in the TRANSP run, the higher yet narrower the spikes would be. If this bootstrap current model is used (CURBS = CURBSEPS) with the poloidal field diffusion equation, then, an axially localized effect on the q profile would occur. There may have been subtle effects on some temperature prediction and some "mixing model" ion density prediction calculations over the same range of dates. Other aspects of the calculation (e.g. the neutral beam model) are not directly affected. Questions: email dmccune@pppl.gov 2 Apr_2004_Beam_current_shielding Between approximately Mar. 18 2002 and Apr. 19 2004, a bug existed in the calculation of shielded beam driven current, in cases where there were multiple Monte Carlo fast ion species with different Z values, such as: -- mixed beam injection involving isotopes both of H and of He4 -- cases with Monte Carlo simulation of He3 or He4 (alpha) fusion products in the presence of D and or T beams. NOTE that the latter situation may be fairly common for modeling of JET DT experiments. The problem was that although the neoclassical shielding factor was correctly evaluated separately for each species (nubeam/jbshld.for), the shielding factor from the last specie in the list of species being followed by the Monte Carlo code was incorrectly applied to calculate the shielded driven current by all fast species. Under certain circumstances the magnitude of beam driven currents could be strongly affected. The leading term in the shielding factor is (1 - Zb/Zeff) [1] in effect Zb=2 was being assumed for some Zb=1 species. The magnitude of the error is reduced in regions with a large trapping fraction. The problem has now been fixed. For 2004 runs, the presence or absence of this bug can be determined in the output as follows. The TRANSP output contains a multigraph (a named set of related output functions) called JBFACS: a) if JBFACS contains the profiles {JBFAC,JBFACZ1,JBFACZ2} then the data was generated with a version of TRANSP with the bug fixed. b) if JBFACS contains the profiles {JBFAC,JBFAC0,JBFACNC} then the data was generated by a version that still had the bug. [1] Hirshman & Sigmar, Nucl Fusion 21, 1079 (1981) -- section 8.2 2 Feb_2004_Toric3_interface Between approximately Sep. 1 2003 and Feb. 1 2004, there was an error in the TRANSP fppmod/Toric3 interface, which caused the wave code power to be displaced furhter inward radially than it should have been. The further out to the edge the RF resonance was located, the worse the error. Bug was found by analyzing behavior of a CMod run provided by C. Fiore at MIT. (D. McCune 2 Feb 2004) 2 Nov_2002_beam_deposition Two issues were discovered while tracking down differences in beam deposition models used in JET simulations: (a) XDEPMOD. The TRANSP namelist contains a pair of controls: NDEPMOD=<...> ! =0 for normal beam deposition ! =1 to enhance all beam stopping cross sections ! by an anomaly factor XDEPMOD ! NDEPMOD=0 is the default. XDEPMOD=<...> ! beam stopping anomaly factor, if NDEPMOD=1 ! default value XDEPMOD=1.0 has no effect. NDEPMOD acts as a "safety lock" on XDEPMOD. Unfortunately, during the extraction of the TRANSP Monte Carlo fast ion package "NUBEAM", TRANSP lost this safety mechanism, so that XDEPMOD was applied, regardless of the setting of NDEPMOD. TRANSP runs containing non-default settings of XDEPMOD in their namelists were affected, from (approximately) July 2002 until November 13, 2002. Regression testing missed this, because the test namelists used the default (XDEPMOD=1.0). (b) Approximate excited states correction (NSIGEXC=1). Due to a bug introduced early in the NUBEAM modularization work, the excited states correction beam stopping cross section was used for a beam at the maximum energy in an excited states atomic physics table, rather than the actual beam energy. This caused the beam stopping rate to be erroneously 10-20% higher than it should have been, depending on the details of the case. This is enough to significantly affect shine through and deposition profile shapes, in some cases. This bug occurred in runs using NSIGEXC=1 in their namelists, from approximately July 2001 through Nov. 13, 2002.