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

Add nuclear zone data #1269

Merged
merged 15 commits into from
Jun 13, 2024
Merged

Conversation

whokion
Copy link
Contributor

@whokion whokion commented Jun 12, 2024

Extend neutron inelastic data for the Bertini cascade nuclei model

This MR adds data for nuclear zone properties to NeutronInelasticData and associated updates:

  • Import nucleon loss energies in IsotopeView
  • Add options for the Bertini cascade model
  • Add nuclear zone data for the Bertini cascade model
  • Extend the NeutronInelastic test and adjust other tests due to updated in Isotope

@whokion whokion added enhancement New feature or request physics Particles, processes, and stepping algorithms labels Jun 12, 2024
@whokion whokion requested review from sethrj and amandalund June 12, 2024 13:46
@whokion
Copy link
Contributor Author

whokion commented Jun 12, 2024

@sethrj Is the fail from windows real?

real_type integral,
real_type ws_shift) const
{
constexpr int max_trials = 1e+3;
Copy link
Member

Choose a reason for hiding this comment

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

@whokion This is the source of the windows error:

D:\a\celeritas\celeritas\src\celeritas\neutron\model\detail/NuclearZoneBuilder.hh(368): error C2220: the following warning is treated as an error
2024-06-12T13:55:56.9194698Z D:\a\celeritas\celeritas\src\celeritas\neutron\model\detail/NuclearZoneBuilder.hh(368): warning C4244: 'initializing': conversion from 'double' to 'const int', possible loss of data

Write it as 1000. (In theory you could specify a real number that's out of range of int and then loses accuracy.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks!

Copy link
Member

@sethrj sethrj left a comment

Choose a reason for hiding this comment

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

Everything but the NuclearZoneBuilder looks essentially perfect! great design and implementation.

I think the NZB needs to split out a templated numerical integrator class that has some additional testing on it.

src/celeritas/ext/GeantImporter.cc Outdated Show resolved Hide resolved
src/celeritas/io/ImportElement.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/CascadeOptionsIO.json.cc Outdated Show resolved Hide resolved
src/celeritas/neutron/model/NeutronInelasticModel.cc Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
// Average value of \f$ r^{2} V(r) dr \f$ at boundaries
real_type integral = half() * delta_r
* (rmin * (rmin + ws_shift) / (1 + std::exp(rmin))
+ rmax * (rmax + ws_shift) / (1 + std::exp(rmax)));
Copy link
Member

Choose a reason for hiding this comment

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

This (and the gaussian case below) are just initial guesses for the integral... this should be trivial to incorporate into the adaptive quadrature solver itself, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are absolutely right. This was a lazy man's implementation, but definitely can be integrated into PotentialIntegrator that you suggested early.

src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
@whokion
Copy link
Contributor Author

whokion commented Jun 13, 2024

@sethrj Thanks a lot for your review comments and suggestions, which I hope that I addressed most of them except the request for PotentialIntegrator (which may be a separate MR). Is the CI failure something that I should worry about or a just glitch?

@sethrj
Copy link
Member

sethrj commented Jun 13, 2024

@whokion Just a glitch I think: rerunning now. I'll see if I can make a small PR with a generic numerical integrator and test...

Copy link
Member

@sethrj sethrj left a comment

Choose a reason for hiding this comment

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

One or two small suggestions; I'll let @amandalund review and then I can follow on after the merge with the numerical integrator.

Comment on lines +173 to +174
size_type num_of_zones = components.size();
std::vector<real_type> integral(num_of_zones);
Copy link
Member

Choose a reason for hiding this comment

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

Instead of doing the "number of zones" calculation in a separate function and expecting the size to match in the if statements below, I think it'd be better to resize the vector inside this function. Inside the if statements, resize the vector to 1, y.size(), alpha.size(), etc., and then loop over integral.size() rather than a separate num_of_zones values.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure about this. The number of zones is used for other properties (i.e., volumes, etc), so it may be still more readable keeping it as a common size across the whole code, which is called just once for a specific Isotope.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, i didn't see this wasn't addressed. Are you expecting NuclearZoneBuilder::num_nuclear_zones to be called outside of that helper class? The number of zones is implicitly available through the components size, so the separate assumptions between num_nuclear_zones and calc_zone_component is a dangerous redundancy.

src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
Copy link
Contributor

@amandalund amandalund left a comment

Choose a reason for hiding this comment

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

This looks great @whokion!

src/celeritas/neutron/data/NeutronInelasticData.hh Outdated Show resolved Hide resolved
* Device data for nuclear zone properties
*/
template<Ownership W, MemSpace M>
struct NuclearZoneData
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the data could be simplified slightly by removing this struct and instead storing the components and zones directly in NeutronInelasticData.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I originally did what you are suggesting, but I may want to reorganize data structure by grouping data separately needed for the process (i.e., macro_xs) and for the interactor (nucleon_xs, zone_data and other data which will be added later). Although NuclearZoneData is too specific now and can be renamed by the more generic name as more data are added, I would keep the structure as it is now and reorganize them later as more codes and data are added.

src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
src/celeritas/neutron/model/detail/NuclearZoneBuilder.hh Outdated Show resolved Hide resolved
Copy link
Member

@sethrj sethrj left a comment

Choose a reason for hiding this comment

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

Nice, thanks!

@sethrj sethrj enabled auto-merge (squash) June 13, 2024 18:24
@sethrj sethrj merged commit 4fe3cf4 into celeritas-project:develop Jun 13, 2024
29 checks passed
@whokion whokion deleted the nuclei-model-data branch July 1, 2024 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request physics Particles, processes, and stepping algorithms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants