Skip to content

Conversation

@yardasol
Copy link
Contributor

Description

This PR refactors the openmc_run_random_ray() function as well as the automatic setup machinery to adhere to D.R.Y.

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)

Copy link
Contributor

@jtramm jtramm left a comment

Choose a reason for hiding this comment

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

Looks good -- thanks for cleaning these areas up! Just a minor comment on naming, but then should be good to go.

Comment on lines 407 to 430
void RandomRaySimulation::random_ray_adjoint()
{
if (!adjoint_needed_) {
return;
}

// Configure the domain for adjoint simulation
FlatSourceDomain::adjoint_ = true;

// Reset k-eff
domain_->k_eff_ = 1.0;

// Initialize adjoint fixed sources, if present
prepare_fixed_sources_adjoint();

// Transpose scattering matrix
domain_->transpose_scattering_matrix();

// Swap nu_sigma_f and chi
domain_->nu_sigma_f_.swap(domain_->chi_);

// Run a single simulation
run_single_simulation();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be nice to be able to deduce from the top level calls that the adjoint simulation still fundamentally the same as the forward one, just with a few preparations made. I think the naming scheme of RandomRaySimulation::run_single_simulation() and void RandomRaySimulation::random_ray_adjoint() is a little opaque, as without digging into those functions it suggests there is a very different control flow happening for forward vs. adjoint. I might propose changing RandomRaySimulation::random_ray_adjoint() to something like RandomRaySimulation::prepare_adjoint_simulation, and then pull out the run_single_simulation();call that is inside of it into the higher level caller space, such that the control flow is more clear. I also wonder if run_single_simulation() might be changed to run_simulation()? Or, even better yet, perhaps it would be better to fold this logic into the RandomRay.simulate() function, so as to avoid having both simulate() and run_simulation() functions, which is a little confusing when looking through the API why we have both of these.

@yardasol
Copy link
Contributor Author

Thanks for the feedback @jtramm. I've implemented your suggestions, let me know what you think.

@yardasol yardasol requested a review from jtramm January 22, 2026 18:00
Copy link
Contributor

@jtramm jtramm left a comment

Choose a reason for hiding this comment

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

Thanks @yardasol - the changes look fantastic!

@jtramm jtramm merged commit 049a852 into openmc-dev:develop Jan 22, 2026
17 checks passed
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.

2 participants