Fields

GEMC propagates charged tracks through one or more electromagnetic fields. Each field is an independent, named object that Geant4 queries for a magnetic flux density B at every step point.

Fields are declared in YAML. A configuration can mix any number of them; GEMC builds the field registry once per worker thread and hands each volume the field manager it needs.

Two ways to define a field

Both routes produce the same kind of runtime object — a GField — and share the same integration controls (integration_stepper, minimum_step).

A minimal example

gmultipoles:
  - name: dipole
    pole_number: 2
    strength: 2
    rotaxis: z
    rotation_angle: "30*deg"

gemc mydetector.yaml

Attaching a field to geometry

Defining a field only registers it — it stays inert until a volume uses it. There are two ways to apply a field to the geometry, and they can be combined:

Because Geant4 uses the field manager of the nearest enclosing volume, a per-volume emfield overrides the global field locally. A common pattern is a global field for the whole apparatus plus a stronger, more specific field inside one magnet:

gmultipoles:
  - name: holding         # weak field everywhere
    pole_number: 2
    strength: 0.5
    rotaxis: z
  - name: magnet          # strong field inside one volume
    pole_number: 4
    strength: 1.2
    rotaxis: z

global_field: holding     # attach 'holding' to the ROOT world volume

The magnet field is then attached to a specific volume through that volume’s emfield label, and wins over holding wherever the two overlap. The <name> given to global_field (or to a volume’s emfield) must match the name of a field defined under gmultipoles or gfields.

Common keys

Every field entry — whichever route — accepts these integration controls:

Querying a field

You do not need a full simulation to inspect a field. Two options print B at chosen points and exit — see Field plugins → Querying:

gemc dipole.yaml -fieldAt="10*cm 0*mm 2*m"
gemc dipole.yaml -fieldMapPoints=field_points.txt