In the world of particle physics it’s possible to simulate (our best approximation of) the fabric of reality. The bad news is that this comes at a cost. Nearly all software is made in-house by scientists. Many of them are excellent programmers, but many aren’t. The documentation is often missing steps and there are sometimes dependecies of outdated packages. To make matters worse the documentation is often sparse and pointing to the wrong resources.
Today I’m trying to use two packages called pythia and Delphes, which are used to simulate particle collisions and the respective detector responses. So far I’ve had to visit the pythia page at least four times (including outdated pages that no longer exist) to find the correct location of the package. Once downloaded and installed, it turns out it requires some additional packages to run the parts I need. That means going down another rabbit warren of pages and outdated links to find out how to get FastJet and HepMC.
On one hand keeping all these packages separate and linking to each home page makes things more versatile and faster to develop. On the other hand having a single recipe or even a single installer can work wonders and get people using these projects more quickly and easily. That’s what the CMS experiment does, and it gets people past the fisrt hurdle. All you need to do is a simple cmsrel <name> and then cmsenv and you have a fully working, internally consistent copy of the CMS software infrastructure. Each step that gets added to the process is a hurdle between the user and the end result, which often leads to frustration to the point where people simply give up trying to make things works. There have been several times in the past where I’ve made the decision that continuing to pursue a given route is just pointless. That’s why whenever I make a package I try to give simple all-in-one instructions to make things as easy as possible.
In any case this blog is supposed to be a useful repository of knowledge about the things I make and do, so here’s the link to the recipe: Physics cheatsheets.
This is a work in progress, with much more space for much more development at a later date. The user can change some settings to generate different sequences. The only reason the project is so small is lack of time and interest to devote to it.
Giving the user more control over the parameters. Many new variables were added that the user can edit, including the number of “breeds” of cells, number of “families”, the size of the cells, how the play area wraps around in the \(x\) and \(y\) directions, the base health of the cells, and after how long they start to decay (a new feature.)
Addition of the history bar. This records the recent evolutiom of the simulation, allowing the user to see how changing the different varaibles affects the overall stability of the populations.
Refactoring to object oriented code. Initially the code borrowed from Conway’s Game of Life, where the history of the cells was not important. As a result the code was simply a two dimensional array of states. As the tricolor cellular automata became more sophisticated it became necessary to introduce a class to handle the cells. This simplified the code greatly.
The user can now view the “health” of the cells. Each cell has a health associated with it, and turning on the option to see the health clarifies where most of the changes are taking place. The regions close to the boundaries have less health, giving a dark outline. Large areas without any “food” lose health, making the decay more obvious/
The layout of the page was tidied up significantly. There is less whitespace and better use of existing space. There is still room for improvement though, as a single button should be used for changing all settings, and a description of all the parameters should be given. It should also be made explicit which changes of settings require the play area to be completely redrawn.