Skip to content

Conversation

@itay-space
Copy link

@itay-space itay-space commented Aug 27, 2025

Description

This PR is the first step in breaking down the point detector tally project into smaller, reviewable pieces, following the large PR #3109
and the paper Development and benchmarking of a point detector in OpenMC.

As suggested during the earlier discussion (thanks @GuySten, @gridley, @shimwell !), the natural starting point is to add the ability to correctly calculate PDFs on the C++ side.

Accordingly, this PR introduces the get_pdf implementations for the distribution classes. This is essentially a clean cut from the original large PR, with the goal of keeping the scope focused and review manageable.

We plan to follow up with tests and additional pieces of the point detector work in subsequent PRs.

Checklist

  • I have performed a self-review of my own code
  • I have run clang-format (version 15) on any C++ source files (if applicable)
  • I have followed the style guidelines for Python source files (if applicable)
  • I have made corresponding changes to the documentation (if applicable)
  • I have added tests that prove my fix is effective or that my feature works (if applicable)

@itay-space itay-space changed the title Implement get_pdf functionality [Point Detector] Add distribution get_pdf functionality Aug 27, 2025
Copy link
Contributor

@GuySten GuySten left a comment

Choose a reason for hiding this comment

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

Nice work @itay-space!

My review focus more on the code structure side of things.
I did not check the maths.

itay-space and others added 6 commits August 28, 2025 08:32
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
Co-authored-by: GuySten <62616591+GuySten@users.noreply.github.com>
@itay-space
Copy link
Author

@GuySten , Thanks for the suggestion! These classes already rely on two independent 1D distributions (polar and azimuthal), and the evaluate methods are implemented at that level. The sphere distributions just combine those underlying 1D PDFs, so the functionality is already covered.

@GuySten
Copy link
Contributor

GuySten commented Sep 25, 2025

@itay-space, the conversion is not trivial because of the reference direction, so I think that adding this functionality is worth while.
If you do not object I can add the relevant functionality myself.

@itay-space
Copy link
Author

@GuySten I’m not sure why this would be different from the other cases (I can’t see it right now), but sure, go ahead and add the functionality. I have no objections. Thanks!

@GuySten
Copy link
Contributor

GuySten commented Sep 28, 2025

I am waiting for #3582 to be merged to add the functionality I talked about.
Without that PR it is unclear what is the correct mapping between a point on the unit sphere and the mu, phi angles to calculate the pdf for.

@GuySten
Copy link
Contributor

GuySten commented Oct 14, 2025

@paulromano, I am reminding you to look at this PR when you have some time.

@shimwell
Copy link
Member

shimwell commented Nov 3, 2025

I am waiting for #3582 to be merged to add the functionality I talked about. Without that PR it is unclear what is the correct mapping between a point on the unit sphere and the mu, phi angles to calculate the pdf for.

Thanks for breaking out this small PR and great to see it is now merged

@GuySten
Copy link
Contributor

GuySten commented Nov 3, 2025

I've added the functionality I wanted.

@paulromano, could you take some time to review this PR? You asked to review this RP before we are merging it, and I want to merge this PR and continue to the next parts of the point detector work.

@paulromano
Copy link
Contributor

@GuySten Yes, I will try to get to it this week

Copy link
Contributor

@paulromano paulromano left a comment

Choose a reason for hiding this comment

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

@itay-space @GuySten Just wanted to let you know I am starting to go through this PR. It's not as simple as I was hoping as there is quite a bit of effectively duplicated code in the AngleEnergy classes. I'll see what I can do with it but let me know if either of you have ideas.

@GuySten
Copy link
Contributor

GuySten commented Dec 3, 2025

I simplified this PR significantly.
@paulromano, are these changes enough?

@GuySten GuySten requested a review from paulromano December 8, 2025 13:29
@GuySten
Copy link
Contributor

GuySten commented Jan 6, 2026

@paulromano, could you take some time to look at this PR?
It is in much better shape now.

@paulromano
Copy link
Contributor

Thanks for the ping @GuySten. I'm working through PR reviews this week and will try to get to this one.

Comment on lines 108 to 122
vector<double> energies_cut(energies.begin(), energies.begin() + i + 1);
vector<double> factors_cut(factors.begin(), factors.begin() + i + 1);

vector<double> mu_vector_rev;
std::transform(energies_cut.begin(), energies_cut.end(),
std::back_inserter(mu_vector_rev),
[E_in](double Ei) { return 1 - 2 * Ei / E_in; });
vector<double> mu_vector(mu_vector_rev.rbegin(), mu_vector_rev.rend());

auto f = xt::adapt(factors_cut, {
factors_cut.size(),
});
auto weights = xt::diff(f);
weights /= xt::sum(weights);
vector<double> w(weights.begin(), weights.end());
Copy link
Contributor

Choose a reason for hiding this comment

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

The use of std::vector here results in dynamic memory allocation, which is undesirable within any code that appears within the transport loop since it is threaded. @itay-space @GuySten can you guys see if you can restructure this to avoid the use of new vector objects?

@GuySten
Copy link
Contributor

GuySten commented Jan 16, 2026

@paulromano, I've managed to reduce the number of vector allocations to 2.
Currently, I have no idea how to reduce it further.

@GuySten
Copy link
Contributor

GuySten commented Jan 16, 2026

@paulromano, I have some ideas of how to reduce the memory allocations further
but it will be easier to test them once we have reached the point where we have point detector regression tests.

Are you okay with merging it as is and open an issue to improve memory allocations in the future?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants