Innova Physics UPV Handbook
Edition 2026-27 · version 1.0
Innova Physics UPV is a student engineering team of the Universitat Politècnica de València (UPV), recognised within Generación Espontánea, the university’s programme for student teams. We design, build and test tabletop electron accelerators, and we publish every design as open hardware.
This handbook explains what we are building, how the team is organised and how we work. It is written for anyone who wants to know us: students thinking of joining, other universities, sponsors and the university itself. It is kept short on purpose. Members learn the detail inside the team.
Why we exist
Particle accelerators are built by institutions, and a student rarely works on one before a master’s thesis or a PhD. Yet the field is large and needs engineers: more than 50,000 accelerators operate worldwide, and fewer than 6% of them serve fundamental research. The rest work in medicine and industry, in radiotherapy, sterilisation, semiconductor fabrication and materials processing [1].
ALOHA, A Linear Open-Hardware Accelerator, is our answer: tabletop machines designed by undergraduates, with every drawing published under an open licence so that other universities can build their own.
An accelerator is also an unusually complete engineering object. Even a tabletop machine needs vacuum, high voltage, electron emission, beam optics, control electronics, firmware, mechanical integration, diagnostics and radiation safety, all working together. Few student projects offer that breadth.
What we aim to do
- Train our members by having them design, build and test real machines under the supervision of a professor.
- Build open machines, starting with an electron source designed to serve two of them, and publish every design so that others can build their own.
- Open accelerator design to every student at the UPV through the UPV Accelerator Challenge, held each July from 2027.
In five lines
Build a beam you can see, and use it to find our people.
Build a beam you can measure, and use it to read a painting.
Build a beam that accelerates, once the first two have earned it.
Every July, teach what we have learned to anyone who wants to build.
Meanwhile, publish every drawing and hand every machine over to people who were not there when it started.
About this edition
We revise this handbook every September, together with the team’s plan, and date each edition. It holds what we expect to stay true for a whole season, and the page This season is the one rewritten each year. Schedules, rosters and procedures live on our website or in the team’s internal documentation.
The text of this handbook is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0) [2].
The ALOHA project
ALOHA (A Linear Open-Hardware Accelerator) is our principal project: a family of tabletop electron machines, built in stages. ALOHA started in 2026. Each machine is a complete instrument that can be built, tested and documented on its own.
Design requirements
Three requirements apply to every machine.
- Affordable. It has to be within reach of a teaching laboratory or another student team.
- Modular. Subsystems meet at defined interfaces, so that one can be replaced or improved without redesigning the rest.
- Customisable. Whoever builds the machine next will have a different budget, different goals and different parts. The design has to accommodate them.
The machines
The machines are numbered in the order they were proposed. While we build ALOHA-0, we design ALOHA-1. If the conservators who would use ALOHA-2 give the go, we then design and build it around ALOHA-0. ALOHA-1 waits for a host before it is built, so ALOHA-2 may be built first.
ALOHA-0, the electron source. A thermionic source in telefocus configuration: a tungsten hairpin cathode at −20 kV, with a Wehnelt electrode biased slightly below it, faces a grounded anode, and the beam ends on a graphite collector inside a closed vacuum chamber. Its design point is 20 keV and below 1 mA. We build it once, to the beam requirements of ALOHA-2, and a second unit of the same design is the injector of ALOHA-1.
ALOHA-1, the accelerator. An electron linear accelerator of up to 1 MeV. We design it now, without beam: accelerating cavities and their cold tests. We build it only once a university laboratory commits to using it, supervising it and housing it in a shielded room. Direction reviews that decision every September, with the Tutor’s agreement.
ALOHA-2, the instrument. We aim to make ALOHA-0 the source of an X-ray fluorescence instrument for the analysis of paintings. It adds a target that converts the beam into X-rays, an exit window that lets only X-rays out towards the painting, an energy-dispersive detector, shielding and a scanning stage. At 20 keV it is designed to read the core of a conservator’s palette: calcium, iron, copper, arsenic, mercury and lead. Its design starts from a meeting with its future users that fixes their requirements. The first decision there is the target, whose own emission lines must not hide the pigments conservators care about. Once the instrument is handed over, its users decide every measurement and we maintain it.
Model-0, the demonstrator. A glow-discharge demonstrator in which the discharge makes the path of an electron beam visible. It runs at 10 kV, at a pressure of 1.7 Torr measured with a Pirani gauge. We use it for outreach. It brought us our first sponsor, Edwards Vacuum.
The machine parameters and the record of design decisions are published in the ALOHA design documentation.
The UPV Accelerator Challenge
The UPV Accelerator Challenge invites students to work on the problems of state-of-the-art accelerators. It is open to every UPV student, undergraduate or postgraduate, whether they study engineering or physics. It is aimed above all at students with no previous experience of accelerators, and it is also held live online, where participants can present too. We plan to hold it every July, starting in 2027.
Each edition runs over two days, or more if registrations and talks call for it. In the mornings, members of the team teach workshops. In the afternoons, participants present their work. Any work on accelerators is welcome, from beam optics to radiofrequency, vacuum and electronics: simulated or built, made with any software, including work already shown at other conferences.
A task team organises each edition. The UPV and Generación Espontánea endorse the Challenge. Its page on our website will carry the dates, how to register and simple worked examples to start from.
This season
2026-27, the first season of ALOHA
Where we stand
- Built. Model-0, demonstrated in public.
- Simulated. The ALOHA-0 electron source, in COMSOL at 30 kV: a beam of 1.5 mA with a focus below one millimetre. The design point has since moved to 20 keV and below 1 mA, where the source is due to be simulated again.
- Measured. No ALOHA beam yet. Measuring the first one is the goal of ALOHA-0.
- Shown. In July 2026 we presented two posters on ALOHA at the accelECR poster session at CERN.
Objectives
- ALOHA-0. The vacuum system, pumped down and measured, is the minimum for the season. The cathode’s floating power supply follows if time allows. The electrodes and the high voltage wait for the requirements of ALOHA-2.
- ALOHA-1. Design of the accelerating cavities, and cold tests without beam.
- ALOHA-2. A requirements meeting with its future users, and their decision on whether to go ahead.
- The UPV Accelerator Challenge. Preparation of the first edition, planned for July 2027.
The schedule of ALOHA-0 depends on component deliveries.
Joining the team
We recruit students of any degree at the UPV. No previous knowledge of accelerators is expected: candidates learn what they need inside the team.
Departments
Every member belongs to one of four departments.
| Department | Its work |
|---|---|
| Applied Physics | Beam simulation and accelerator physics |
| Electronics and Control | High-voltage supplies, interlocks and firmware |
| Technical Design | CAD, vacuum and mechanical assembly |
| Communication | Visual identity, publications and figures. No physics background needed. |
As the machines develop, the work divides into two lines: instrumentation, around ALOHA-2, and radiofrequency and beam physics, around ALOHA-1.
What members gain
Members work on real machines in a team run like an engineering project, with reviewed work, recorded decisions, defined interfaces and safety rules. Under a professor’s supervision, they gain practical experience in:
- electronics, from schematic and circuit board layout to assembly, test and microcontroller firmware;
- mechanical design and the integration of vacuum equipment;
- supervised work with vacuum, high voltage and radiation protection;
- simulation of fields, radiofrequency cavities and particle beams, checked against measurement;
- visual identity, figures and science communication;
- version control, design reviews and technical writing in English.
The trial period
New participants enter as Candidates. A Candidate joins a department and spends a trial period on design, simulation or documentation tasks with a defined scope, mentored by the department’s lead. Candidates do not work on laboratory equipment. At the end of the trial, Direction decides on admission on the basis of the work delivered. The tasks, dates and criteria of each round are given to its candidates at the start.
What we expect
- Presence. We work in person. Laboratory and simulation work are done on site, and members attend regularly during term.
- Studies first. Academic obligations come first. Members say in advance when exams or coursework will reduce their availability.
- Handover. A member who leaves hands over open tasks, documentation and access before going.
How to apply
We recruit in rounds, announced on our website and social media. To ask about the next round, write to innovaphysicsupv@gmail.com.
Values
We expect the following of every participant, in all technical work.
- Measurement decides. A simulation is a hypothesis until a measurement agrees with it.
- Every number carries its unit and its status. Measured, simulated, design or estimated, with its tolerance, its provenance and, where relevant, its convention: full or half angle, peak or average.
- Aims are stated as aims. We say what we aim to do, and we claim only what we have done.
- Negative results are reported. A design that failed, a geometry that would not converge or a supplier that did not deliver is written down promptly.
- Work is documented. Members turn over every two or three years. The standard is that a competent stranger can continue the work from the repository alone.
- Safety rules are followed exactly. Nobody operates hazardous equipment without training and authorisation.
- Nothing is understood by only one person. A subsystem that a single member can explain is a defect to be corrected, and every role is handed over with overlap.
Organisation
Direction
The team is directed by three people.
- The Tutor, a member of the UPV’s teaching staff, holds final authority on safety, on relations with the university and on any decision with legal or institutional weight. The Tutor also gives the team continuity across student generations.
- The Team Lead is responsible for the team as a whole: its programme, its external relations, the annual proposal to Generación Espontánea and this handbook.
- The Co-Lead shares the coordination and the technical programme with the Team Lead and deputises for them.
The Tutor appoints the Team Lead and the Co-Lead for each season.
Departments
Every member belongs to one of four departments: Applied Physics, Electronics and Control, Technical Design, and Communication. A department is where its members learn and qualify. Its lead, selected by Direction, mentors the department’s candidates, assigns its members to tasks and reviews work in its area. Until a department has a lead, a member of Direction leads it.
Task teams
Deliverables are produced by task teams. A task team forms around one deliverable, such as a circuit board, a subsystem, a document or an edition of the Challenge. It draws its members from whichever departments the work needs, and it dissolves when the deliverable is accepted. A task team has no technical leader. Its convener schedules meetings, keeps the record and reports progress to Direction; the role is administrative and rotates.
Standing responsibilities
Some functions continue through the year whatever the deliverables: safety, documentation, procurement and recruitment. Each is held by a named member alongside their engineering work. Maintaining a machine handed over to its users becomes a standing responsibility of its own.
Handover
Every role changes hands with overlap. In the second semester, each department lead chooses a shadower, who takes over the role the following season. Each Team Lead trains a Co-Lead for a full season before leaving.
Membership levels
| Level | How it is reached | What it allows |
|---|---|---|
| Candidate | Acceptance in a recruitment round | Trial tasks in design, simulation and documentation, mentored by the department lead. No laboratory equipment. |
| Member | Admission by Direction at the end of the trial | Work in task teams. May hold a standing responsibility or lead a department. |
| Qualified | Demonstrated competence in one area, such as vacuum, high voltage, firmware or simulation | Independent work in that area, including its equipment once the Tutor authorises it. Review of others’ work in that area. |
Qualification is held per area: a member can be Qualified in one area and in no other. Direction positions sit outside these levels.
Contributors and collaborators take part without joining the team: students who contribute a defined piece of work, and external institutions, companies and specialists.
How decisions are made
We take decisions close to the work, write them down where the work is, and escalate along a fixed path when agreement fails.
Who decides what
| Decision | Taken by | Recorded in |
|---|---|---|
| Technical choices inside a task | The task team | The pull request |
| Choices that constrain the design: a parameter, an interface, a component, a licence | The task team proposes, the department lead or a member Qualified in the area reviews, and Direction accepts | A Design Decision Record |
| Starting to build a machine | Direction, with the Tutor’s agreement; for a machine built for users, after their go | The team’s plan |
| Safety rules and authorisations | The Tutor | The safety documentation |
| Budget, purchases, sponsors and external relations | Direction | Direction’s records |
| Admission of members and selection of department leads | Direction | Direction’s records |
| The next season’s Team Lead and Co-Lead | The Tutor | Direction’s records |
Reversible and irreversible decisions
A decision that can be undone cheaply is taken by whoever is doing the work and noted in the pull request. A decision that is costly to undo needs a Design Decision Record before work proceeds: purchases, frozen interfaces, changes to published parameters and anything that affects safety.
Consent by default
A proposal posted where the work is discussed stands if nobody objects within three working days during term. An objection states a reason and, where possible, an alternative.
Escalation
When a task team cannot agree, its convener takes the question to the Team Lead. Questions of safety or of institutional weight go to the Tutor, whose decision is final.
The plan and the record
Direction keeps a plan for the coming seasons and reviews it every September, including the decision on whether to build ALOHA-1. This handbook is revised at the same time.
A decision exists once it is written in a pull request or a Design Decision Record. Agreements reached in a meeting or in chat are written down the same day by whoever proposed them.
How we design
Lifecycle of a deliverable
Every deliverable, from a circuit board to a complete machine, passes through the same stages.
- Define. Requirements and acceptance criteria are written before design starts. They state what will be measured to show that the deliverable works.
- Design and simulate. The design is developed in the repository, with its calculations and simulations.
- Review. The department lead or a member Qualified in the area reviews the design before anything is ordered or built. Designs involving high voltage, vacuum or the beam also pass a safety review.
- Build. The deliverable is built as designed, and every deviation is recorded.
- Test. The deliverable is measured against the acceptance criteria written at the start.
- Release. Design files, test results and documentation are published.
A machine built for users passes one more stage before handover. It measures reference samples only; the university’s radiation protection and occupational safety services check its dose rate and its electrical safety; and a written agreement fixes ownership, maintenance, training and responsibility for safety. From then on, the users decide every measurement.
Tasks and pull requests
All work is tracked as tasks in our GitHub organisation. Every task has an associated pull request, opened early as a draft and merged after review. A task is done when its pull request is merged; work that is not in the repository is not done.
When accepted work changes how a machine is built or operated, the public design documentation is updated as part of the same task.
Design Decision Records
Every decision that constrains the design is recorded in a short Design Decision Record: the decision, the alternatives considered and the reason.
Machine parameters
The parameters of each machine live in a single parameter table. Drawings, simulations and documents refer to it, and changing it takes a Design Decision Record.
Reports and notes
Results are written up in two numbered series, set in the team’s LaTeX class: INNOVA-REP for reports and papers, INNOVA-TN for technical notes. A simulation report states the tool and its version, every input value and the method, so that another person can reproduce the result; large model files stay on the team’s workstations. Before a document is released, a member who is not among its authors reads and checks it. Released documents are published openly, with a DOI, under CC BY 4.0.
Safety
We work with high voltage, evacuated vessels and, from the first beam onward, X-rays. We control these hazards first by design and then by procedure.
Principles
- Fail-safe design. Equipment is designed so that any single failure brings it to a safe state. We aim for a residual risk comparable to that of a standard teaching laboratory.
- Authority. The Tutor holds final authority on safety. Equipment involving high voltage, vacuum or the beam is operated only with the Tutor’s authorisation.
- Qualification. Members operate equipment only in the areas in which they are Qualified. Candidates do not work on laboratory equipment.
- Two people. Work on energised or evacuated equipment requires at least two people present, one of them Qualified in the area.
- Interlocks. Interlocks and emergency stops are designed, reviewed and tested like any other subsystem.
- Licences. Any licence or authorisation the law requires is held by university staff, never by a student.
- Records. Every operation of laboratory equipment is entered in the laboratory logbook.
Radiation
Electrons stopping in matter produce X-rays. Shielding is part of every machine’s design. The university’s radiation protection service measures the dose rate of each ALOHA machine before its first beam, and again before any handover.
Procedures
The safety rules in force, the list of authorised operators and the procedure for each system are kept in the team’s internal documentation.
Conduct, credit and licensing
Conduct
We treat each other, and everyone we work with, with respect. Harassment and discrimination are not tolerated. The team is part of the UPV, and its members are bound by the university’s rules.
A concern can be raised with any member of Direction. A concern about Direction goes to the Tutor.
Credit
Work is credited to the people who did it, and the repository history is the record. Authorship of posters, papers and public documents follows contribution and is agreed before submission.
External communication
Statements on behalf of the team, to sponsors, the university or the press, are made by Direction or with its agreement. Members who write to external parties do so from their university address with the team address in copy, so that the team keeps the record when people move on. Partners are named only with their agreement.
Licensing
Hardware designs are released under the CERN Open Hardware Licence v2, Strongly Reciprocal (CERN-OHL-S) [3]. Anyone who distributes modified hardware based on our designs must publish those modifications under the same terms. We keep hardware sources in formats that free tools can open; circuit boards are designed in KiCad.
Software will be released under a copyleft licence of comparable strength. The choice between GPL-3.0 and AGPL-3.0 is open and will be recorded in a Design Decision Record before the first public release of code.
Documents, this handbook included, are released under CC BY 4.0 [2]. Participants contribute their work under these licences.
Tools
We keep our collaboration tools few and give each one a single purpose.
| Tool | Used for | Kept out of it |
|---|---|---|
| Zulip | Day-to-day communication, with one topic per task or pull request | Decisions of record. A decision agreed in chat is written into the pull request or a Design Decision Record the same day. |
| GitHub | Tasks, pull requests, reviews, design files, code and documentation | Large binary files such as simulation models and raw data |
| Google Drive | Spreadsheets, the team calendar, media and compiled documents | Design sources, which belong in the repository |
Formal documents are written in LaTeX with the team’s class, on Overleaf, and kept in a repository of our GitHub organisation. References come from a shared Zotero library, so that every document cites from the same source. Simulation runs on the team’s workstations, which are used on site.
The laboratory logbook records every operation of laboratory equipment. It is separate from the Research section of our website, where we publish our work for the public.
Passwords and other credentials are never written in any of these tools. Direction grants access to each tool according to membership level and withdraws it when a participant leaves.
The engineering software in use is listed in the team’s internal documentation.
Glossary
ALOHA. A Linear Open-Hardware Accelerator: our family of tabletop electron machines.
ALOHA-0. Our electron source: a thermionic source in telefocus configuration, designed for 20 keV, with its vacuum, high-voltage, control and diagnostic systems.
ALOHA-1. An electron linear accelerator of up to 1 MeV, in design. It is built only once a university laboratory can host it.
ALOHA-2. The X-ray fluorescence instrument for paintings that we aim to build around ALOHA-0.
Model-0. Our glow-discharge demonstrator, used for outreach.
UPV Accelerator Challenge. Our yearly event for UPV students: workshops by the team and presentations by the participants.
Direction. The Tutor, the Team Lead and the Co-Lead.
Tutor. The member of UPV teaching staff who holds final authority on safety and on institutional matters, and who appoints the Team Lead and the Co-Lead.
Team Lead. The student responsible for the team as a whole.
Co-Lead. The student who shares the coordination with the Team Lead and deputises for them.
Department. One of the four groups in which members learn and qualify: Applied Physics, Electronics and Control, Technical Design, and Communication.
Department lead. The member, selected by Direction, who mentors a department’s candidates, assigns its members to tasks and reviews its work.
Shadower. The member a department lead chooses in the second semester to take over the role the following season.
Task team. A group formed around one deliverable and dissolved when the deliverable is accepted.
Convener. The member who handles the administration of a task team.
Standing responsibility. A function held by a named member through the year, such as safety or procurement.
Candidate. A participant in the trial period.
Member. A participant admitted by Direction at the end of the trial.
Qualified. A Member with demonstrated competence in one area, allowed to work independently in it.
Contributor, collaborator. A person or institution that takes part without joining the team.
Design Decision Record (DDR). A short document stating a decision, the alternatives considered and the reason.
Pull request. A proposed change to a repository, reviewed before it is merged.
INNOVA-REP, INNOVA-TN. Our numbered series of reports and papers, and of technical notes.
Laboratory logbook. The internal record of every operation of laboratory equipment.
Research. The section of our website where we publish our work for the public: papers, posters and write-ups.
Cold test. A low-power radiofrequency measurement of an accelerating cavity, made without beam.
Telefocus. An electron source whose electrode geometry places the focus far beyond the anode.
X-ray fluorescence (XRF). A technique that identifies the elements in a material from the X-rays they emit when excited.
Generación Espontánea (GE). The UPV’s programme for student teams.
References
[1] S. Sheehy, “Applications of Particle Accelerators”, in Proceedings of the CERN Accelerator School: Introduction to Particle Accelerators, 2nd ed., 2024. Available: https://cas.web.cern.ch/previous-schools
[2] Creative Commons Attribution 4.0 International, Creative Commons. Available: https://creativecommons.org/licenses/by/4.0/
[3] CERN Open Hardware Licence Version 2, Strongly Reciprocal, CERN, 2020. Available: https://ohwr.org/cern_ohl_s_v2.txt