Category Archives: Physics

Update: Trigger game

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.

Screenshots

Updated event display
Updated event display
Showing the various modes (some in development) with a garish colour scheme.
Showing the various modes (some in development) with a garish colour scheme.
Updated Spy mode, analysing the data.
Updated Spy mode, analysing the data.

Work in progress: Trigger game

Like the Science Shift Simulator, this is a game that emerged as a subset of the aDetector project. The player has to save events that match the criteria given, just like a trigger does in real life. The results are then combined across all the players in a given team to determine the final score. The scores can be combined across experiments to make a “discovery”. This is still in development, which will continue over the net week and months.

Links

Live page
Spy page
GitHub repository

Overview

This is another cooperative multiplayer game aimed at showing the public (especially high school pupils) how particle physics research actually takes place. Any number of players can take part and they are split into “Team ATLAS” and “Team CMS”. The score of each team is determined by the performance of the players on each “shift” they take at the trigger, and the final scores are combined for the discovery of the Higgs boson. There is also a “spy” mode where people can see the events as they are submitted.

Challenges

Challenge: This project needs an attractive, fast, and realistic detector model.
Solution: Having already developed a decent detector model for the aDetector project, I simply used a two dimensional version for this project. I then split the detector finely in \(\eta\) and \(\phi\) to make interactions between the particles and detector easier. The aesthetics went through a few iterations before settling on the final design. However further optimisations and aesthetic changes are anticipated as development continues. (Resolved, to be revisited.)
Challenge: This game puts a bit of a strain on my server.
Solution: My web space uses a shared server, so sometimes many HTTP requests from the same client looks like a Denial Of Service (DOS) attack, resulting in a throttling of the requests. There are two main strategies to overcome this. The first option is to bundle up several requests into one request, reducing the total number of requests, and the load on the server. This solution has not been implemented yet. The second option is to change the server settings. I do not have access to these, but as development continues I intend to move to a different server that can handle so many very small requests. (To be revisited.)
Challenge: This game needs cross platform and cross device support.
Solution: This game was initially intended to be played with an iPad, but I did not have an iPad for testing. On the day of the release of the game I had to tweak the settings so the response times were slower with respect to mouse events to make it easier to play on a tablet device. These settings are trivially changed to allow multiple device support. (Resolved.)
Challenge: The game should be repsonsive to the inputs of the user.
Solution: Initially the game did not confirm success when a user clicked on the screen and this lead to confusion. As a result I had to add a big green “tick” for success and a big red “cross” for failure to inform the user of the status of the event. (Resolved.)
Challenge: The game needed an animated histogram for the final result.
Solution: I’ve made histogras before, including histograms that update themselves on the aDetector project, but until now I had not animated a histogram. This was a bit tricky as I had to call events which were using the this keyword, so the histogram object had to be stored as a global variable because, although I’d like to, I couldn’t use this to refer to the histgoram. Javascript can be frustating like that. (Resolved.)

Screenshots

I don’t normally put lots of screenshots up, but I’m quite proud of the asethetics here, so here are the three main screens of the main game:

The front page of the game.
The front page of the game.
The transition page of the game.
The transition page of the game.
The game in progress.
The game in progress.

The design went through a few iterations before settling on the current choice:

Design 1
Design 1
Design 2
Design 2
Design 3
Design 3

Work in progress: Science Shift Simulator

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.

Links

Live page
GitHub repository

Overview

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.

Challenges

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.
Solution: This is the first game I made that has mini games in it, and this required a different strategy for development. Making a generic mini game module in Javascript is not easy, and there will be some further significant changes as I rewrite this code again. (Resolved, to be revisited.)

Screenshot

Here’s the page as it currently looks. It needs a bit of a facelift!

Screenshot of the Shift Leader's page
Screenshot of the Shift Leader’s page

LHC Driver

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.

Links

Live page
GitHub repository

Overview

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!

Challenges

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.)

Screenshots

Here is a screenshot of the game in its current form:

Screenshot of the LHC Driver game
Screenshot of the LHC Driver game

I don’t usually show screenshots of previous stages of development, but here is the first version of the game:

Screenshot of the previous version of the LHC Driver game
Screenshot of the previous version of the LHC Driver game

aDetector

One of the projects I have wanted to develop for a long time is a browser based particle physics experiment simulator. Such a project would generate events using Monte Carlo methods and simuate their interactions with the detector. This was made partly as an educational aid, partly as a challenge to myself, and partly because at the time I was feeling some frustration with the lack of real analysis in my job. As expected for a Javascript based CPU intensive appplication, this reaches the limits of what is possible with current technology quite rapidly.

Links

Live page V1
Live page V2
Live page V3
Live page V4
Live page V5
GitHub repository

Overview

The model for the detector is saved in an xml file which is loaded using the same methods developed in the Marble Hornets project. Particle data are currently stored in Javascript source files, but will eventually use xml as well. The particle interactions are simulated first by choosing a process (eg \(e^+e^-\to q\bar{q}\)) and then decaying the particles. Jets are formed by popping \(q-\bar{q}\) pairs out of the vacuum while phase space allows and then arranging the resulting pairs in hadrons. Bound states are then decayed according to their Particle Data Group (PDG) branching fractions, with phase space decays used. The paths of the particles are propagated through the detector using a stepwise helix propagation. Energy depositions in the detector are estimated, according to the characteristic properties of the detector components. A list of particles is then compiled based on the particles produced and these can be used to reconstruct parent particles.

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.

