<div dir="ltr">Hi all, as part of the Jan 2020 codecamp, we put in some changes to NXmx to support beam spectra.  The relevant text is here: <a href="https://github.com/nexusformat/definitions/blob/master/applications/NXmx.nxdl.xml#L583-L607">https://github.com/nexusformat/definitions/blob/master/applications/NXmx.nxdl.xml#L583-L607</a>, but here's a quick summary<div><br></div><div>The use cases are</div><div><ol><li>1 wavelength</li><li>1 spectrum (weights in incident_wavelength_weight)</li><li>1 wavelength per image (incident_wavelength_weight is not set)</li><li>1 spectrum per image (incident_wavelength and incident_wavelength_weight are 2D arrays)</li></ol><div>There is however a use case we didn't cover.  SwissFEL currently provides a spectrum per image (use case 4) AND a per-shot 'calibrated' wavelength.  I had assumed this wavelength was a simple weighted average, but it actually is complicated smoothing and fitting procedure.  So, how to represent both 1 spectra per image and a calculated wavelength in NeXus?</div></div><div><br></div><div>I have 3 ideas right now:</div><div><ol><li>Add a new optional field to NXmx: incident_wavelength_calculated.</li><li>Add an entirely separate beam group to the NeXus file for the spectra.  So under entry/sample, there would be beam and  beam_spectra.  The first would be use case 3 using the calculated wavelengths and the second would be use case 4.</li><li>Use incident_wavelength as use case 3 with the calculated wavelengths, and add incident_wavelength_spectra as a variant of incident_wavelength.  This wouldn't modify NXmx, but I could modify our software to look for this variant.  This seems like it defeats 'standards' though.</li></ol><div>In idea 2, how would downstream processing software know which to use if both are marked with NX_class = NXBeam?  Also, could I specify this in NXmx somehow that won't confuse the validator?</div></div><div><br></div><div>Thoughts?</div><div>Thanks!</div><div>-Aaron</div><div><br></div></div>