Skip to content
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

Interface to modify RNO-G detector description #616

Open
fschlueter opened this issue Feb 5, 2024 · 4 comments
Open

Interface to modify RNO-G detector description #616

fschlueter opened this issue Feb 5, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@fschlueter
Copy link
Collaborator

This was mentioned in one of the RNO-G calls. Several analyses (I guess mostly calibration related) will profit / make it necessary to change the detector description "on-the-fly" to validate the effect on the changed description. I can think of a few approaches how to realise that. This issue is here to collect ideas and as a discussion platform.

I have two ideas:

  • Implement a setter for the total_response of a channel. Keep in mind this key is buffered internally. Also this key is not exported to file (because one can/should not serialise custom classes and the data are already exported).
  • Implement a setter for the signal chain list which specifies the individual response which constitute the total_reponse (those would than need to be defined in the database)
@fschlueter fschlueter added the enhancement New feature or request label Feb 5, 2024
@fschlueter
Copy link
Collaborator Author

A other possibility is to modify the json file. If that is the case we should add some utility scripts to NuRadio for that.

@tongnpdl
Copy link

tongnpdl commented Feb 9, 2024

I am not sure how the class is structured at the moment but, as a user, I would love to have something that can take a list of electronic elements or response class object and return a total_response object. Imagine the presentation about how should we calculate total response from currently available measurements. If we have a tool to test each possibility, it would be greatly helpful especially when we are trying to test our hypothesis during calibration whether we are missing something or not .

@cg-laser
Copy link
Collaborator

cg-laser commented Feb 9, 2024

what about a new class "ModifiedDetector" that inherits from the RNO-G detector but allows the user to overwrite any parameters/response functions? This detector class could also implement other useful functions such as systematically changing response functions to study systematic uncertianties, etc.
It might be good to separate this functionality from the RNO-G detector class to let users unintentionally mess up the reference detector description.

@cg-laser
Copy link
Collaborator

cg-laser commented Feb 9, 2024

and as always, I would take a pragmatic approach and implement only the functionality that someone needs for their analysis right now. If more functionality is needed at a later stage, this can be added later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants