Fix specific energy spectrum when PDA and MRW are used, as well as dust sublimation capping

[astrofrog]

The optional frequency-resolved specific energy spectrum (a per-cell, per-dust histogram of absorbed energy binned by photon frequency) is filled during normal photon propagation, but three code paths modify the cell energy without going through propagation and left the spectrum stale or wiped it, breaking the invariant that the spectrum summed over frequency bins equals the scalar specific energy:

• MRW: diffusion-step energy deposits only updated the scalar, so cells heated mainly via the Modified Random Walk had a near-empty spectrum. The energy is now also deposited in the spectrum, with the frequency sampled from the local emissivity (in the diffusion regime where MRW is valid, the radiation field is Planckian, so the absorbed energy is distributed as kappa_nu * B_nu).
• PDA: the Partial Diffusion Approximation overwrites the scalar in poorly sampled cells but left the spectrum untouched. The spectrum is now rescaled by the ratio of the new to old specific energy, preserving its shape.
• Dust sublimation: capping the specific energy at the sublimation value reset the spectrum to the minimum specific energy, destroying the spectral information. It is now rescaled by the cap ratio instead.

Includes a test suite that asserts the sum-over-bins invariant per cell (plain, PDA, and AMR runs, plus custom frequency grids) and that enabling the feature does not change the scalar specific energy.

Models that do not enable the frequency-resolved spectrum are unaffected (the scalar code paths are unchanged, and the full bit-level suite passes against the existing reference files).

[astrofrog]

@dnarayanan - just FYI this fixes some issues related to the frequency-dependent specific energy, though this might be in modes you don't depend on.

[dnarayanan]

thanks! i hadn't tested those modes so appreciate the fix!

[astrofrog]

@dnarayanan while I think of it, I've been meaning to ask is there a reason you didn't have it so that users define bins rather than the 'centres' of the bins? Having played around with this I feel that having the definition be based on bibs might be more explicit, so that users don't think that the values are being computed at an exact frequency. For instance if a user specifies two frequencies, the results will be huge averages rather than just the value at two frequencies.

Anyway I'm curious if switching things would be a no go for you, or if there's a reason you decided against this?

One option would be to have the Python method to set the bins take both bin_edges and bin_centers as kwarg only arguments so that users have to explicitly use one or the other, and handle it via bins internally.

[dnarayanan]

this is a really good idea! i have to admit i just didn't think about it because i was doing this for my own purposes and wasn't really thinking through a general use-case. i think this would be a useful addition.

i could try to implement this though i have to admit it i may not have time to look until mid-fall (i'm about to go into a multi-month proposal writing frenzy for a series of grants...)