Negative k-packet probabilities in scatter

[kslong]

In the example, for #854 the first errors one sees are of the type

scatter: kpkt probability (-2.8064e-03) < 0 for phot_top 63, zeroing
scatter: photon edge frequency: 1.5593e+16, comoving (observer) frequency 1.5550e+16 2.3427e+16

where I have modified the diagnostic message so that the observer frame frequency is also printed out. These errors arise in scatter (which is only called trans_phot_single). The problem occurs because although the original scatter was triggered by a photon which was thought to be above an absorption edge ends up below the edge after it is converted to the local frame.

It seems likely that this error occurs because we make some kind of approximation to locate the place where the scatter occurs in trans_phot_single (probably in calculate_ds) and when we calculate the actual frequency at that position it is now what was expected. But this should be cleaned up if possible, since it is not clear that this is not a bug.

[jhmatthews]

From memory, I think there is not much one can do about this if we want to keep the current code philosophy. By which I mean, if a photon's CMF frequency crosses an edge, this error can always happen, because we use the average frequency to calculate the opacity (and the ds), but then we use the frequency at the interaction point in the interaction process (e.g. macro-atom/kpkt decision making). This is discussed a little in #436. One alternative choice that would avoid this error would be to make the assumption that the photon frequency is constant along ds, but whether either choice is better is debatable.

Note also that this shouldn't ever produce negative frequencies, just negative probabilities, which are zeroed, and the heating impact of these packets should be extremely small (since they are basically right on the edge).

[kslong]

Yes, I agree as to the underlying reason this problem develops. I was just wondering if there was something we could do to stop this problem from percolating to this point in the code.

Also, If we really believe this is expected, I would favor eliminating this as an error, or increasing the limit to say -5e-3, as conpared to -1e-3, so it did not appear very often. That is what I will do unless there are objections.

[jhmatthews]

I think basically there's nothing we can do if we preserve the current philosophy of using the CMF frequency at interaction point.

I think the 5e-3 limit is fine in terms of suppressing errors, the 1e-3 was chosen rather arbitrarily.

[kslong]

I've experimented a bit with Ed's example. To get the numbers of error numbers be low for Ed's example, one needs to choose 1e-2