feat: Add JSON detector element #3851
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
Component - Examples
| py::class_<Acts::JsonDetectorElement, Acts::DetectorElementBase, | ||
| std::shared_ptr<Acts::JsonDetectorElement>>( | ||
| mex, "JsonDetectorElement") | ||
| .def("surface", [](Acts::JsonDetectorElement& self) { |
There was a problem hiding this comment.
Does this need to return the shared pointer? Otherwise I'd stick to the C++ return type.
Is the base class exposed to Python as well? I wonder if it would be enough to expose this method on the base class.
There was a problem hiding this comment.
I think a shared ptr is required to avoid livetime issues, right?
And you're right, I forgot to pull in the binding of the base class. I think its not strictly necessary, but I think it could be useful to not loose the type information here...
| std::shared_ptr<Surface> m_surface; | ||
| Transform3 m_transform{}; | ||
| double m_thickness{}; |
There was a problem hiding this comment.
Conventionally we put private members at the bottom of classes.
| return self.surface().getSharedPtr(); | ||
| }); | ||
|
|
||
| mex.def("readDetectorElementsFromJson", |
There was a problem hiding this comment.
We'll probably want to refactor this to align it with the C++ namespace instead of a function at the module level.
I also don't really understand why these functions are in the examples and not in the plugin itself.
There was a problem hiding this comment.
Yeah I agree that conceptionally it should be in the plugin since it is not a IWriter type object
|
Add a json detector element, which is explicitly constructed from a
nlohmann::jsonobject in order to ensure consistency.--- END COMMIT MESSAGE ---
Any further description goes here, @-mentions are ok here!