About

Troubleshooting

TRDAT fails because it does not find a variable.

If TRDAT fails because it does not find a namelist variable, there is a good chance that the variable you are using is listed here .

Input data

When you submit your run, TRDAT will check for inconsistent settings in the namelist, but it is not going to check inconsistencies in the input data. This is your responsibility. Your run might fail at any time because the input data have problems. Here are a few things that you may want to check before submitting your run.

Density and temperature profiles

Make sure that the minimum value of density and temperature is above the minimum defined in the namelist.

If you are running in interpretive mode, make sure that the profiles do not have large discontinuities, both in radius and in time. If you are giving to TRANSP the time of sawtooth crashes and you are using the sawtooth model (not predictive), then check your profiles against the time of crashes. Remember that TRANSP interpolates between time steps, except around a sawtooth crash.

Please be aware that every density and temperature profile mapped using an EFIT that has not been constrained is introducing a systematic error in your simulations, be they interpretive or predictive. Yes, you hear correctly, because it is very likely that your predictive simulations are fixing everything outside XIBOUND, XNBOUND.

If your fitted density and temperature profiles are going to zero at the separatrix, you may want to check your data, your equilibrium and the position of the separatrix. You should not expect the calculated neutrons to match the measured neutrons if your profiles and equilbrium are off.

Plasma composition

Make sure that the input plasma composition Zeff from UFILE does not go below the unphysical value of 1.0. TRANSP assumes a minimum Z_eff=1.1, thus data will be rescaled to satify this minimum.

It is common habit to calculate offline a Z_eff profile from impurity profiles and give this to TRANSP. Remenber that TRANSP is including in the calculation of Z_eff also the thermalized fast ions. If the impurity density is measured, it is good practice to give these profiles to TRANSP and let it calculate the Z_eff. This is especially true in the presence of a single impurity (e.g. in Carbon wall machines, with no impurity seeding). It is always better to give to TRANSP quantities that are directly measured and compare calculated quantities with derived quantities, or with other measured quantities.

Z_eff (profile or 1D data) measurements are affected by large errors, so are radiation profiles. The reduction of these data is often subject to assumptions that are model-based. Giving either of these measurements to TRANSP might increase the uncertainties on the calculated neutron rate, for example.

Magnetic Equilibrium

Remember the following: the equilibrium from the magnetic measurements has large uncertainties. Far too often we have seen safety factor profiles with minimum below unity, which is unphysical. It is always a good idea to compare the magnetic equilibrium with a spectrogram. If you see evidence of fishbones and/or sawteeth and your q profile goes down to 0.5 (we have seen cases that use an equilbrium with q as low as 0.2), there is a problem. You should never submit a TRANSP run under these conditions.

Current diffusion

You are using TEQ (LEVGEO=11) and the run fails soon after TINIT.

This is most likely a problem with the convergence of the equilibrium and transport. It is possible that the pressure profiles (or density and temperature, separately) are not consistent with the equiilbrium. This usually happens when the kinetic profiles are processed separately from the equilibrium. Since TRANSP/TEQ need to use the data for initialization, if the data are inconssitent TEQ will fail. First, check that the first time point available for the equilibrium (MRY or MMX UFILES) is not posterior to the first time step in the profile UFILES. Then, you can do the following (a) change TINIT to a time where both the profiles and the equilibrium are available (b) start the current diffusion prediction only after a few time steps; this should do the job.

Transport

Your run fails with the message DT.LT.DTMIN

This indicates that variations for a given quantity are too large over a given time step and that errors are above the acceptance criterion even when TRANSP uses the shortest timestep (DTMIN). This error can occur either in interpretive or in predictive mode. Errors like this may indicate a problem with the input data, especially close to an event that casues discontinuities in the profiles, e.g. the injection of a pellet or a sawtooth crash. If you have this error, we recommend that you check carefully your input data and how they have been processed close ot the time of the crash.

Your run fails with the message that 'the ion temperature went negative'

This occur most commonly in the edge region and indicates a problem with the input data. Either the edge density is too low, or a very rapid upward spike in Zeff is causing the entire hydrogenic thermal plasma to be pumped out on a short timescale. The negative temperature occurs because of instabilities in the implicit solution for ion temperature which appear when the ratio of convective flow over density (i.e.: cross-flux-surface velocity) becomes very large.

Negative ion temperature in the edge region can occur when modeling the plasma rotation, for example if the input data indicate an increase in plasma angular momentum, but there is no corresponding torque (i.e. the beams have not yet been turned on). It should be noted that TRANSP can model the beam torque, but has no good model for intrinsic rotation, thus the momentum balance equation and the energy balance equation may fail under these circumstances. The problem can be minimized by making sure that the rotation is near zero before the neutral beams are turned-on (for example, by manipulating the angular velocity input data).

Your run fails with the message that a thermal ion species density is negative

This error typically indicates that the calculated fast ion density exceeds the electron density within some radial region. It may happen if the input electron density profile does not have sufifcient spatial resolution to resolve rapid radial variations that may occur in case of strongly peaked profiles (e.g. neutral beams injected in a low density plasma). It may also happen if the fast ion transport is affected by strongly non-classical effects, which at present are not modeled self-conssitently in TRANSP. A solution in this case might be to use anomalous fast ion diffusivity in the simulation. If this does not help, then probably TRANSP cannot be used to interpret this particular plasma discharge.