Frequently Asked Questions

Typical causes: inconsistent radius definitions (ψ_N vs ρ_tor), time misalignment between EFIT and profiles, or invalid/legacy q–/g–file fields.

Checklist:

1. Be explicit about radius: If EFIT uses ψ_N∈[0,1] but profiles use ρ_tor, convert one to the other before the run.
   Example: if your profile file is labeled “rho”, confirm whether it is ρ_pol or ρ_tor. If unsure, plot the profile against the EFIT LCFS and check the edge at 1.0.
2. Align times: Provide EFIT at the same times as the profile timebase, or keep EFIT static and resample all profiles to that single time.
   Example: if profiles are at t=[2.0, 2.5, 3.0] s, provide EFIT at those times or resample profiles to EFIT’s 2.5 s.
3. Sanity-check the grid: Ensure R and Z grids are monotonic, boundary points are present, and units are SI (m, T, A).

If LCFS is offset: verify that any smoothing/regridding you performed did not shift axis/LCFS. Re-extract axis, LCFS, and compare.

Diagnosis: plot a known feature (e.g., temperature pedestal) versus your radius and versus EFIT’s ψ_N. A constant radial stretch almost always means a coordinate mismatch.

Fix: convert radii to match EFIT (preferred) or configure the code’s mapping inputs to declare each profile’s coordinate.

Practical tip: normalized coordinates should stay within [0,1]. Values slightly over 1.0 usually indicate the wrong normalization.

Use the same timeslice and same radius definition across EFIT, profiles, and H&CD inputs.

• NBI/ECH launch geometry must be referenced to the same EFIT used by transport.
• If you smooth or regrid EFIT, repeat the deposition sanity check afterwards.

Causes: typos, deprecated names, or duplicate keys (last-one-wins).

&! BAD (duplicate keys, trailing tabs)
LEVGEO = 11  	
LEVGEO = 1

&! GOOD (single authoritative value)
LEVGEO = 11

Fixes: remove duplicates; check the current manual page for renamed keys; avoid stray tabs at end-of-line.

Checklist:

• File is plain ASCII with a consistent delimiter (spaces or commas), no locale commas for decimals.
• Units are consistent (density in cm⁻³, temperature in eV or keV — pick one and stick to it).
• Radius and time grids are monotonic; remove duplicates.

Example minimal radial profile (ρ, n_e):

# rho_n   ne_cm3
0.00      4.5e13
0.50      3.0e13
1.00      0.5e13

Use a small overlay namelist that is applied last in your submit script, containing only the keys you change. Keep a README noting which keys you override.

&! base.nml
LEVGEO = 11
ZEFF_MODEL = 2

&! override.nml
ZEFF_MODEL = 3  &! only changed key

Check quasi-neutrality: n_e ≈ Σ Z_i n_i. If you supply both composition and Z_eff, they must be consistent.

Example consistency check: D (Z=1) + C⁶⁺ at 2%: n_e ≈ n_D + 6·n_C. If measured n_e is lower than this, your impurity fraction is too large.

Keep Z_eff radial profiles within physically plausible bounds (e.g., 1–3 for many cases) unless you have strong diagnostics to justify otherwise.

Use monotone/shape-preserving interpolants for positive quantities (n, T, χ, D) and re-enforce boundary conditions at ρ=0 and ρ=1.

Practical tip: if smoothing is required, clip to nonnegative and re-normalize if needed.

Ensure impurity species/charge states used in radiation are the same ones assumed when building Z_eff and composition; avoid double counting of impurities in separate inputs.

Resample all inputs to a common time vector that fully covers your modeling window.

Example: if you run 2.0–3.0 s at Δt=0.05 s, create a vector [2.0, 2.05, …, 3.0] and resample EFIT, profiles, and sources to those times. Avoid leaving gaps that force extrapolation.

Standardize upstream. Convert once and document: T_e in keV or eV (not both), densities in m⁻³, positions in meters.

Quick sanity check: central T_e ≫ 10 eV for hot plasmas; if you see values ~10, you likely used eV where keV were expected (or vice versa).

Confirm the IDS version your build expects and the availability of equilibrium, core_profiles, and relevant heating IDS for the intended time window.

Example mapping: electron temperature is typically at core_profiles.profiles_1d[i].te.data with radial coordinate grid.rho_tor_norm.

Check read permissions and the backend (local DB vs remote).

Review IDS unit metadata and your converters. Harmonize all to site-standard units before running transport.

Verify species/energy, geometry, and timing; align with EFIT times.

Example keys: BEAM_ENERGY, BEAM_SPECIES, PINJ(t), geometry angles/offsets. Ensure deposition checks use the same radial coordinate as core profiles.

Check frequency vs resonance for your B-field, launch geometry, and whether refraction is modeled. Re-verify axis/LCFS after any EFIT processing.

Inspect spectrum parameters and accessibility criteria; ensure overlap with modeled time window and consistent profiles.

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 .

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.

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.

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.