-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add first_modno input argument for components.JUNGFRAU #379
Add first_modno input argument for components.JUNGFRAU #379
Conversation
1cde7a1
to
ebd8d2d
Compare
I am not sure what the reason for the codecov/project failed check |
Ugh 🙄 . Do you know if this is only an issue with JF500K detectors? We could go back to your idea of applying it to all single module detectors. Or we could let the user pass in something like Or if the user specifies |
It is with JF500K detectors for now. But there is no guarantee that this will be the case always. Also, adding more info to this. The below screenshot shows that in offline calibration we are dependent on that DA/Receiver relation.
I always think about this solution. The only thing I couldn't solve is: For example, we have JF4M -> JNGFR02 & JNGFR03 & JNGFR04 & JNGFR05. The user passes n_modules = 4 and we see only JNGFR02 how would we know that this is the 1st detector? Passing |
Yeah, if there are missing modules, you'd have to specify where the numbers start from. I'd probably do it with passing an integer rather than a string, because this 'JNGFR02' part isn't something that EXtra-data otherwise asks you to look at. |
Yes, that makes sense 👍🏽 |
d796fae
to
6b54ddf
Compare
I have replaced the changes in the MR by adding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks like a good direction, my comments are all on the details.
Sorry it's taken so long to look at it again.
Oh, and I meant to say, don't worry too much about codecov - it often seems to report that PRs cause a small drop in coverage. I imagine there's some fiddly issue with coverage collection, but so far I haven't bothered to figure it out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kakhahmed !
This MR fixes issues with:
JNGFR03
.modno_to_source
andsource_to_modno
with the correctmodno
corresponding to the module array index.This fix will used by https://git.xfel.eu/calibration/pycalibration/-/merge_requests/775 [Not yet tested with all reference runs.] It was tested with SPB_IRDA_JF4M and FXE_XAD_JF500K
And it is an alternative for European-XFEL/EXtra-geom#206
This issue was discovered after creating
components.JUNGFRAU
object forFXE_XAD_JF500K
to form a DataArray fordata.adc
, then plotting it usingplot_data_fast
. The problem is that the module coordinates for this DataArray are of a value3
. As the data channel has JNGFR03.Both
modno_to_source
andsource_to_modno
are modified when st_modno is set to > 0 value.This helps in fixing the cases mentioned below in the comments with JF detectors with one module and receiver with integer > 1
Tested were added for
st_modno
andmock_fxe_jungfrau_run
was added for /gpfs/exfel/exp/FXE/202101/p002478/raw/r0052