The mtable results are qualitatively different between version 2.1h and 2.1j and later for the depths of lines when the value of vturbi is small. These differences are entirely due to the challenge of modeling absorption in a binned spectrum. Since before v2.1h the ionization and thermal balance has changed very little.

Taking O VIII L alpha as an example. A cloud with colum 10, log()=1.8 and a =2 power law ionizing spectrum has a line center optical depth of 1.6e3 for this line, and a temperature 10 K. So the thermal Doppler velocity is 11 km/s, or 2.4e-3 eV in energy units. The line wavelength is 18.9689 A, or 653.62 eV. The nearest xstar bin boundaries are at 653.1 and 654.0 eV, which are both many Doppler widths away. These versions of xstar both use a logarithmic energy grid evenly spaced between 0.1 and 20000 eV, with E/DeltaE=722, for a total of 9999 energy bins (there are some extras tacked on at high energy). The version in development has 10 times as many, but still will not resolve the lines such as O VIII L alpha.

How to put an unresolved line on a fixed grid? There are 3 obvious ways, 2 of them dumb: Version 2.1h and before simply calculated exp(-tau_line) at the nearest energy grid point, so O VIII L alpha was black in one bin. This version also did not take into account the damping wings accurately. Version 2.1j and later use an accurate Voigt profile, with damping wings, and evaluate the profile function at the grind point. So the bin at 654 eV in my example, being 12 Doppler widths away, has an optical depth of about 0.4. And there was an error in the implementation of this in versions 2.1j and 2.1k when turbulent broadening is included, but that is now fixed.

The third way would be give the bin a depth which would give the correct equivalent width for this unresolved line, since neither of the previous two will do that. This is work, since it requires implementing a curve of growth calculator which can handle damping, and arbitrary values for hte line wavelength relative to the bin boundaries, and can smoothly go over to something like what is in 2.1k when the line is resolved. It is planned to put this in the next version of xstar.