Building GENIE on your own

Really? Must you?

This should be a prescription that will work for unpriv'd users. It goes something along the lines of:

Personal UPS area

Pick a location where your own UPS will be it must be on a "app" disk (e.g. /nova/app). You'll need to refer to this again for setting things up in new sessions after it is built ... so remember where you parked

   export MYUPSDIR=/<expt>/app/users/$USER/altups   # where <expt> is "nova" or "uboone" or whatever

Initializing your personal UPS

The ALTUPSSRC is where you can get some stuff that make this easier. You'll only need to know this location during the initial setup of your UPS area


Create your UPS directory, and populate it with the magic files

   mkdir -p $MYUPSDIR
   cp -vax $ALTUPSSRC/.upsfiles $MYUPSDIR 
   cp -vax $ALTUPSSRC/.updfiles $MYUPSDIR 

Initializing GENIE product in your personal UPS

Create the genie product area

   mkdir genie
   cd genie

Here are some helper scripts you'll use for GENIE.

   ln -s /nusoft/app/alt/genie/make_genie_ups_skeleton $MYUPSDIR/genie
   ln -s /nusoft/app/alt/genie/make_genie_nusoft_build $MYUPSDIR/genie

You shouldn't have to make copies unless you plan on editing them. If you're editing them then they need revision and you should let know what and why. They are also available from

Setup the build environment

The easiest way to start is to setup an existing genie release with similar properties relative to what you're attempting to build. This is what will setup the compiler and auxiliary packages (ROOT, LHAPDF, etc) for you.
At a minimum you must have a UPS area defined that has the auxiliary products you desire installed.

   # bootstrap UPS
   source /nusoft/app/alt/setup
   # or perhaps ...
   source /grid/fermiapp/products/uboone/

   # add your UPS installation area to the list

   # get list of existing genie versions
   ups list -aK+ genie

   # setup one of many existing versions (this is an example ... pick appropriately)
   setup genie v3_00_06i -q debug:e19

Create a GENIE version in your UPS area

Create the UPS skeleton, and check out GENIE.

In this example:
  • my3_00_06alt = the UPS version name being created
  • e19:debug = the UPS qualifiers
  • HEAD = check out the master branch (script might not handle branches/tags correctly)

Don't reuse the official UPS version name here, lest confusion reign supreme. Pick something like my3_00_06 or such. Use something that describes what you have (i.e. not "test") to avoid it as it being too ambigious later ... the UPS dependencies will allow you to get those setup correctly, but if you've forgotten what this variant was for (or perhaps from whence you started) then you're on your own. The minimum necessary to get a version started in your UPS area (and check out the code from the repository) is:

   ./make_genie_ups_skeleton --show-config --checkout=yes  my3_00_06alt e19:debug HEAD

Using the --help flag will show you additional options. The 3 non-flag args are version qualifier and svn-tag.

Now it should be a UPS product

Now you should be able to "setup" the UPS product. it isn't built, but all the paths can be/are defined.

   setup genie my3_00_06alt -q e19:debug

Note, you'll need to know what qualifier (-q) as well as the version name that was assigned by the skeleton making process. If you forget you can get hints via:

   ups list -aK+ genie -z $MYUPSDIR
   # or if you know the version name you gave it
   ups list -aK+ genie my3_00_06alt -z $MYUPSDIR

You can see what settting up genie also sets up using:

   ups depend genie my3_00_06alt -q debug:e19

yields a dependency tree such as:
genie my3_00_06alt -f Linux64bit+3.10-2.17 -z <myupsarea> -q debug:e19
|__root v6_18_04d -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:e19
|  |__numpy v1_15_4b -f Linux64bit+3.10-2.17 -z /cvmfs/ -q e19:p372:prof
|  |  |__python v3_7_2 -f Linux64bit+3.10-2.17 -z /cvmfs/
|  |  |  |__sqlite v3_26_00_00 -f Linux64bit+3.10-2.17 -z /cvmfs/
|  |  |__lapack v3_8_0c -f Linux64bit+3.10-2.17 -z /cvmfs/ -q e19:prof
|  |     |__gcc v8_2_0 -f Linux64bit+3.10-2.17 -z /cvmfs/
|  |__fftw v3_3_8a -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug
|  |__gsl v2_5 -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug
|  |__pythia v6_4_28p -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:gcc820
|  |__postgresql v9_6_11b -f Linux64bit+3.10-2.17 -z /cvmfs/ -q p372
|  |__mysql_client v5_5_62 -f Linux64bit+3.10-2.17 -z /cvmfs/ -q e19
|  |__xrootd v4_8_5c -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:e19
|  |__tbb v2019_3 -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:e19
|  |__libxml2 v2_9_9 -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug
|__lhapdf v6_2_3d -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:e19:p372
|__log4cpp v1_1_3b -f Linux64bit+3.10-2.17 -z /cvmfs/ -q debug:e19

Actually building GENIE

Configure and build genie using another of the helper scripts

   # set it up if you haven't already, this defines $GENIE
   cd $GENIE  
   $MYUPSDIR/genie/ -C -m

So that should get you a build. This build script just makes configuring and running make easier and consistent, there's nothing you couldn't do by hand.

Future sessions will require:

   source /nusoft/app/alt/setup  # or other UPS bootstrapping (e.g. uboone example above)

   export MYUPSDIR=/nova/app/users/$USER/altups
   setup genie my3_00_06alt -q debug:e19

to get it setup again.

Future Rebuilds of GENIE and SRT

Now ... there are conflicts between GENIE's build system and the one that is present after setting up the NOvA/LArSoft SRT code. The above assumes you did not setup experiment specific code, especially anything to do with SRT, before you started. This approach is generally the simplest and least likely to cause confusion.

But if it can't be avoided, in any session where you're going to compile GENIE and have setup SRT, do the following:

   cd $GENIE
   srt_setup --unsetup
   gmake [genie-build-target]

You can also use the script to rebuild. The -c flag cleans out everything, -C configures GENIE, and -m it to do the build. Use them in appropriate combinations. If you don't do a clean (and generally you don't need to) then in principle only the things that changed get rebuilt; I've found that if you change only a header sometimes it misses that and doesn't rebuild something that it should. So pay attention to what actually is getting compiled and make into libraries.

The "srt_setup --unsetup" will make that session unable to build NOvA/LArSoft SRT code (and re-doing setup_nova or LArSoft equivalent is probably going to fail). So expect to do some multi-terminal session juggling. I usually have one window open for editing/compiling GENIE and a separate session for my test release work.