Add RMC to the muon stop pileup capture products, and add a test script

[michaelmackenzie]

Add RMC the list of muon stop pileup capture products. The RMC rate for aluminum is 1.4e-5 for E > 57 MeV over the closure approximation spectrum fraction for E > 57 MeV (~1/10,000 muon captures). This is in connection to Offline PR 1375.

[FNALbuild]

Hi @michaelmackenzie,
You have proposed changes to files in these packages:

• Tests
• JobConfig

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for 3e49a75: build (Build queue is empty)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at 3e49a75.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 3e49a75 at 2b61d64
build (prof)	✅	Log file. Build time: 08 min 34 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 0 files
clang-tidy	✅	0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at 3e49a75 after being merged into the base branch at 2b61d64.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[brownd1978]

Thanks for the quick response! I have some basic questions. Also note that this change won't affect existing MDC2020 output, we would need to remake the pileup stream and rerun mixing for it to have an effect. It would be useful to have a comparison of the output before/after this change.

[brownd1978]

This configuration is for 'external', does that mean it generates photons? Is that redundant with the flat spectrum above?
What about internal conversion? Should there be a 2nd tool instance for that?

[michaelmackenzie]

Yes, we would need to have a second tool in the list for internal conversions. I can add this as well if this makes sense to you. Its rate will be reduced by 0.0069 with respect to the real photons for reference. I can also consider updating the RMC generator tool to randomly generate internal instead of external conversions at this relative rate if this makes more sense.

[brownd1978]

On Thu, Nov 21, 2024 at 5:45 AM michaelmackenzie ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In JobConfig/pileup/MuStopPileup.fcl <#368 (comment)>: > @@ -54,6 +54,19 @@ physics : { spectrumShape: "flat" } tool_type: "MuCapPhotonGenerator" + }, Yes, we would need to have a second tool in the list for internal conversions. I can add this as well if this makes sense to you. Its rate will be reduced by 0.0069 with respect to the real photons for reference. I can also consider updating the RMC generator tool to randomly generate internal instead of external conversions at this relative rate if this makes more sense.

I think we should be generating both internally converted (e+e- pairs) and real photons. Only having 1 seems physically inconsistent. Whether that's 1 tool or 2 is an implementation detail and best left to your expertise. But either way, the common physics components should be synchronized.

…

— Reply to this email directly, view it on GitHub <#368 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH572KIE2HMCYBSGCO7HL2BXPXNAVCNFSM6AAAAABSFQJI3KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDINJRGQ2TIOBSGU> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[FNALbuild]

📝 The HEAD of main has changed to 9545a97. Tests are now out of date.

[michaelmackenzie]

Yes, we would need to have a second tool in the list for internal conversions. I can add this as well if this makes sense to you. Its rate will be reduced by 0.0069 with respect to the real photons for reference. I can also consider updating the RMC generator tool to randomly generate internal instead of external conversions at this relative rate if this makes more sense.

I think we should be generating both internally converted (e+e- pairs) and real photons. Only having 1 seems physically inconsistent. Whether that's 1 tool or 2 is an implementation detail and best left to your expertise. But either way, the common physics components should be synchronized.

I updated the Offline PR to include internal conversions randomly selected using the internal conversion branching fraction (measured for RPC). This now generates external and internal conversions at their expected rates with one tool entry in the capture products list, naturally keeping the spectra synchronized given any updates. I tested generating muon stop pileup to see that RMC is added at the expected rate (I saw 2 events with 20k generated stops) as well as that the internal conversions are generated at the expected rate (I increased the overall RMC rate for this test due to the low expected rate). Are there any other tests you would suggest running?