Updates for finer incident energy bins in SRM

[mithunnps]

On exploring finer bin SRMs, it is noticed that having finer incident energy bins makes a difference to the predicted count spectrum in STIX for the same model, especially at low energies. Including new transmission files with finer binning to generate SRM files with finer incident energy bins of 10 eV in the 2-20 keV energy range and 100 eV in the 20-160 keV energy range and updates in the code to read from the new files. The transmission files are generated from stixpy by modifying the energy values in stixpy.calibration.transmission.generate_transmission_tables(). When this is merged, maybe this small change in stixpy may also be merged for consistency.

There are small differences in temperature (slight increase) and emission measure obtained with the new finer bin SRM compared to the previous versions.

[samaloney]

I think need to check if this is consistent with the default DRM energy binning as I think they need to match? Not clear how it would work if the transmission and DRM are not evaluated on the same energy grid?

[FredSchuller]

Hi @samaloney
it's not 100% clear to me what needs to be checked and how to proceed... we have another colleague from India visiting us now, therefore it would be good if this issue could be solved relatively soon ;-)

[mithunnps]

I think need to check if this is consistent with the default DRM energy binning as I think they need to match? Not clear how it would work if the transmission and DRM are not evaluated on the same energy grid?

Transmission files are reevaluated with the the finer energy bins using the stixpy routines mentioned above. New transmission files are also included in the commit. Perhaps the changes in stixpy to generate the transmission files also need to be committed, please see.

[samaloney]

Ok so I just had a look at the current version of the software and the drm bin edges go from 3.927 to 149.927 in steps of 0.146 (all in keV) but from the the name stix_transmission_highres_20240711_010-100eVBin.csv of the new file would suggest it goes from 10-100 with and but the contents seem to go from 2 - 159 with a step of 0.148.

I don't think either of these match the DRM but maybe I'm missing something?

Ok I see now I think what does the _10_ in the file name indicate?
Also any performance issues in terms of fitting with such large DRM?

Looks like this would work in the python code

np.hstack((np.arange(2, 20, 0.01), np.arange(20, 160, 0.1)))
array([  2.  ,   2.01,   2.02, ..., 159.7 , 159.8 , 159.9 ])