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

refactor: Explicit and type safe navigation delegates #2214

Closed
wants to merge 12 commits into from

Conversation

andiwand
Copy link
Contributor

In this PR I try to make the navigation delegates more explicit and type safe by splitting the interface of volume finders and surface candidate lookups. That way the navigation state is just a view to the delegates and cannot be modified which also lowers bug risk IMO.

  • rename DetectorVolumeUpdator to DetectorVolumeFinder
  • rename SurfaceCandidatesUpdator to SurfaceCandidatesDelegate
  • add uniform utility functions to construct delegates
  • reorganize file structure of new navigation and new geometry

@andiwand andiwand added Component - Core Affects the Core module 🚧 WIP Work-in-progress labels Jun 15, 2023
@andiwand andiwand added this to the next milestone Jun 15, 2023
@github-actions github-actions bot added the Component - Examples Affects the Examples module label Jun 15, 2023
@andiwand
Copy link
Contributor Author

TODO

  • run unit tests
  • add doc
  • add unit tests

@github-actions github-actions bot added the Component - Documentation Affects the documentation label Jun 16, 2023
Copy link
Member

@paulgessinger paulgessinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the naming is clearer this way and it makes sense to me to separate these two.

/// @param nState [in,out] is the navigation state to be updated
///
/// @todo for surfaces skip the non-reached ones, while keep for portals
inline static void updateCandidates(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these need to be inline?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not - I just saw that removing that would lead to linker errors in some cases but maybe that was also in combination with templates. the question is also if these kind of methods really have to have their impl in the header

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the question is also if these kind of methods really have to have their impl in the header

That's what I was trying to ask.

const std::vector<std::shared_ptr<Acts::Surface>>& lSurfaces,
const std::vector<size_t>& assignToAll,
std::vector<std::shared_ptr<Acts::Surface>> lSurfaces,
std::vector<size_t> assignToAll,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just need to make sure we don't copy these needlessly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed - I just think by value gives you more flexibility when you are sinking the param anyways

// Return the transform, the volume bounds, and some default portal
// generators
return {Transform3(m_cfg.transform * eTransform), std::move(volumeBounds),
defaultPortalGenerator()};
makePortalGenerator<const DefaultPortalGenerator>()};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just force const?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you mean by force? I wondered if I should add it to the helper directly. but at the same time I wondered why we require const because the method being called is const anyways 🤔

@github-actions github-actions bot added the Component - Plugins Affects one or more Plugins label Jun 20, 2023
@asalzburger
Copy link
Contributor

@andiwand how do we go about this?

@andiwand
Copy link
Contributor Author

@andiwand how do we go about this?

I can update this again - in principle it is ready to review just the CI is failing

There is one detail about the grids I was unsure about. I had to touch it without really knowing what is going on behind the scenes

@andiwand andiwand closed this Jul 17, 2023
@andiwand andiwand reopened this Jul 17, 2023
kodiakhq bot pushed a commit that referenced this pull request Jul 21, 2023
- consistent pass by value
- reformat documentation

pull changes out of #2214
paulgessinger pushed a commit to paulgessinger/acts that referenced this pull request Jul 24, 2023
- consistent pass by value
- reformat documentation

pull changes out of acts-project#2214
@github-actions github-actions bot added the Stale label Aug 16, 2023
@paulgessinger paulgessinger removed the 🚧 WIP Work-in-progress label Sep 29, 2023
@andiwand andiwand closed this Sep 29, 2023
@andiwand
Copy link
Contributor Author

this will be followed up in other, smaller PRs

@paulgessinger paulgessinger modified the milestones: next, v30.1.0 Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component - Core Affects the Core module Component - Documentation Affects the documentation Component - Examples Affects the Examples module Component - Plugins Affects one or more Plugins Stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants