What Are All the Setups?
|
|
What Are All the Setups?
|
|
| |
| Working groups |
| Blessed plots and figures |
| Approving new results and publications |
| Approval web pages - new results |
| Approval web pages - new publications |
| Mu2e Acronyn Dictionary |
| Fermilab Meeting Rooms |
| Fermilab Service Desk |
| ReadyTalk : Home |
| ReadyTalk : Help |
| ReadyTalk : Toll Free Numbers |
The instructions for running the first examples of the Mu2e software at Fermilab contain the following steps:
setup -B art v1_08_09 -q+e4:+mu2e:+prof setup -B geant4 v4_9_6_p02a -q+e4:+prof setup -B heppdt v3_04_01 -q+e4:+profThe purpose of this web page is to explain each of the lines above that contain the string setup. The short answer is that:
| setup mu2e | Defines all site specific information | |
| setup.sh | Chooses the external products needed for one release of the Mu2e software | |
| setup product_name | The setup command from the UPS/UPD system; this is used within setup.sh. |
If we have done everything correctly, then, except for the locations of input and output files, any mu2e code that runs on the Mu2e machines at Fermilab, should run without any changes at all other Mu2e sites.
The rest of this page will provide some background information and then explain the three meanings of setup in more detail.
The Mu2e software software depends on many external products, including the framework, geant4, root, clhep, boost and many others. On the Mu2e machines at Fermilab, all of these external products live under the directory
/grid/fermiapp/products/mu2e/artexternalswhich we refer to this directory as the products directory or the products area. Get a listing of this directory to see that there is one directory for each external product. Within each product directory there may be multiple versions of the product and each version may be built for several different architectures or with several different debug levels.
To access these files we use software named UPS/UPD, which is, itself, distributed as one of the external products.
The Mu2e web site has instructions for installing the external products on a remote site, such as your desktop, laptop or university-based computer cluster.
Mu2e also has many Mu2e-specific large files that are not really part of any release of the Mu2e software but which are used by the Mu2e software. These files include the magnetic field maps and some input event-data files that are needed for examples. Eventually this will also include such things as the geometry and calibration databases. Many of these files are binary files, which makes them poor candidates for management with cvs. On the machines at Fermilab, these are kept in
/grid/fermiapp/mu2e/DataFilesIn the future we may choose to distribute these files using the external products mechanism. Intially we chose not to do so because the products area was deployed on disk space that was shared between many experiments. Now, however, Mu2e manages its own products area and we may, in the future, choose to distribute these files as products.
When you follow the instructions for installing the external products on your own computer, one of the steps is to copy a subset of the DataFiles area.
The Site Specific Setup File: setupmu2e-art.sh
When you start a Mu2e session the first command is always:
setup mu2eThis command does one thing:
source /grid/fermiapp/products/mu2e/setupmu2e-art.shThe file sourced in this step is called the "site specific setup script". It's job is to create a Mu2e specific working environment that is the same at all Mu2e sites; that is, it creates environment variables and adds elements to paths so that the Mu2e software will run the same way on all Mu2e sites.
You can find more details in the section about the site specific setup script on the Mu2e UPS/UPD web page.
The Release Specific Setup File: Offline/setup.sh
Each version of the Offline code requires a certain version of art, a certain version of geant4, a certain version of heppdt and so on. When you source setup.sh it will use the UPS/UPD setup command to request the correct versions of each required product. The file setup.sh is under revision control using cvs: when a new version of the Offline software requires a new version of the dependent products, setup.sh will be updated to request the correct version. If you read setup.sh, you will see that it does not setup ROOT; this is because setting up art automatically sets up the correct version of ROOT. Similarly for CLHEP, BOOST and several other packages.
If the required versions are not available in the products area, you will get an error message and you will not be able to run the Mu2e code. This should never happen on one of the Fermilab machines; if it does, check the instructions for running the first examples of the Mu2e software at Fermilab to see if you are using the correct site-specific setup file. This error will happen at a remote site when you check out a new version of the Mu2e software that you did not realize requires that you must also update the products area on the remote site. In that case see instructions for installing the external products on your computer.
When you source the site specific setup file it adds the UPS/UPD binary directory to the front of your path. That directory contains a command named setup and it is this setup that is executed when you do, for example:
setup framework v1_1_4This command is described in some detail in the documentation for UPS/UPD and Mu2e.
If you need to use the unix system command with the same name, execute it by giving its full path, usually /usr/bin/setup.
Why didn't we make "source /grid/fermiapp/products/mu2e/setupmu2e-art.sh" the first line in Offline/setup.sh? Wouldn't this shorten the number of steps needed to get started?
The reason is that setupmu2e-art.sh will very likely live at different locations at different Mu2e sites ( such as your laptop or your university based cluster). Will your university site let you make a top level directory named /grid? If we wanted to incorporate this into Offline/setup.sh, then we would need to make Offline/setup.sh aware of all of the different remote sites and the location of the external products on those remote sites. Alternatively we could have asked you to edit setup.sh every time that you check it out.
The solution we chose puts all site specific information into a single place and it puts all version specific information into a different single place.
Using A Base Release of Offline: bin/addlocal.sh
|
|
| Security, Privacy, Legal |
|