NLTE Solver population checks

[jpollin98]

I have been thinking about the errors in the multid nebular runs. I think a check at the end of the NLTE solver would be a good idea. We would need to check for two cases:

1. when the population may become sufficiently small to cause problems with floating point numbers. (On this point, I also think min pop should be changed to something larger, 1e-35 to ensure we are not close to the float limit)

2. The case when we have a population inversion. The division by the groundpop when we have a successful solution with a population inversion can cause significant problems at the point the partition function is cast from a double to a float. There is no physical justification for not allowing a population inversion thus simply setting the population to LTE might not be the best approach. Thus, I suggest some tolerance on what we would accept.

As such, I have attempted to introduce two checks on the solved populations. I believe the changes in the outputs are from numerical round-offs as the spec.out files are the same. Although I'd appreciate some sanity checking of the implementation for the 2nd case. Do you think there's a better way to implement this safety mechanism on the NLTE solver?

[lukeshingles]

Does running this code solve the problem with your multiD runs? Do you know what is going wrong in the NLTE solver that requires the populations to be clamped afterwards?

I would prefer to move in the direction of eliminating arbitrary parameters like MINPOP that must be manually adjusted. Ideally, the code will automatically set it to some sensible value, if it is really needed at all. I know one of the main uses is to prevent nne from going to zero, but it should not be a problem for an ion or level population to be zero.