Use std::expm1() in conversion from Planck to Rosseland.

[dholladay00]

• Purpose of Pull Request

  • This pull request changes how Planck2Rosseland factor is calculated, using a std::expm1(x) which is accurate even for small (x), refs Enable travis CI #2 (882)

• Pre-Merge Code Review

  • Travis CI checks pass
  • Code coverage does not decrease
  • Valgrind test passes
  • Toss2 checks pass
  • Toss3 checks pass
  • Trinitite checks pass
  • Code reviewed/approved, sufficient DbC checks, testing, documentation

[RyanWollaeger]

Several machines appear to have caught some failed assertions associated with this header:
https://rtt.lanl.gov/cdash/testDetails.php?test=489229&build=856

[RyanWollaeger]

Some tests are failing.

[dholladay00]

Yep, I built Draco and am seeing that Assertion: rosseland >= 0.0, failed in /users/dholladay00/repos/Draco/src/cdi/CDI.hh, line 747.

So, it's definitely something wrong with my change.

[KineticTheory]

The old if/else logic was in place to avoid division by zero when nu is very close to zero. That might need to go back in.

[dholladay00]

More extensive tests failed due to overflow. This is probably occurring when freq is large, thus making expm1(freq) overflow (that is unverified but my guess without further investigation). This was the wisdom baked in to the previous way of multiplying numerator and denominator by exp(-freq). Even in this form, there is a way to use expm1 in that 1 - exp(-freq) = -expm1(-freq).

thus it would be exp_freq * freq * freq_3 / -std::expm1(-freq)

Of course looking at the order of operations could be useful as well to try and group operations such that each result remains as close to O(1) as possible.

Rolling back all of the changes is an option that we know won't hurt anything, but I'd like to see if the new small frequency approximation breaks anything b/c it should be more accurate (I also highly doubt it's the culprit in this case).