sum(charge*dens) must equal 1 in simulations with no electron species

Issue #107 new
Robert Davies created an issue

Changing the dens parameter from 1 for the ion species, in simulations without electrons present, does the following:

  • Raises a warning in ingen (“You are negelcting an ion species” or “excess ion charge fraction”)
  • Changes the instability growth rate when the simulation is run (NB this behaviour appears the same, regardless of the adiabatic_option parameter)

It seems that the electrons are assumed to have dens=1, but this isn’t documented anywhere, as far as I can tell. It’s also not clear to me why this imposition exists, given that there appears to be no contribution from the electrons to the fields (unless ky=0 and adiabatic_option=”field-line-average-term”).

Comments (5)

  1. Stephen Biggs-Fox

    I have not checked the behavior myself. However, assuming the behavior is as Bob has described, then this is a problem because this forces the user to have the density normalization value equal to the electron density and this is not necessarily desirable. For example, if one is running simulations of various surfaces from the same equilibrium, it may be desirable to use the same normalization values for all surfaces, e.g. so that the results from the different runs come out in the same normalized units. This may require the total ion density to be more or less than 1.0, i.e. on surfaces where the total ion density is not equal to the normalization value, which is likely to be most surfaces for equilibria with varying density profiles. However, if one is also using adiabatic electrons, then such an approach is prevented because the adiabatic electron density is assumed to be 1.0. Instead, the adiabatic electron density should be set such that the plasma is quasi-neutral w.r.t. the kinetic ion(s) specified, although this requires the code to make some assumption about the charge of the ion(s) / electron. Maybe the most robust way is to allow users to arbitrarily specify some adiabatic electron parameters such as dens and charge.

  2. David Dickinson

    I think that the input tite is probably important here as this controls the adiabatic contribution. This is probably actually something like n_e T_i / (T_e n_ref) although I’d need to check what’s actually done in the code.

  3. Michael Hardman

    Notes that I received from Colin some years ago suggests that

    tite = (ne/nref)*(T_ref/T_e)*(q_e/q_ref)^2

    as David says.

  4. Log in to comment