# Presentation: 143758

## High-Brightness Injector Modeling

*Presented at the 2004 Advanced Accelerator Concepts workshop*
*John W. Lewellen*

## Some Basic Questions

**What does “High-Brightness” mean?**
**What’s an injector?**
**What do I mean by “modeling?”**
**What is this talk *****not***** about?**
- Detailed description of individual codes
- Comparison between different “injector” codes
- Not here to castigate nor advocate a particular code, code suite, or code writer;  *every* injector code has bad points, most have good points too.

## What is brightness?  What’s High-Brightness?

**One canonical definition:**
**Another definition:**
**The actual characteristics of a beam, relative to those which are of interest for the task we wish to perform with the beam**
**In useful terms, brightness is situational.**

## What’s an injector?  Why single it out?

**Broadly:  an accelerator which provides beam to another accelerator.**
- Plasma channel
- DC or RF gun, perhaps including a booster tank
- Linac (including source)
- Linac + damping ring
**For this talk:  kinetic energies from 0 ******** ~30 MeV (for electrons)**
**Why single it out?**
- Transition to relativistic motion;  allowed approximations change
- Beam quality doesn’t get any better than it is here (generally)
- Keystone component:  Replacing the injector can upgrade the facility performance as a whole

## What is modeling?

- (The solution is left as an exercise to
- the modeler.)

## Generic Modeling Process

- Beam
- Simulation

- Beam Sim
- Results

- Optimizer

- Cavity
- Design Code

- Cavity
- Properties

- Field
- Properties

- Each link:
- adds computation expense
- must be validated for correct operation with *all* previously applied links
*should* increase self-consistency and validity of the answer

## What is the intent of modeling?

**Determine the behavior of a corresponding physical system**
- What kind, and level, of detail determined by the goals for the injector
- What level of physical abstraction is acceptable?
- Increasingly, more than “beamware” is needed

**Notes:**
Make the note here that “modeling” a wakefield does not necessarily mean modeling the interaction;  it can be an analytic result applied to the beam.  Again, levels of abstraction from reality;  and make the point that one needs to know where the limits are.

## What are some trends?

**Lower emittance (tranverse & longitudinal both)**
- Particle emission models become far more important
- Fine-structure intrabeam interactions become far more important
- Beam-edge details become more important
- Short-range wakefield details become more important
- Need to handle disparate spatial scales in general
**Higher average power**
- Beam halo modeling becomes far more important
- Impedance modeling becomes far more important
- Cavity modeling becomes far more important
**Unique design configurations require new sim. capabilities**
- BNL diamond-pass cathode
- SRF photoinjectors
- LANL Cs-regeneration cathode
- UMd photo-thermionic cathodes
- APS planar focusing cathode

## Directions for Injector Development

- “Big Iron” accelerators
- Linear colliders
- Next-generation x-ray light sources
- “Desktop” accelerators
- Electron microscopy
- Electron beam lithography
- Small laboratory experiments
- “Mini-Me” accelerators
- Radioisotope generation
- High-power free-electron lasers
- Slow positron production
- Pulse radiography

- Courtesy SLAC/LCLS

## Directions of exploration...

- _Some different requirements_
**“****Big Iron”**
- lower emittance (10x)
- higher peak currents (5x)
- emittance aspect ratio control
**“****Desktop”**
- ultra-low emittance (103x)
- very low energy spreads (10-5)
**“****Mini-Me”**
- (usually) modest beam quality (e.g. we can sometimes get there today)
- high average power (e.g. 1 MW from the gun for FEL)
- at least quasi-CW operation
- beam halo is a critical issue

- _Some common themes_
- Higher performance levels than are routinely achieved today are demanded
- With few exceptions, the injector is a quasi-standalone component
- Injector reliability is key to the uptime of the entire facility
- Backup injector capability would be a large benefit
- “Beyond the beam physics” issues are very important

## What do we need to get started?

- What are we modeling, overall?  Gun?  Gun + linac?  Etc.
- What is the particle source to be modeled?  Cathode type?
- Is the gun a DC, RF or hybrid gun?
- What is the operational parameter space for our new source?
- How many spatial dimensions are required?
- What physical effects will we need to incorporate?
- How do we determine the applied fields?  Model the cavities?
- What type of beam model are we assuming?  Particle-based?  Fluid-based?
- What type of space-charge model are we going to use?  Lorentz-transformed pseudo-PIC code?  Point-to-point?  Ring-to-ring?  True PIC code?  A hybrid?  Vlasov equations?
- What interactions with the environment (e.g. cavity wakes) do we deem important?  Which of those do we include?
- Do we care about jitter?  If so, which parameters?  How do we model that?
- Is this a scenario under which we care about particle-field-particle effects (e.g. CSR, FEL interaction)?  How is *that* approached?
- How will we know if the simulation results are valid or not?
- ...

## What is to be modeled?

**Beam ******** beam interactions**
- “space charge”
- Bunch-bunch interactions
**Beam emission / generation process**
**Beam ******** field interactions**
- Acceleration
- Focusing
- Synchrotron radiation, CSR

