[jackal1-66]

This PR adds the transport and detector response of magnetic monopoles to
o2-sim when running with Geant4. Related to https://its.cern.ch/jira/browse/O2-6780

Until now, a monopole could neither be defined as a particle nor lose energy in
the detectors, since it has no electric charge and the standard Geant4 physics
does not ionise for it.

• Four new particles, Monopole_symm/Monopole_asymm and their antiparticles
  (PDG codes ±4110000 and ±4120000), are registered in O2DatabasePDG and
  the Geant4 particle table. The helpers are in MonopoleParticles.h.
• O2MonopolePhysics provides the monopole ionisation (mplIoni) and a
  dedicated transport process with the full dual Lorentz force. It does not
  replace the global chord finder or the stepper requested by the VMC macro.
• ITS and TPC ProcessHits let neutral monopoles deposit energy. ITS gets a
  monopole response and a data format, TPC uses a Bethe-Bloch based ionisation.
• GeneratorFactory takes the monopole mass so that generator and transport
  agree, and the monopole hook is combined with the fast-sim hook.

Everything is steered by three new G4Params options:

• G4.monopole (default false) switches the monopole physics on.
• G4.monopoleMagneticCharge is the charge in units of the Dirac charge (default 1).
• G4.monopoleMass is the mass in GeV (default 100) and has to agree with the
  mass in TDatabasePDG, otherwise the run is fatal.

A non-positive magnetic charge or mass, or monopole physics requested but not
installed, are also fatal.

By default nothing changes for the user: the particles are only defined and the
lookups in ITS and TPC are only done when G4.monopole is set.

The changes were validated with Schwinger pair-produced monopoles and several
values of the magnetic charge.

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.

[wiechula]

Dear @jackal1-66 , I just merged another PR that touches the TPC Detector code. I seems that this brought in a conflict. Please have a look.

[jackal1-66]

Ciao @wiechula, could you please check that my solution works well for you? I gave priority to your condition over isMonopole.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 39381ca at 2026-09-21 13:44:

No log files found

Full log here.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 1d62ef1 at 2026-09-22 16:59:

No log files found

Full log here.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 26f3cee at 2026-09-22 20:19:

No log files found

Full log here.

[ihrivnac]

Hi @jackal1-66 ,

I've found a few issues in the proposed update:

1. O2MonopoleTransportation replaces the chord finder but leaves the field manager’s DoesFieldChangeEnergy() flag false. Consequently, G4Transportation discards the integrated kinetic-energy change. The existing VMC G4MonopoleTransportation explicitly takes the final kinetic energy from the integrated field track. Discarding this change affects acceleration, stopping range and subsequent energy deposition.

2. Local field managers bypass the monopole equation of motion. Only the global field manager receives the monopole chord finder. A region or volume with its own field manager therefore uses its ordinary equation, losing the monopole’s magnetic-force contribution. This matters only if such local fields are used. We were not previously using local fields, but @sawenzel recently introduced them to support different field configuration parameters in different regions.

3. Defining monopoles as kPTHadron causes VMC to attach hadron ionisation and multiple scattering. The PR removes the ionisation process but leaves multiple scattering. Is that intended? Consider defining these particles as kPTUndefined and explicitly attaching the intended monopole processes, while checking that the required VMC cuts and step limits remain effective.

4. The magnetic-moment workaround is not thread-safe. Temporarily changing G4Transportation::EnableMagneticMoment() modifies a shared static flag. This does not affect O2’s process-based parallelism, so it can be considered a low-priority issue.

[jackal1-66]

Ciao @ihrivnac thank you for your review, I fixed the first three issues you mention, while I kept the 4th as it is, given that it's currently not relevant in our framework, as we don't run G4 multi-threaded. I also clean up a bit the code and fixed some other minor problems. Let me know what you think.

[ihrivnac]

Ciao @ihrivnac thank you for your review, I fixed the first three issues you mention, while I kept the 4th as it is, given that it's currently not relevant in our framework, as we don't run G4 multi-threaded. I also clean up a bit the code and fixed some other minor problems. Let me know what you think.

Thank you. The items 1. and 3. are now ok; in the 2nd, there is still ignored passing the DeltaChord parameter: The shared monopole chord finder copies DeltaChord only from the global manager during construction. Installing it on a local manager therefore overrides that manager’s chord tolerance. I attach a patch that fixes it
local-delta-chord.patch.

[jackal1-66]

Ciao @ihrivnac , you are right. I just applied your patch so now also point 2 should be settled.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 0af8023 at 2026-10-22 11:41:

No log files found

Full log here.