The beam model

The beam model describes how the beam travels: beam systems and beams, paths of components (open lines and rings, with branches and merges), each component’s definition, apertures, alignment and datasets such as optics. It is independent of any simulation code, and linked to the real equipment.

Bring a model in

1. + New → Beam model.

2. Upload a file: the canonical *.beam.json, or one to convert:

   Format	Files
   MAD-X sequence or line	.madx, .seq, .str, .mad
   MAD-X TFS table (twiss)	.tfs
   Elegant lattice	.lte
   Bmad lattice	.bmad, .lat
   Xsuite line	.json
   Accelerator Toolbox (pyAT)	.json

   Or start one from scratch in the editor.

3. ARGUS checks it and says how complete it is, level by level (topology, lattice, geometry, optics, physical, integrated) and what is missing for the next level.

Markers, and what a simulation does not compute

A lattice places with markers what its simulation computes nothing for: a vacuum pump, a valve, a gauge, a reference point. The beam model is not one simulator’s view of the machine, so markers are kept by default (untick keep markers to leave them out). A marker whose name follows the usual conventions becomes what it names:

Name starts with	Becomes
VPI, SIP, IGP, TMP, NGP, PMP, PUMP	vacuum pump
VG, GAUGE, PIG	vacuum gauge
FV, VFV	fast valve
VV, GV, VLV, VALVE	gate valve
BEL, BLW, BELLOW	bellows
WIN	vacuum window

Any other marker stays a marker. The viewer draws each kind with its own symbol. A model imported before markers were kept does not have them: import it again to add them.

Check an imported model

Look at its paths, the order of its components, positions, units and the datasets it has. Completeness says which kinds of information are there; it does not say the model matches the machine installed, nor that it is valid for a particular calculation. Keep the source file, note which configuration it describes, and read the conversion warnings before relying on it.

Look at and edit a model

Beam model (side bar) lists the models. Open one to see its paths, components and their positions along the beam. The editor changes the model, its definitions and datasets, boundaries along paths, alignment, state mappings and value provenance; saving keeps a new revision.

Remove a model

On the Beam model page, remove beside a model’s name takes the whole model out of the workspace:

• its systems, paths, elements and datasets are retired, with their history; tickets and installations that point at them stay as they were;
• its values, stored documents and asset bindings are deleted.

Importing the same model again brings it back as the same records.

Link components to equipment

From a model, open its asset synchronisation:

1. ARGUS proposes which physical asset implements each component, from names, aliases, type, beamline, position, order and neighbours, each with a confidence and the evidence.
2. Confirm, correct or reject each proposal. A confirmed link makes the asset installed at that position.
3. Confirmed links are kept on later synchronisations; only new or changed components are proposed again.

Before confirming, check the unit’s identifier and the evidence: a similar name or a neighbouring position is a clue, not proof. Do not confirm a planned or future model as the current installation unless that is what you mean to record.