-
Notifications
You must be signed in to change notification settings - Fork 509
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
Point Detector Tally #3109
base: develop
Are you sure you want to change the base?
Point Detector Tally #3109
Conversation
…n and failed (core dumped)
…roblem simulating more than 5 particles
…g them, there energ was nan - ehat caused the memory problem
…nction. Works dynically with the number of soultions. verified.
…ron function bc the scoring happens from source
…o had again a round off problem with mu not in [-1,1]
Fixed 2 solution conditions for H1
…evelop Newest OpenMC Version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, there's a lot of new stuff going on here. My main question is: why do you think that point estimates should be interpreted as an estimating method for tallies in general? It seems like in fact, this is a special estimator that can only be applied for the point estimate filter. This special filter can only allow one type of estimator, the point.
Also, there is a substantial amount of undocumented code here, and no accompanying commentary on what's being done here in the PR documentation or docs changes. This is a nontrivial feature, so would need to be described a bit more. For example, I'm unsure what this is talking about when you say this is relativistic.
There is a fair amount of commented out debug printing. That would have to be removed before merging.
There must also be some limitations to this: for example, is this correct for treating resonance upscatter with DBRC or RVS? Getting the correctly normalized PDF value there is kind of nontrivial.
@@ -84,7 +84,6 @@ PenaltyBreakTemplateDeclaration: 10 | |||
PenaltyExcessCharacter: 1000000 | |||
PenaltyReturnTypeOnItsOwnLine: 200 | |||
PointerAlignment: Left | |||
QualifierAlignment: Left |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why remove this?
ARG openmc_branch=master | ||
ENV OPENMC_REPO='https://github.com/openmc-dev/openmc' | ||
ARG openmc_branch=deploy | ||
ENV OPENMC_REPO='https://github.com/itay-space/openmc.git' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this change.
@@ -281,7 +281,7 @@ enum class TallyResult { VALUE, SUM, SUM_SQ, SIZE }; | |||
|
|||
enum class TallyType { VOLUME, MESH_SURFACE, SURFACE, PULSE_HEIGHT }; | |||
|
|||
enum class TallyEstimator { ANALOG, TRACKLENGTH, COLLISION }; | |||
enum class TallyEstimator { ANALOG, TRACKLENGTH, COLLISION, POINT }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really make sense as a way to architect this feature. Semantically, the estimate of a quantity at a point is an entirely different problem from the different approaches to estimating otherwise. To be specific, in this case you are calculating contributions to a tally outside the usual process of filtering the state of a particle.
IMO, this should be classified as an entirely different type of tally similar to how pulse height tallies were done. POINT
should not be an option in TallyEstimator
, since this would allow someone to make a mesh tally that has the POINT
estimator type. That doesn't really make sense, if you ask me. This estimator is fundamentally tied to one specific type of filter, a (set of) dirac delta(s) in space.
@@ -23,7 +23,7 @@ class Distribution { | |||
public: | |||
virtual ~Distribution() = default; | |||
virtual double sample(uint64_t* seed) const = 0; | |||
|
|||
virtual double get_pdf(double x) const = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this density function infrastructure is very nice to have, and it could be used for other applications outside point estimates.
@@ -60,7 +61,9 @@ class Particle : public ParticleData { | |||
//! simply as a secondary particle. | |||
//! \param src Source site data | |||
void from_source(const SourceSite* src); | |||
|
|||
void initilze_ghost_particle(Particle& p, Direction u, double E); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check your spelling here
@@ -50,6 +50,7 @@ class FilterBinIter { | |||
void compute_index_weight(); | |||
|
|||
const Tally& tally_; | |||
Particle ghost_particle(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should document what this is doing.
ARG openmc_branch=deploy | ||
ENV OPENMC_REPO='https://github.com/itay-space/openmc.git' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ARG openmc_branch=deploy | |
ENV OPENMC_REPO='https://github.com/itay-space/openmc.git' | |
ARG openmc_branch=master | |
ENV OPENMC_REPO='https://github.com/openmc-dev/openmc' |
Description
This repository contains the development and benchmarking of a relativistic point detector within the OpenMC framework. The detector efficiently estimates neutron flux at a point using full relativistic kinematic calculations, making it ideal for high-energy particle simulations. This first implementation of a point detector tally in OpenMC is validated through single and multiple collision experiments, showing excellent agreement with conventional methods. This enhancement significantly improves OpenMC's capabilities for complex shielding analyses and other scenarios where traditional Monte Carlo methods may be inefficient.
Use Example
To configure a point tally in OpenMC, follow the standard procedure for creating a tally but specify the estimator as "point" and provide the coordinates for positioning and the exclusion sphere radius$R_0$ using a list of x, y, z, $R_0$ values. The following code snippet demonstrates how to set up a point detector located at coordinates (0, 0, 1) with an exclusion sphere radius of 0.01 cm, along with an energy filter, using the OpenMC Python API:
Checklist