Challenges

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.)

Screenshot

Screenshot of aDetector V5
Screenshot of aDetector V5

LXR tidy

When I was working on the CMS experiment I used their LXR a lot when browsing code. The interface was fairly basic and would return a poorly formatted (and unsemantic) HTML output, so I write a greasemonkey script to make the results easier to read. Within a couple of weeks of writing this code the developers improved the output, so this project never got any wider use.

Links

CMSSW LXR home
GitHub repository

Overview

The output is parsed and carefully separated into different results. These are then wrapped in more pleasant looking HTML, colour coded based on the file type (with characters for the colour blind) and the main modules are summarised to give an idea of the main users of a given piece of code.

Challenges

Challenge: The default output is terrible. Just terrible.
Solution: The default output was not even semantically correct (from what I remember there were no <html> tags) so I had a hard time parsing the DOM properly. Special character sequences such as << appearing in C++ code didn’t make things much easier. (Resolved.)

Screenshots

Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output before the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied
Screenshot of LXR output after the tidy script is applied

IIHE Nobel Prize website

When I started working for the ULB at the IIHE I wanted to get involved with some outreach activities. One of my first activities was the creation of a website celebrating the Nobel Prize in Phsics 2013, which was awarded to Fran├žois Englert and Peter Higgs for the prediction of the scalar (Higgs) boson. This involved collaborating and development using HTML, CSS, and PHP, with multiple language support, search engine optimisation, YouTube integration, and video recording sessions. The results was a webpage where the users of the lab got to show off what they did to the wider world and to show how the rich physics program at the lab was relevant to the prize. It was a fun project to work on, it was my own creation and was excellent practice for working on similar projects in the future.

Screenshot of the IIHE Nobel Prize 2013 websiteScreenshot of the IIHE Nobel Prize 2013 website
Screenshot of the IIHE Nobel Prize 2013 website

Live page

Reflections

A “reflection” is a term in particle physics for when a decay of one particle looks like the decay of another. It’s a topic which has been studied for about fifty years, and seemed like an excellent chance to combine physics and coding.

Links

Live page
GitHub repository

Overview

To make a reflection it’s necessary to take one particle that decays to two daughters, and then assign the wrong mass hypothesis to at least one of the daughters. The way this is done is by using PHP to generate an SVG image with Javascript embedded within it. The user then makes a POST request to create a new image.

The definition of the helicity angle is the angle between one of the daughter particles, and the relativistic boost into the lab frame, in the frame of the mother particle. The angle is determined by explicitly boosting into this frame and taking the dot product.

Challenges

Challenge: This was one of the first projects where I had to map onto a coordinate system on a canvas.
Solution: This is not as easy as it sounds when axes are involved! By appropriate use of the log function and creating margins it was possible to make a two dimensional histogram, which is a model I’ve used ever since. (Resolved)
Challenge: This project needs some insight into how the underlying physics works.
Solution: It took some thought about how to make this work effectively, as it’s essentially an exercise in four vectors, which are always more subtle than I’d like. (Resolved)
Challenge: The plot needs to be updated to match the user’s input.
Solution: At the time this was written I was already used to using both PHP and SVG, which were the state of the art at the time. It’s a bit clunky to send a POST request every time the plot needs to be updated, and now we have the canvas. At some point I should update this code to use Javascript and the canvas. (Resolved, to be revisited)

Screenshot

Here is the output for the decay \(\Lambda \to p \pi\) (\(m(\Lambda)=1150 ~\mathrm{MeV}\)) creating a reflection for the decay \(K_S^0 \to \pi\pi\) (\(m(K_S^0)=497~\mathrm{MeV}\)), which has been studied for decades.

Screenshot of a classic reflection
Screenshot of a classic reflection

Advent Calendar 2012

This is a collection of YouTube videos as made as an outreach project in December 2012. Each day of Advent gives a different interesting fact about particle physics.

Links

Live page
YouTube acount
GitHub repository

Overview

This is mostly an exercise in using the YouTube Javascript API. It was this project that made me realise that the old Javascript API is now deprecated, which means I will have to update the Marble Hornets project at some point.

Challenges

Challenge: The YouTube Javascript API changed.
Solution: Having already become accustomed to the old YouTube API, it was somewhat frustrating to get used to a new one, but such is life and working with bleeding edge technologies! (Resolved.)

Screenshot

Screenshot of the Advent Calendar 2012
Screenshot of the Advent Calendar 2012

ScramBuildEggs

This project parses a build log and gives more intuitive output.

Links

GitHub repository

Overview

This is a script that parses the build log created by the CMSSW command “scram build” (hence the name!) It takes the output, wraps it to a more readable width, splits errors by type and colours them, and also gives more useful output. It’s not complete yet, but it is already rather useful.

Screenshot

ScramBuildEggs screenshot
ScramBuildEggs screenshot