Fermilab


MINOS Offline Documentation
[home] [installing MINOS software] [supported platforms] [package links] [mailing list] [HyperNews] [FAQ] [computing help] [MINOS glossary] [archives]

Instructions for Installing the MINOS software with install_minossoft




(note: for a simpler alternative consider msrt.)

The MINOS software requires various external produces. If you have not already installed these, go to the external products page and install the products. You are required to install these products before installing and running the MINOS software.

Index:


Getting the MINOS software

  1. Download the tar file.

    minossoft.tar.gz

    To use a pserver for access to CVS repository, download the tar file

    minossoftpserver.tar.gz

  2. Decide the software location <soft_loc> and cd there
      prompt> cd <soft_loc>
  3. Unwind the tar file
      prompt> gunzip xxx.tar.gz 
      prompt> tar -xvf xxx.tar
    You will get a directory, minossoft, containing the following items, all of which are directories:
      packages 
      releases
      setup
      srt
  4.   prompt> cd minossoft/srt
      prompt> ./install_srt <compiler>

    Set the <compiler> string to EGCS_1_1 if you are using EGCS 1.1.2 (egcs-2.91.66). For GCC 2.95.2 set it to GCC_2_95. See full list of options you may use. The default base release is development. The base release is defined in the file minossoft/srt/srt_envrc. For a frozen release go to Frozen Releases.

  5.   prompt> cd minossoft/setup

Modifying the Setup Scripts

  1. Find out if you have the Fermilab product ups installed.

    1. If you have ups installed, copy the file
        setup_minossoft
      and edit the copy to conform to your site setup.
    2. If you do not have ups then copy the file
        setup_minossoft_template
      and edit the copy to conform to your site setup.

      You will need to change the location for MINOS_SOFT, ROOT_DATA, and INSTALLATION.


  2. All external packages will be installed in INSTALLATION. The default in the setup scripts is to locate ROOT and CERNLIB (required for building Rerootjob) under INSTALLATION.
    You may put these anywhere, but must change the setup script accordingly.

  3. The setup script must point to the location of installed external products.
    1. If you do not have the LABYRINTH code installed then comment out the definition of LABYRINTH_DIR as you cannot build Rerootjob without it. There are separate installation instructions for the LABYRINTH software which is the old Fortran code. If you want to convert your own GMINOS output files to ROOT files then you will need Rerootjob. If you have the code then change the location to conform to your site.

    2. If you want to roll back your development release to some specified date eg. "Mar 28, 2001 12:05pm" then set SRT_ROLLBACK_DATE ="Mar 28, 2001 12:05pm" (see the description of the -D option in the cvs(1) man page for the format of this date string) and SRT_CHECK_RELEASE=version where version could be any name you want to call your release except "development".

Installing the software

  1. Make sure "gmake" is a symlink to GNU make.

  2. Go to where you unwound the MINOS software tar file.
  3.   prompt> cd minossoft
  4.   prompt> source setup/setup_minossoft_<string>

    Note: for a Rollback Release you must

      prompt> source  setup/setup_minossoft_<string> <version>
    where version is the name you want to call it, but don't call it "development"
  5.   prompt> ./setup/install_minossoft -l 
    See below for descriptions of the -l (log) and -c (clean) optional arguments.

    The script:
    • Creates all the packages that are listed in setup/packages-development and fetches them from CVS
    • Initiates a local rebuild of the code
    • Produces a development release that corresponds to the head of the CVS repository
    • By default, logs the output from gmake to your screen

    If you enable the -l option then the output from the various stages of make is placed in files in releases/development/build-logs/$SRT_SUBDIR There is one file for each package/target combination, e.g. CandDigit.lib for the output of the lib stage of CandDigit.

    If you add the -c optional argument, then a make clean will be done before the build. This is sometimes necessary if a file has been cvs removed from the repository.

Frozen Releases

Back to Development Releases

You should already have downloaded and installed the minossoft.tar.gz files and editted the setup_minossoft script as above.
The frozen releases which are available are indicated by the files matching the following pattern:
  minossoft/setup/packages-R<x.y.x>
(The minossoft/ directory is where the tar files were unpacked.) For example, the first frozen release is labeled by R0.0.0. This R<x.y.z> string is used when you source the appropriate setup_minossoft script (described above) and when running the install_minossoft script in the following:
  prompt> cd minossoft/srt 
  prompt> ./install_srt <compiler>
  prompt> cd minossoft 
  prompt> source setup/setup_minossoft_<string> <version> 
  prompt> ./setup/install_minossoft -rl 
  
  • Available Releases from CVS
    View ChangeLog directory to see differences between versions.

    Version R0.6.0 guaranteed to work with ROOT version 3.03/07 10/09/02 New
    Version R0.5.0 guaranteed to work with ROOT version 3.03/07 09/25/02
    Version R0.4.0 guaranteed to work with ROOT version 3.03/08 09/11/02
    Version R0.3.0 guaranteed to work with ROOT version 3.03/02 03/09/02
    Version R0.2.0 guaranteed to work with ROOT version 3.02/02 10/24/01
    Version R0.1.0 guaranteed to work with ROOT version 3.01.06 07/16/01
    Version R0.0.0 guaranteed to work with ROOT version 3.01.05 06/29/01

For instructions on checking out ROOT from CVS for a particular date see README.

There are a few tested *.jcm files as well as instructions in the Validation package that comes with the release which you may find useful in running the code

Release Issues

The purpose of this section is to alert you on minor problems associated with a particular frozen release and solutions to avert this problem
R0.6.0
    When running loon you will encounter this message below when geometry information is being accessed from the database: " =E= Plex 2002/10/15 12:48:13 PlexScintMdlId.cxx,v1.6:274> no match for { Far partial X} used by GetNumStripsInPln =W= Ugli UgliDbiStructHash.cxx,v1.2:149> Hash det Far view _ cover ?unknown breaks hashing scheme". This message is not fatal.
R0.4.0
    A known and unaddressed deficiency of this release is that you can't reliable run "EventSRListModule::Ana". However, we do hope to fix this problem in the shortest possible time.
R0.2.0
  1. When running REROOT files there is an unusual long delay due to the construction of the DBI tables in the MySQL "temp" database based on the geometry found in the REROOT (ie. ADAMO) info. This is the safe thing to do. On the other hand this is often an unnecessary step as the version of the geometry in the "offline" database is sufficient. If you know your file is a standard GMINOS geometry (ie. not strange shifts, odd layouts, truncated supermodules) then you can skip this temp file building by including the line:
    /Root/ProcessLine UgliLoanPool::SetAlwaysUseDbi(true);
    
    in your .jcm file. By default UgliLoanPool tries to use UgliGeometryReroot (temp file building) on reroot files.
  2. You are likely to see these error message when running on Soudan Far detector data.
    no database info for the Far detector (or this VldContext) is available yet
    or NO_FAR_PLEX_DATABASE needs to be switched off in GNUmakefile
    
    This is the ongoing problem that unless fake database entries are made one can not simultaneously use the same Plex compilation for both data and MC. The default is currently to work fine for REROOT files, but give this message ("no database info for ... or NO_FAR_PLEX_DATABASE needs to be switched off in GNUmakefile") when run on real data. Alternatively one can switch one the use of the DBI (via modifying the line in Plex/GNUmakefile, gmake Plex.clean, gmake Plex.all) but then running REROOT jobs see only a plex that's only as up-to-date as the real installation has occurred (and thus fails for planes aren't yet mounted in real life).

Release Testing

Before a release is made the code is vigorously tested. Below is the outline of the testing procedure
The testing involves two stages:
Stage 1
In this stage individual package testing is done. Currently these are the packages that are tested. This list may be expanded in due course.
LeakChecker
Lattice
Navigation
DatabaseInterface
MIDAD
Demo
Plex
Rerootjob
BField
Conventions
Dependency
Persistency
Demux
DatabaseTables
Validation
STAGE2
This is an integration testing stage. Below is an example of the testing procedure carried on frozen release version R0.2.0. The jcm files can be found in "$SRT_DIST/packages/Validation/R<version>"
A. Reroot Monte-Carlo
  1. Reroot MC no demuxing
    prompt> midad -x midadrerootmc.jcm <root_file>
    (View digits in U and V planes)
    
  2. Reroot MC with demuxing
    prompt> midad -x midadrerootmcdemux.jcm < root_file >
    (View digits in U and V planes)
    
  3. Reroot MC with demuxing and Paul's fitter
     prompt> midad -x midadrerootmcdemux_pfit.jcm <root_file>
    (View digits in U and V planes)
    
  4. Reroot MC with demuxing and Roy's fitter
    prompt> midad -x midadrerootmcdemux_rfit.jcm <root_file>
    (View digits and fitted tracks)
    
  5. Reroot MC with demojob on Roy's fitter
    prompt> demojob -x testdemo-1.jcm
    (View cheezy display of digits in U and V views)
    
B. Caldet Data
  1. Run midad on Caldet data (no trackfit or demux)
    prompt> midad -x midaddata.jcm <root_file>
    
    (View and make plots of display of digits in U and V views)
  2. Run midad on Caldet data with Roy's trackfit
    prompt> midad -x midaddata_rfit.jcm <root_file>
    
    (View digits and fitted tracks)
  3. Run demojob on Caldet data with Roy's track fitter
    prompt> demojob -x testtrackfit.jcm <root_file>
    
    (View digits in U and V)
C. Soudan Data  
  1. Run midad on Soudan Far detector data with Roy's trackfitter
    prompt> midad -x midaddata.jcm <root_file>
    (View digits and fitted tracks)
    
  2. Run midad on Soudan Far detector data with Paul's trackfitter
    prompt> midad -x midaddata_pfit.jcm <root>
    (View digits in U and V)
    
  3. Run demojob on Soudan Far detector data with Roy's trackfitter
    prompt> demojob -x testtrackfit.jcm <root_file> 
    (View digits in U and V)
    

Other Issues

If you downloaded the software before 06/28/01 then you need to update your minssoft/setup to checkout the installation scripts.
   prompt> cd minossoft/setup 
   prompt> cvs update 
After installing the software, assuming you want to recompile or clean the code, and in the case of developmental release, do not want to update
  1.    prompt> cd $SRT_PUBLIC_CONTEXT 
  2. Invoke GNU make on:
    • everything
         prompt> gmake all
    • OR only <Package>
         prompt> gmake <Package>.all
  3. Invoke GNU clean on:
    • everything
         prompt> gmake clean 
    • OR only on <Package>
         prompt> gmake <Package>.clean
Note that you could also use the install_minossoft script to do the above. Type "install_minossoft --help" for instructions on how to use it.

Hints
If your install_minossoft script fails to run check that your "SRT" environmental variables are set to their correct locations by typing

   prompt> srt_environment
In particular check to see that SRT_DIST is pointing to the location of your source code. You should see something like this:
   SRT_DIST = "/home/lartey/minossoft" 
   SRT_PUBLIC_CONTEXT = "/home/lartey/minossoft/releases/<version>"


Last Modified: $Date: 2002/10/16 18:25:55 $
Contact: lartey@fnal.gov
Page viewed from http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/soft_ins.html
Fermilab
Security, Privacy, Legal Fermi National Accelerator Laboratory