In recent weeks I’ve been working a lot on the Trigger game (Live page.) These update have included an overhaul of the style, addition of new pages, rewriting of the “Spy mode”, adding new particles, tweaking the graphics, and many more changes behind the scenes. The code was significantly refactored to make it easier to extend and understand, as now this has becomes a collaborative project. The game has been tested on a few schools and shown to be a good success with children (and adults) and it seems to have a bright future. I also added sounds, music, and a simple music player.
The Science Shift Simulator game is something that emerged from development of the aDetector project and LHC Driver projects. The mechanic is loosely based on the cooperative game Space Team. This is still in development, so the current page doesn’t actually work at the time of writing, and development will continue over the net week and months.
This is a cooperative multiplayer game aimed at showing the public (especially high school pupils) how particle physics research actually takes place, with an emphasis on cooperation. The game proceeds by bringing up several issues that need to be solved. The “Shift Leader” has information about how to solve the problems, but no control over the various subsystems. Instead they have a team of “Shifters” whose job is to solve the problems. This then becomes a problem of communication, cooperation, and optimisation between the various players.
For this project each player has control of a browser, which communicates with a central server. The Shift Leader’s client sends problems to the server, which are then collected by the Shifters’ clients. As a result the main difficulty in developing this game is synchronisation, especially when there are network problems!
Eventually this project will be reskinnable to allow other developers to add their own content. This will also be moved into a collaborative space, as this will have several developers in the future.
- Challenge: The big problem is synchronisation.
- Solution: This is not the first project I’ve developed that required the client and server to communicate via AJAX requests, but it is the first that had more than one client sending information to the server. In fact it was this project that persuaded me to install MySQL locally and hook it up to Apache to get a local LAMP stack running on the my laptop. I got a prototype version working for demonstration purposes, but had to cut some corners. Development stopped in the middle of a significant rewriting of code, which is still to be completed. (To be revisited.)
- Challenge: This game contains many mini games.
Here’s the page as it currently looks. It needs a bit of a facelift!
I wanted to make a “steady hand” game and realised I could make one based on the beams of the LHC. In this game the player(s) have to control magnets in the \(x\) and \(y\) directions to keep the beams on target. This eventually lead on to the Science Shift Simulator games.
Both beams have a random walk that moves them around the canvas. The player(s) can affect the forces that act on the beam(s) in the \(x\) and \(y\) directions and have to keep the beams within the valid range of the canvas. If the beams are close to each other then the instantaneous luminosity increases, and the integrated luminosity is a measure of the score. When the beams get dumped there is the customary toilet flush!
- Challenge: I had to make sliders to control the forces.
- Solution: This is the first time I made some sliders (that I would later reuse in the Mandelbrot project) and it was trickier than I thought it would be. The event listeners need to keep track of all mouse and keyboard actions to use the slides properly and intuitively. (Resolved.)
- Challenge: This was the first two player game I made.
- Solution: Making a game that two players can play is a bit tricky, since their controls cannot be allowed to interfere with each other. This was achieved by moving both with the keyboard. (Resolved.)
Here is a screenshot of the game in its current form:
I don’t usually show screenshots of previous stages of development, but here is the first version of the game:
The user has access to several controls to interact with the application. They can choose how to view the detector, using Cartesian coordinates and two Euler angles (with the roll axis suppressed.) The most expensive parts of the process are the generation of the event displays and the generation of the particle table. By default these are only updated after a certain interval, to allow the user to accumulate a significant number of events without being slowed down by the graphics. To save time the detector itself is rendered once in a cutaway view, and the particle tracks are overlaid on the saved image. Eventually the user will be able to get a full event display, including the detector response to the particle with glowing detector components etc.
The user has access to collections of particles, including electrons, muons, pions, kaons, photons, and protons. From these they can construct other particles, making selections as they do so. Once they have made parent particles they can then plot kinematic variables including mass, momentum, transverse moment, and helicity angle. This should, in principle, allow students to learn how to recreate particles and how to separate signal from background effectively.
Given the large amount of information available the user has access to a number of tabs which can can be collapsed out of view. This allows the user to run the application with the expensive canvas and DOM updates, and thus collect many more events.
This is still a work in progress, with reconstruction of particle being the next main priority. Eventually the user would be able to load their favourite detector geometry and beam conditions, then perform their analysis, saving the output in xml files and possible being able to upload these to a server. This would allow users to act as “players” with “physics campaigns”, including the SPS experiments, HERA experiments, B factories, LEP experiments, and LHC experiments. This is, of course, a very ambitious goal, and one which has been ongoing for over a year at this point.
See other posts tagged with aDetector.
- Challenge: A sophisticated model for the detector was needed.
- Solution: The detector is split up by subdetector, with each subdetector having its own characteristic responses to different particles. The detector is split up in cylindrical coordinates, \((
ho,\eta,\phi)\), with each subdetector also being split into modules. Individual modules then react the particles for reconstruction purposes. Thus with a few key parameters even a sophisticated model can be stored in a few variables that can be tuned quickly and easily. (Resolved.)
- Challenge: The detector shold have a three dimensional view that the user can control.
- Solution: The detector is drawn using a wireframe with transparent panels. This is a method I developed in 2009 for a now defunct PHP generated SVG based visualisation of the BaBar electromagnetic calorimeter, which I used to show the absorbed dose as a function of detector region and time. The drawing algorithm is not perfect, as panels are drawn in order from furthest from the user to closest. This is sufficient for most purposes, but occasionally panels will intersect causing strange artefacts. Eventually this should be replaced with a much more stable, robust, and fast implementation, such as in three.js. (Resolved, to be revisited.)
- Challenge: Particles should be modeled realistically and physically correctly.
- Solution: Particles are modelled with the most important parameters (mass, charge, decay modes etc) taken from the PDG. Their kinematic properties are modeled using special four vector classes, and decay products “inherit” from their parents in a consistent manner. Particles at the highest layer of the tree are assigned their four momenta, and then their decay products are decayed, inheriting the boost and production vertex from their parents. This is repeated recursively until all unstable particles are decayed. So far this does not take spin into account, as everything is decayed using a phase space model. Particles with large widths have their lineshape modeled using a Breit-Wigner shape. As a result, particle have realistic looking jets and four momentum is conserved. This required the development of special libraries to handle these decays and kinematic constraints. (Resolved, to be revisited.)
- Challenge: Particles decay trees must be traversed consistently.
- Solution: This is harder than it sounds! Every time an event is generated, particles are recursively decayed for as long as phase space allows. The particles must then be traversed and dispalyed in the table, in a consistent manner. Ensuring that all particles are listed hierarchally without missing anything out takes some care. (Resolved.)
- Challenge: Particles lists had to be prepared for the user.
- Solution: The user has access to a handful of “building blocks” to play with. These are taken from the (generated) list of particles per event and filtered by the particle type. Further lists can be created or filtered from these lists, and parent particles can reconstructed from combining lists. This means having to provide special classes to handle the particles and ensure that no particles are reconstructed recursively (leading to infinite loops.) Apart from using reconstructed particles instead of generated particles, this has been resolved. (Resolved, to be revisited.)
- Challenge: The user needs to be able to make histograms.
- Solution: I had made histgorams for other projects, including the Reflections and Box plotter projects, so this was mostly fairly easy to do. Even so, being able to create new histograms of arbitrary scales and variables on the fly meant that this histogram class had to be more robust than previous projects. (Resolved.)
When dealing with systematic uncertainties in physics it’s often important to know the relative contributions of each unceratinty to the overall uncertainty. This script compares all the uncertiaties, assuming they are \(0\%\) correlated.
The script arranges the uncertainties by size, then adds the uncertainties in quadrature and then expresses them as a radial distance from the lower left corner, showing the effect of each uncertainty. This makes it easy to determine where to focus effort in an analysis, and which areas of analysis will not give much benefit in terms of systematic uncertainty reduction.
- Challenge: The output needs to be clear and easy to read.
- Solution: The code needed to create the relevant geometry is fairly trivial to write. The only difficult part was adding the labels in such a way that they are all unambiguous and legible. At the moment the script works, but for a much larger list of systematic unceratinties, the labels may fall outside the plot area. (To be revisited)
In 2014 the CMS experiment at CERN released their 2010 data to the public for analysis. As a quick exercise I decided to analyse the dimuon mass spectrum to show that this could be done in a reasonable amount of time.
The input file is the 2010 Run B comma separated values file. The python script then produces mass spectra for same sign and opposite sign mass spectra and zooms in on the interesting regions.
- Challenge: The main challenge was that this project was made as quickly as possible.
- Solution: This project uses python and existing ROOT libraries for the maximal development speed. The other data format available was using CMSSW and a virtual machine. In principle using CMSSW should be straightforward, but I decided against using this because the software was already four years old and support would be minimal or non-existant, even to current CMS physicsts. (Resolved)
This project creates an infographic showing the ROOT colors and how they relate to each other.
Physicists use ROOT to make plots and it’s often useful to be able to easily browse the color space. ROOT provides a color wheel, but I find the rectangular display very useful as well. In principle, colors in the same column should suit each other, which makes the rectangular display more useful than the color wheel.
This project is intended to make a map from \((x,y)\) space to \((\eta,\phi)\) space to make analysis in the CMS endcaps easier and more intuitive.
This script arranges “superclusters” around the endcap and shows what a cone of constant \(\Delta R\) looks like.
This project was written as part of the content for a talk presented at the International Workshop on Future Linear Colliders to compare the future prospects of the LHC and lepton colliders. It is shared here in case it is of use for other physicists.
This project simply plots a series of graphs.
- Challenge: Using a TMultigraph in pyroot is not easy.
- Solution: In order to make this work I had to use the array module, a step I usually forget! This macro should save me a few headaches in the future. (Resolved.)
For my thesis I needed to describe many of the know mesons and baryons. To better illustrate their relation to each other I decided to create an SVG image showing a three dimensional representation in isospin and weak hypercharge space.
The multiplets are constructed from a series of points, wires and polygons. These are then rotated using two of three Euler angles (the rotation about the intrinsic \(z\) axis is not useful in this case) and the resulting SVG document is written server side using PHP. The client is then left to render the image.
- Challenge: The SVG image had to be rendered in such a way that objects were not obscured in the 3D view.
- Solution: This was one of the first projects where I had to write a simple 3D viewer from scratch, and I opted to use the median dstance of an object form the viewer to determine the order in which to draw the objects. There were a few minor tweaks to acount for instances where this was not always successful, but the overall result was efficienct and overall I am pleased with the solution. This is very similar to the techniques I used for the EMC viewer and the aDetector project. (Resolved)
- Challenge: This project allows the user to rotate the multiplets and the rotation must be intuitive.
- Solution: This is only really meant to be used by physicists who are used to thinking with angles, and used to poor user interfaces, so given the audience I would say that the user interactions is a big success. However the page still makes requests to the server, meaning that the rotations do not happen in real time, and in the case of mutiple requests could lead to a large overhead on the server. In the future this should be handled client side to free up server side resources and speed up the user experience. (Resolved)