LIMS-2054: Dont exclude peaks from MCA spectra

[ndg63276]

JIRA ticket: LIMS-2054

Summary:

The SynchWeb view of MCA spectra uses logic to determine whether to label fitted peaks by comparing the energy of emission lines to a cutoff applied to exclude the Compton scattering region of the spectrum (currently applied as a blanket beam energy - 1 keV cutoff).

This logic is redundant as similar logic is applied at the analysis step and peaks would not be included in the results file if they fall into this cutoff region. The code should therefore be removed to avoid needing to change logic in two locations if the application of the cutoff needs to be modified.

Changes:

• Don't exclude peaks within 1keV of the beam energy

To test:

• Go to /dc/visit/lb42888-63/ty/mca/id/18384, check there are 2 labelled Zn peaks

NB
There is also code to plot the graph within 1100eV as a different colour, just above this change. That is to be addressed in ticket LIMS-2055

[gfrn]

The label seems to sit far above the peak, compared to other peaks

Is this intentional?

[ndg63276]

I think that is just what the analysis results file says. @pblowey might be able to tell us why that is.

[pblowey]

The label seems to sit far above the peak, compared to other peaks

Is this intentional?

What data collection was this from?

[ndg63276]

https://ispyb.diamond.ac.uk/dc/visit/lb42888-63/ty/mca/id/18384

[pblowey]

The file that SynchWeb reads has peak counts as peak areas, however, Synchweb must be applying some logic to estimate a peak height for showing the labels. Do you know where that logic exists in the SynchWeb code?

[ndg63276]

I think Synchweb assumes they are heights, not areas, so this quite wide Zn peak gets a label a bit too high. Some logic is at https://github.com/DiamondLightSource/SynchWeb/blob/master/api/src/Page/DC.php#L1255 (basically it passing the contents of results.dat) and then more logic at https://github.com/DiamondLightSource/SynchWeb/blob/master/client/src/js/modules/dc/views/mcaplot.js#L29

[pblowey]

I'm not 100% sure that I'm following the code correctly but what I think it is doing is this:

1. Sets the y-axis of the spectrum based on the max number of counts in the non-compton region.
2. Sets the label y position as a fractional coordinate of the y-axis (+ an offset) by comparing the number of counts for the peak in the results file, vs the largest peak in the results file (even though these are really peak areas and not peak heights).

I think this probably works well enough to make the labels readable and obvious enough as to which peak they refer to but we may see some variance in the heights of the label above the peak with different peak widths.

[ndg63276]

Yeah that's my reading too. So I think the slight variance in label heights is not a problem, or not enough of a problem to affect this PR at least!

[gfrn]

That makes sense! Sorry, I was away the last two days