**Beam ******** cavity interactions**
- Wakefields
- Surface heating
**Cavity ******** field interactions**
**Multiple interactions**
- Retarded potentials
- Beam loading
- e- secondary formation
- Beam emission

- “Just the Physics”

- “Other Stuff”

**Long-timescale effects**
**Cavity / power source interactions**
**Beam loss**

**Jitter**
**Component reliability & lifetime**
**Etc...**

## What is being modeled?

- Surface heating
- Wakes

- Retarded
-     potentials
- Beam loading
- Beam Emission
- e- secondary
- Halo formation

- Surface gradients
- Shunt impedance

**Notes:**
Note that this says nothing about self-consistency;  it just says what one is attempting to take into account.

## Alternate view of the modeling process:

- Beam

- “Support Systems” design

- Fab.
- tol.

- Thermal
- control

- Non-Ideal and “Novel” Effects

- Device

- Maint.

- “Physics” Codes

- “Engineering” Codes

- Poisson/Superfish, MAFIA, HFSS,
- Omega/Tau3P,
- HOMDYN,
- PARMELA, GPT, spiffe, Tredi,
- IMPACT, ASTRA,
- MAD, Elegant, Trace-3D, traffic4,
- EGS4, ...

- SPICE
- ANSYS
- Pro/E, AutoCAD,
- SolidWorks,
- ...

## Just a reminder...

- The “physics stuff” allows you to postulate a new beam source,
- and perhaps build & test it on a small scale.
*However....*
- The “other stuff” is what you need to build and use it
- successfully, be it a small lab or a national facility!
- The easier the interface, the better the chances
- of getting it right!

## For future codes:

**The algorithms need to be known and the implementation well-documented.**
**There should be means for (helping to) validate results;  these should be well-documented also.  This includes documenting known problem areas with the algorithms, as well as post-change validation testing.**
**Some features that would be nice:**
- The ability to add new interactions, fields, particle emission models, etc., without dramatic changes to the core code.  (Murphy’s Law in context.)
- General usability improvements
- True multiphysics

## Two Forward-Looking Codes Codes

**General Particle Tracer – GPT**
- Commercial code, copyright Pulsar Physics (Netherlands)
- Beam physics code
- Does not include PIC capabilities, so no intrinsic beam-element interaction
**Finite-Element Modeler – FEMlab**
- Commercial code, copyright COMSOL, Inc.
- “Device Engineering” code ... sort of.
- 1 – 3D models, MATLAB interface avail.
- Does not include beam physics (yet) or system-level design

## Beam Physics – GPT (General Particle Tracer)

***Beam Physics – GPT (General Particle Tracer)***

- Source code
- provided for all
- elements and
- interactions

- GPT is a
- commercial code;
- copyright
- Pulsar Physics

- User-defined
- elements treated
- the same as built-
- in elements

- Can be run in
- batch mode

## FEMlab – Finite-Element Modeling Software

- FEMlab copyright COMSOL, Inc.

- Built-in “multiphysics” modes ... but can
- define one’s own equation system

- Analytic expressions for coupling:  here,
- heating at Cu/vac. boundary via H

- Time-dependent fluid flow already built-in...

**Notes:**
Special notes:
 This is a “physicist’s code” as much as an “engineer’s code” and can be used for cavity field modeling very well.
 has capabilities of importing models directly from some popular formats, such as IGES and AutoCAD
 compares well with codes like ANSYS, is relatively easy to use, and is “physicist-friendly”

## Common themes:

**Good balance between oversimplification and single-career codes**
**Extensibility is built into the programs from the start**
**Some built-in tools to assist with validity and input checking**
**Ability to run in a user-interface mode, or in a “batch” environment suitable for automated execution (with some digging)**

## Where do we go from here?

***Detailed***** photoemission process**
**Beam-bunch microinstabilities, longitudinal space-charge instabilities**
**Evolution of ultra-low emittance beams**
**Head-tail effects;  energy spread effects**
**Self-field images from cavity / injector surfaces**
**Resolving beam, field, edge effects in extreme geometries (e.g. needle-type cathodes)**
**Improved interaction between beam physics, cavity design, and cavity modeling codes, as well as core code improvements.**
**Inclusion of other physics effects, for “total gun” modeling**

## Acknowledgements

- ANL Theory Institute on Production of Bright Electron Beams:  “Towards Advanced Electron Beam Brightness Enhancement and Conditioning”  (http://www.aps.anl.gov/techpub/lsnotes/lsnotesTOC.html)
- John Petillo (SAIC), Dave Dowell (SLAC), John Power (ANL), Patrick O’Shea (UMd), Kevin Jensen (NRL), Rob Rybe (LBL), Lloyd Young, James Billen (LANL), Cecile Limborg (SLAC), and many others
- Pulsar Physics (GPT)
- COMSOL, Inc. (FEMlab)

## Murphy’s Law in Context:

**Any really new idea is bound to break at least one simulation code.  Why?  Because it’d be a feature of some code, somewhere, if someone thought of it already.**