Doppler broadening of spectral line shapes for non-Maxwellian distribution functions

[vsnever]

Currently, the line shape models calculate Doppler broadening assuming the Maxwellian distribution of the emitting species. Specifically:

• projection of the bulk velocity on the observation direction is used to calculate the Dopple shift,
• effective temperature is used to calculate the standard deviation of the Gaussian function,
• integrals over the spectral bins are calculated using the error functions (erf).

I suggest adding a special method to the DistributionFunction called projected_fraction(double x, double y, double z, Vector3D direction, double v_lower, double v_upper), which at a spatial point (x, y, z) calculates the fraction of particles having projection of their velocity on a given direction between v_lower and v_upper.

We could also add a simpler method projection(double x, double y, double z, double vx, double vy, double vz), which calculates the 1D projection of the distribution function on the direction (vx, vy, vz) in (m^-4 s) integrating over velocities in perpendicular direction, but then we have to somehow deal with the integration over the spectral bins.

In LineShapeModel, we could simply call the target_species.distribution.projected_fraction() to calculate the Doppler broadening, which for Maxwellian distribution would give us what we already have, but would allow the existing line shape models to work with custom subclasses of DistributionFunction.

This is just an idea, I don't have an implementation yet, but in terms of design it seems right to move the calculations related to the particular implementation of the DistributionFunction to the DistributionFunction itself for some generality.

@jacklovell, @Mateasek, any thoughts?

[Mateasek]

Hi @vsnever ,

I like the idea with the projection. It will be useful for many models which depend on the particle velocity in laboratory frame. The question is how to realise this. I'm not a fan of adding this functionality directly to the DistributionFunction. In my opinion the DistributionFunction should stay as simple and general as possible and what you propose is outside of the idea of a distribution function. It builds on top of it. This is why I think it should go into a separate function.

About the implementation, I'm not sure I understood you correctly. Do you propose to have a function/method, which would return two arrays? One with velocities and second one with densities? If so, I think it goes a bit against the way how most of the models and Raysect's math module work which is not supporting evaluation over arrays. I think that there is a benefit to this, because we don't need to care much about memory usage during observations. This is something I think is worth of sticking with.

What about defining multiple LineShape models with different levels of detail? Levels which would be connected to different approaches to plasma description: Fluid and Kinetic

• What we use now is the fluid approach. We assume a distribution function and use its moments to calculate lineshape. Currently we have only Maxwellian, but there is no problem in adding more kinds of velocity distributions and changing the resulting lineshape appropriately. The advantage of this approach is speed.
• We can add a second approach, which will be the kinetic one. For each spectral bin in a spectrum the models would separately integrate the distribution function in the relevant velocity ranges and calculate the contribution of the emission model to the bin. The velocity ranges are given by the wavelengths of the spectral bin, observation direction and physics included in the emission model.

To add the kinetic approach we would need to add integrators which would integrate a DistributionFunction in a specific way suitable for the given model. There might need to be different integrators for different emission models. For example for some models a magnetic field is not important for the radiation, but for some is. This changes the way you can perform the integration in the velocity space in an efficient way.

This approach could I think help us to cover more physics with the same architecture, although we would have to add specific pieces of code tailored for the specific usage.