However, my output only shows (n,g) capture and not other channels like (n,p) or (n,α)etc even when I expect these to occur. Could you please clarify why only (n,g) is being identified and what conditions or common‑block variables I should check to correctly distinguish and capture all relevant reaction channels?
I understand you’ve been busy with your schedule, and I appreciate your time in addressing my query.
I have successfully got reaction channel ( (n,p), (n,α), (n,g), (n,n’), (n,el), (n,d), (n,t), OTHER), using mgdraw.f and the genstk.inc and fheavy.inc files as suggested. However, when I post-process the results with a Python script for benchmarking against the standard ZR element, my results deviate significantly from the standard benchmark as shwon below.
Could you help me identify potential issues with either the mgdraw.f file or the Python script that might cause this discrepancy? Are there specific conditions or common block variables I should verify in my implementation to ensure accurate comparison?
I understand that everyone has their own busy schedules, but I would greatly appreciate any feedback or suggestions you may have regarding my approach.
Earlier, I shared a Python script (pka_post_process_multi_cycle.py) related to my PKA simulation, but I realized that I mistakenly uploaded the wrong file. I sincerely apologize for the confusion. The actual python scrip and his out file is below.
I am looking at the code of PKAPKA.f.
The condition at line 74 does not convince me. Can you please explain your logic there?
I agree with the fail-fast approach, but I would expect the routine to exit for:
IF ( ICODE .NE. 300 .OR. LTRACK .NE. 1 .OR. JTRACK .NE. 8) RETURN
, i.e.
IF ( .NOT.( ICODE .EQ. 300 .AND. LTRACK .EQ. 1 .AND. JTRACK .EQ. 8 ) ) RETURN
Could you please check whether this logic is consistent with your intent?
As a concrete reference, consider the routine downloadable at the top of this thread.
In addition, I cannot reproduce your plots by simply running your latest script (the latest terminal screenshot that you posted seems to be coming from the obsolete python processing script).
For clarity, could you please upload again the files that should be inspected and used for reproduction?
and also update lines 124-127 of old PKAPKA.f, as highlight in the updated mgdraw.f.
Out Summary File:
The PKA spectrum plotted output shows correct eV PKA energy on the x-axis but y-axis values (PKA s⁻¹ cm⁻³) that are orders of magnitude lower than expected; to determine whether the fault lies in the post-processing Python script or in the mcgraw.f itself.