Jumps in spectrometer data

[cjperks7]

I think some bug in the spectrometer calculations was introduced since upgrading to tofu1.7.0

If I build my spectrometer and then plot it using diag.plot_diagnostic(key='XRSHRKr', plot_config=conf, elements='o', data='XXX'), where 'XXX' can be really any of the options, I observe discrete jumps versus pixel. Shared is a selection of these plots illustrating the error.

I recall we had a similar issue like this before, but you had fixed it and everything had been working smoothly up till now.

Minimum working code: Running the first 3 steps of the tofu_sparc workflow then plotting as given above.

[Didou09]

I'll have to look into it, I suspect it comes again from numerical inaccuracies in the way the projection of a polygon is handled on a concave reflexive surface (can you confirm this is a concave crystal ?)

[cjperks7]

This is using a von Hamos

[Didou09]

@cjperks7 I think I have identified and corrected what is causing this, Could you add more details on the configuration you're building so I can try to reproduce it to check it's solved ?

[cjperks7]

This is running the first three steps of the tofu_sparc workflow. Here's code you can copy/paste

# Modules
import tofu_sparc as tfs
import os
import tofu as tf

from scipy.interpolate import interp1d
import scipy.constants as cnt
import copy

# Step00, Intializes diagnostic object and beamlines
diag, conf, dhp, key_dhp, dportref, dtube, drooms, dk, dax = tfs.step00_get_beamlines()
#diag, conf, dhp, key_dhp, dportref, dtube, drooms, dk = tfs.step00_get_beamlines()

# Step01, Determines spectrometer geometry
isok, dk, dcam, dcase, dax = tfs.step01_parameter_space(configuration='von hamos',
    dtube=dtube, diag=diag, drooms=drooms, dk=dk, dhp=dhp, lamb0=0.944e-10)

# Step02, 2D configuration of beamlines components
ddet, dap, dfilt, dax = tfs.step02_get_beamline_2d(diag=diag, dhpref=dhp[key_dhp], 
    dportref=dportref, dtube=dtube, dcase=dcase, dk=dk)

plt.close("all")

# Step03, generate beamline diagnostics
diag = tfs.step03_add_diags(diag=diag, ddet=ddet, dap=dap, dfilt=dfilt, 
    conf=conf, dcase=dcase, XRS_ib_max = 1000)

dax = diag.plot_diagnostic(key='XRSHRKr', plot_config=conf, elements='o', data='length')

[Didou09]

Thanks @cjperks7 , can you also specify the configuration of the camera (how many pixels in particular), what's the content of your _def_step02.py and _def_step03.py? Did you change it ? are you on branch devel or on your branch ?

[cjperks7]

I'm on theIssue020_AddTrans branch right now. Everything's pushed if you just want to switch over. I don't see that I've made any changes to the _def_step02.py and _def_step03.py files on this branch compared to devel. I have made it the default that my cameras are (33,1) in (horz, vert) pixel number which I assume has propagated to being the devel default.

[dvezinet]

So the numerical instabilities you were seeing were actually due to 2 different mechanisms. Both have to do with the computation of the reflection of the slit on the concave crystal. Those reflections can be tricky and numerically unstable to compute because the concavity of the crystal brings around a singular point (near the center of curvature), where a small numerical error can turn into a large discrepancy on the reflection.

tofu has several safeguards against that, but it wasn't enough for the particular pixels that you identified.

Bug 1: rafter the reflection is computed, tofu interpolate the reflected polygon on many points to try and average out singular points. The interpolation process was missing some corner points, effectively affecting the area of the projection and the etendue.

Bug 2: during the computation of the reflection, the root of an equation has to be calculated, that root-finding process wasn't robust enough for some particular pixels. As a result the reflected polygon was much larger than it should, resulting in a significantly larger etendue. I made that more robust.

After correction of bug 1:

After correction of both bugs:

The residual small variations are below 0.5 % and are tolerable.

This double bug fix is hosted on PR #751 and will be publicly available in the next official release of tofu (1.7.1)