-
Notifications
You must be signed in to change notification settings - Fork 201
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
Change alpha particle momentum initialization #5033
Change alpha particle momentum initialization #5033
Conversation
Now alpha particles will be initializes with momentum calculated via the two step alpha_1 channel, which has a higher cross section than the alpha_0 channel currently used.
It looks like there is an issue with the pB fusion test. Update: FAIL: The energies of the alpha particles produced in the second stage (Be8* -> 2 alpha) are not within the relative tolerance of the analytical calculation. In particular, there is a larger variation in the function |
Corrected the mass of the Be to account for the mass defect due to being an excited state. The conservation of energy tests now pass.
Now the code reproduces the expected alpha particle energy distribution with this simple model. This Figure is a plot retrieved from the test simulation and matches the distribution in Spraker et al (2012) quite well. Why the test is failing? I can't see where the issue comes from - if anyone has any suggestions let me know. |
Thanks for the update @PhysicsDan! I'll take a look at the changes and also see if I can understand where the test failure is coming from later this week. |
* Modified released in fusion and decay steps of pB reaction. Ensures the delta mc2 = energy released, at both the fusion and decay step
Thanks, I had another look and can't find the issue. The values that the simulation outputs are compared against are calculated using: max_p_alpha23 = 0.5*(np.sqrt(p_sq_after) + \
np.sqrt(4*m_a*energy_alpha2_plus_3_theory - p_sq_after))
min_p_alpha23 = 0.5*(np.sqrt(p_sq_after) - \
np.sqrt(4*m_a*energy_alpha2_plus_3_theory - p_sq_after))
max_energy_alpha23 = max_p_alpha23**2/(2.*m_a)
min_energy_alpha23 = min_p_alpha23**2/(2.*m_a) The max and min energy values for the momentum are calculated using the same variables but only the calculation of the maximum alpha energy passes. This most recent commit modifies the energy released in the fusion step and decay step to make sure it matches the energy calculated based on the
Another note: I noticed all the masses include the electron mass. |
I haven't had a chance yet to investigate the test failure but I wanted to comment so long on your note
We are aware of this, but opted to consistently use masses with electrons included in the fusion module (see #4480). The reasoning was that in other parts of WarpX we allow ionization of a species but, for simplicity, that process does not change the particle mass. Therefore, WarpX already has other modules where we assume keeping the electron mass is an okay approximation and we decided to stick with that approach in the fusion module. |
@PhysicsDan I believe I understand the reason for the error you are seeing and it is not actually due to a bug or an error, just statistical variation. The failing test is meant to check whether the range of alpha energies fall within the expected range, but is doing this by checking that the maximum and minimum values are close to the theoretical min and max values. How close the observed energies will get to those bounds is simply a matter of statistical sampling. I ran the test using different random seeds and recorded the difference between the observed energy bounds and the theoretical ones. The results were as follows (I show the minimum bound differences as negative values to make the symmetry between max and min "errors" clear): |
* Test one - abs. tol. in min energy of alpha2 and alpha3 is 20 keV * Test two - abs. tol. in min energy of alpha2 and alpha3 is 200 keV
Thanks, good spot! Here is just changed the test tolerance to: I left the tolerance of the maximum values unchanged. |
@@ -494,9 +494,9 @@ def check_initial_energy1(data, E_com): | |||
|
|||
assert(np.all(is_close(energy_alpha1_simulation, energy_alpha1_theory, rtol=5.e-8))) | |||
assert(is_close(np.amax(energy_alpha2_simulation), max_energy_alpha23, rtol=1.e-2)) | |||
assert(is_close(np.amin(energy_alpha2_simulation), min_energy_alpha23, rtol=1.e-2)) | |||
assert(is_close(np.amin(energy_alpha2_simulation), min_energy_alpha23, atol=3.218e-15)) # 0.02 MeV abs tol |
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.
Could we change this and the other similar calls to the following instead?
assert(is_close(np.amin(energy_alpha2_simulation), min_energy_alpha23, atol=3.218e-15)) # 0.02 MeV abs tol | |
assert(0 <= np.amin(energy_alpha2_simulation) - min_energy_alpha23 < 3.218e-15) # 0.02 MeV abs tol |
That way we simultaneously check that the minimum energy is not less than the theoretical minimum and that the minimum value is close to the expected minimum. I think it would then also be good to swap the maximum energy checks to the same approach otherwise someone looking at the code in the future might be confused by the asymmetry. What do you think?
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.
I made these changes. However, the test now fails.
File "./analysis_proton_boron_fusion.py", line 587, in check_initial_energy2
assert(0 <= np.amin(energy_alpha2_simulation) - min_energy_alpha23 < 3.218e-14)
It appears in check_initial_energy2
that the difference between the limits. I.e, the np.amin(energy_alpha2_simulation) - min_energy_alpha23 < 0
and
np.amax(energy_alpha2_simulation) - max_energy_alpha23 > 0
.
check_initial_energy1
passes - we are in the center of the momentum frame
check_initial_energy2
fails - we are in the boron ion rest frame
I assume that there is some small error in the transformation between reference frames causing this.
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.
That is unfortunate! Do you know if this same issue was present before changing the reaction pathway (this PR)? If so, we can change the check_initial_energy2
function back to the way you had it when the test passed (and merge this PR) and create a new issue to look into the origin of the energy exceeding the expected limits.
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.
No, I'll have a look later this week and let you know. Yes, no problem if it is an issue in the previous version I'll revert the test and create an issue.
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.
Original Version (check_initial_energy2
). This is what we expect.
My branch:
For some reason, the minimum value of the 2nd and 3rd alphas generated is less than calculated in the analysis.
The larger absolute variation is ok because the energy of the 2nd and 3rd alpha particles is also slightly larger via the alpha1 channel.
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.
Apologies for the spam. I had a look at the check_initial_energy1
as well.
TLDR:
The main dev branch will fail if we check if the alpha particle energy is within the limits we calculate theoretically in the check_initial_energy1
function (both max and min are wrong) but pass the check_initial_energy2
.
My branch will pass check_initial_energy1
but fails check_initial_energy2
as some alpha particles are generated with a lower energy than expected. The maximum values are correct.
Could this be some floating point issue that is amplified by the Lorentz transformation that will be performed during the simulation for check_initial_energy2
? Perhaps this is only apparent as the minimum alpha energies are ~x7 lower in the alpha1
channel compared to alpha0
channel.
Summary: In my opinion, this PR is still a net benefit as the alpha spectrum generated matches better what has been observed experimentally (despite the issue above).
If you agree I can revert the tests so that they pass with the updated E_fusion
and E_decay
values
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.
Thanks for checking @PhysicsDan. I agree with you that since the current development
version also seem to fail this more rigorous check, albeit in the first test instead of the second, we can merge this to gain the benefit of the more accurate decay channel. So please do revert the check in check_initial_energy2
to the case where the test passed and let's also summarize the observed discrepancy in a new issue.
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.
So just to make sure, the problem is actually only observed with the second case (where the COM frame and labframe are not the same)? If so, the check for energy in case 1 could be as we discussed previously (checking the energy range falls strictly between the theoretical min and max energy) while the second case's check could then be updated once the underlying issue is fixed.
That change for the case 1 tests is not necessary before merging. I just wanted to point out that case 1 does not have any remaining issues.
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.
Yes to confirm check_initial_energy1
does pass with
assert(0 <= max_energy_alpha23 - np.amax(energy_alpha2_simulation) < 3.218e-15)
assert(0 <= np.amin(energy_alpha2_simulation) - min_energy_alpha23 < 3.218e-15)
assert(0 <= max_energy_alpha23 - np.amax(energy_alpha3_simulation) < 3.218e-15)
assert(0 <= np.amin(energy_alpha3_simulation) - min_energy_alpha23 < 3.218e-15)
There are no issues with case 1 in this PR. However, this test would fail with the previous alpha0 channel implementation.
In `check_initial_energy2` the max and min sim. values are above and below theoretical calculations. Tests now check variation is within an absolute tolerance. Note: Total energy is still conserved.
Now the maximum alpha particle energy from simulation is compared to the analytical value using relative tolerance, not abs tolerance.
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.
Thanks for updating this!
Please remember to create a new issue from the observed inconsistency with the alpha particle energies and link this PR to it. (You could even create an issue from the comment in which you explain the observed errors).
Yes no problem, I will do that now. Just to note I had to change the check that compares the maximum values to a relative tolerance. The percentage variation is ~constant across a range of proton energies. |
Currently, the alpha particle energies are initialized based on the two-step process:
$\alpha_0$ channel$^{11}$ B $\rightarrow$ $^8$ Be + $\alpha$ + 8.59 MeV
$^8$ Be $\rightarrow$ 2 $\alpha$ + 0.09 MeV
p +
The dominant reaction channel is the$\alpha_1$ channel:$^{11}$ B $\rightarrow$ $^8$ Be* + $\alpha$ + 5.557 MeV
$^8$ Be* $\rightarrow$ 2 $\alpha$ + 3.124 MeV
p +
I have modified the two lines where the fusion and decay energies are defined to use the$\alpha_1$ channel.
In the future, this could be modified to calculate the probability of each channel but this is a simple update that should match the expected alpha distribution better.
Paper with plots of the two channels and nuclear energy levels: https://doi.org/10.1016/j.radphyschem.2022.110727
@roelof-groenewald - this may be of interest to you
ToDo