Quick jump to:
The offline website at Fermilab is the best place for general information on the MINOS software. The User's Manual is particularly helpful.
I suggest that all users of the code subscribe to the MINOS software discussion list. Quite a lot of useful (as well as useless) information moves through the list and it's worth scanning every day in order to keep your ear to the ground.
We maintain a local copy of the offline software at /unix/minos/software/minossoft/ . This area should be visible from every MINOS workstation. The directory is structured in a somewhat complicated and non-intuitive way which I will try to briefly explain. The main directory holds the following subdirectories:
kordosky> ls /unix/minos/software/minossoft/ packages/ releases/ setup/ srt/
Users can choose to use one of multiple the releases (e.g. versions) of the offline code:
kordosky> ls /unix/minos/software/minossoft/releases/ boot/ development/ R1.11/
Here there are two releases: development and R1.11. The boot directory holds some utilities (e.g. scripts and so on) and should be ignored.
The development release is a snapshot of the current MINOS code and is updated from the main repository at Fermilab regularly. As such it has all of the newest bells and whistles but can also be unstable since (a) sometimes buggy code gets committed and (b) the performance of the programs can change subtly from day to day. Therefore, using the development release is probably only advisable for people actually doing code development rather than analysis.
People doing analysis should probably use a frozen release , denoted as RY.XX . These releases are composed a specific version of each source file of the offline code. Here's how it works: About once a month the software group ("core group") announces (on the software discussion list) that it's time for a new frozen release. As part of the announcement they identify a specific date on which all the code then in CVS will be marked ("tagged") and used to make the frozen release. People scurry around for a few days trying to get their code in shape and iron out any bugs. As the date approaches there is often a flurry of Q:"Are you ready?" A:"Yes!/No! I just found a bug!" mails sent to the list. This process sometimes pushes back the release date. Eventually, everyone is ready and the code is tagged. After tagging the code is built at Fermilab and some tests are run to make sure that it works. If it does, the core group reports that the release is available.
On occassion, bug-fixes are backported into frozen releases.
Each release contains a number of packages:
kordosky> ls -1 /unix/minos/software/minossoft/releases/R1.11/ Algorithm@ Alignment@ AltDeMux@ AltReco@ AstroUtil@ AtNuReco@ BeamData@ . . .
Here, I'm using the frozen release R1.11 as an example. The other frozen releases and the development release look pretty much the same.
The packages are really just directories which serve to organize the code. The code in each package (directory) is built into a shared library and all of the shared libraries are stored here:
kordosky> ls -1 /unix/minos/software/minossoft/releases/R1.11/lib/Linux2.4-GCC/ libAlgorithm.so* libAlignment.so* libAltDeMux.so* libAltReco.so* . . .
The main executable (i.e., program) is called loon . Loon is essentially ROOT with MINOS's code linked into it. So, pretty much anything you can do using ROOT can also be done inside loon. ROOT is interesting because it (a) provides features like histograms, graphs, data I/O, etc. that everyone needs and (b) allows users to write short macros (in C) which control its operation. Since loon includes the MINOS code those short macros can be used to reconstruct and analyze our data. Loon (for frozen release 1.11) is located at:
/unix/minos/software/minossoft/releases/R1.11/bin/Linux2.4-GCC/loon
The software uses a MySQL database ("the offline database") to store a wide variety of data. This includes the information needed to relate electronics channels to the strips in the detector that they read out (the "plex"), calibration constants, the detector geometry, and so on. The local database runs on db1.hep.ucl.ac.uk and is essentially a copy of the main Fermilab database. Most users will not have to worry about talking directly to the database. However, if you do, the database interface is nicely described in the User's Manual.
The offline database was rebuilt from scratch on Nov 30 - Dec 1 2004. I retrieves updates from Fermilab each hour and checks itself for differences with Fermilab every night. So, it should always have the latest numbers.
Newer versions of the offline code typically require newer versions of the ROOT code. I will try to keep us to a single ROOT version. I anticipate that this will usually be possible (fingers crossed). In any case, it should be mostly transparent to everyone but me.
ROOT has many style parameters which affect the way your plots will look. It turns out that most everyone thinks that the default style is exceedingly ugly. Here's an example:
The style I use is similar to the style commonly used by ROOT's predecessor PAW, and it looks like this:
My style is defined in my logon file. Put it in a directory /home/yourname/macros/, take this .rootrc file and copy it to /home/yourname/.rootrc.
The development release will be updated and rebuilt on pc54 every day at 0215. Frozen releases will be installed and built shortly after the release is announced. On occassion a serious bug or other deficiency is discovered in a frozen release and a fix is backported. In this case the group will be notified and we'll schedule an update.
To start you have to source a setup file. This defines a number of necessary environmental variables, places loon and root in your path, etc. You do:
source /unix/minos/software/setup_minossoft.bash -r [release]
The -r flag and release name is optional. If you don't use a flag you get the development release.
You work with and on the code by setting up a test release . It's just a little area on disk with the following structure:
bin/ doc/ GNUmakefile include/ macros/ man/ tmp/ etc/ lib/ results/
Creation of a test release needs only to be done once and is described in detail here. Very briefly, from your directory of choice (I use my home directory), you do:
newrel -t [base release] [test dir]
where [base release] is either "development" or "RX.YY" (e.g. R1.11 for frozen release 1.11). [test dir] is just the name you want for your test release directory (I usually just choose "test"). To work on a package first you cd to your test release and then you add it like this:
addpkg [package name]
The command takes the most recent version of the package from CVS. If you are working with a frozen release you want to type:
addpkg -n [package name]
The -n flag adds the version of the package in the frozen release to your test release. To build the package you type:
gmake [package name].all
There is a file .base_release in your test release area. The file has a single line with the name of the base release you chose when creating the test release. If you made test release with one release (say development) and then decide to use a different one when sourcing setup_minossoft.bash then you should edit .base_release to hold the name of the new release.
CVS (Concurrent Versions System) is a bit of software used to manage software projects in which multiple people could be editing the same file. The source code is held on a machine at Fermilab (the repository). You checkout a copy of the code to work on it and then check your changes back in to the repository. The CVS software does the book-keeping and notifies you if the changes you made conflict with changes made by someone else. Usage instructions for our repository can be found here .
Mock data challenge ntuples (with strip info) are stored in /unix/minos/mdc/RX.YY . The file naming convention and a bunch of other MDC information are posted on the MDC page. The ntuples are described on the standard ntuples page as well as in the User's Manual.
GMINOS is the Geant3 based "physics" simulation. If you want to simulate particles passing through our detectors then you'll need it. Right now, it isn't installed locally but could be if people wanted it.