I'll start by trying to follow the instructions at <https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookWriteFrameworkModule>. After the standard start-up stuff, and moving to the src directory, I did:

mkdir Demo
cd Demo
mkedanlzr FirstAnalyzer

This created the file FirstAnalyzer/src/FirstAnalyzer.cc. Note that there is no corresponding
file in the interface directory; it appears that the full class delcaration is done in the .cc
file. You can do that, I guess, although maybe not easily extensible. Should look at coding
rules.

Here is a config file that I was able to put together, starting from the suggested one.

process Demo = {
#keep the logging output to a nice level
include "FWCore/MessageLogger/data/MessageLogger.cfi"

source = PoolSource
{
untracked int32 maxEvents = 1
untracked vstring fileNames = { "file:///opt/cms/Higgs_ZZ.root"}
}
#untracked vstring fileNames =
# {"/store/RelVal/2006/12/16/RelVal120Higgs-ZZ-4Mu/0000/B8EBDCD5-578D-DB11-99D6-0017312B554B.root"}

module demo = FirstAnalyzer { }
module dump = EventContentAnalyzer {}

path p = {demo & dump}
}

Sure enough, it does dump out a ton of stuff. In particular, in the big dump, I get
a line that says

++recoMuons "globalMuons" ""

These are presumably the muons I want. However, before I can get to that, I have to
do the nasty re-reco of 120 data, I believe. Now, everyone else has been doing this
by writing out a file of re-recoed stuff, but I wonder if it can be done on the fly.
Why write out a new file? Maybe I will explore that, although I shouldn't spend too
much time on it.

But first, maybe I'll just work on coding up something that gets the muons and
plots some stuff, just to have that. And hey, by putting in the lines

//Get the muons
Handle<MuonCollection> muons;
iEvent.getByLabel("globalMuons",muons);
std::cout << "Number of muons: " << muons->size() << std::endl;

I can in fact print out the number of muons in each event. Maybe you don't have to
re-reco too much? I'll soon find out (I hope).

Later:

I managed to write out my first histogram! In the delcaration of my class, I put

TFile* hFile;
TH1F* hAllMuonPt;

and then in the analyze method I had

for (MuonCollection::const_iterator imu = muons->begin();
imu != muons->end(); imu++) {
hAllMuonPt->Fill(imu->pt());
}

and I wrote and closed the file at end job, and sure enough, I got a plot
of what I believe is the muon pT. Mind you, I had to add the appropriate
header file includes, and I had to change my BuildFile to have a dependency
on ROOT. But it wasn't too hard.

Then I tried something more interesting. A muon has three different possible
momenta -- the one from the silicon track, the one from the muon system, and
the one from a combined fit of some sort. It would be fun to compare these.
I coded this as follows:

std::cout << "combined pT " << imu->combinedMuon()->pt() <<
" standalone pT " << imu->standAloneMuon()->pt() <<
" track pT " << imu->track()->pt() << std::endl;

Unfortunately, all the pT's in question came back as zero. For all I
know, this is where I have to do the re-reco....

In fact, that turned out to be the case.  Fortunately, Jia Fu had done
the re-reco already and written out the output.  It's in his home
area as rereco.root.  Now I was able to get the following output:

Number of muons: 4
combined pT 41.5383 standalone pT 43.3298 track pT 41.5306
combined pT 60.1341 standalone pT 61.605 track pT 60.0624
combined pT 44.0719 standalone pT 45.0048 track pT 44.0706
combined pT 51.1004 standalone pT 62.9869 track pT 51.0571
Number of muons: 4
combined pT 35.5072 standalone pT 38.4574 track pT 35.6901
combined pT 49.351 standalone pT 42.6805 track pT 49.5279
combined pT 55.7431 standalone pT 56.3819 track pT 55.9071
combined pT 34.4881 standalone pT 34.2533 track pT 34.5378
Number of muons: 2
combined pT 51.9391 standalone pT 28.5807 track pT 52.0099
combined pT 36.3055 standalone pT 30.3299 track pT 36.217
Number of muons: 4
combined pT 31.9863 standalone pT 31.7618 track pT 31.9387
combined pT 31.356 standalone pT 35.2338 track pT 31.359
combined pT 41.5018 standalone pT 45.7689 track pT 41.4562
combined pT 39.7872 standalone pT 42.6279 track pT 40.0371

and so forth.  And here are some resulting plots:

















































































So we can see that the track pT completely dominates the combined fit; there is good correlation
with the standalone muon, but the track is better if you can get it.  There, my first useful plot!

I would like to test out our own T2 site, and run at other sites, by using CRAB.  Now, how hard should this be, really?  Most of the documentation, I should note, makes it sound like the hard thing is taking care of your grid certificate.  Fortunately, I already have one of those.

One problem with CRAB is that apparently right now only SL3 systems can be use to submit the jobs.  What a pain!  It's a known serious problem.  So I moved over to cmsuaf.fnal.gov, which is an SL3 system.  I successfully installed my grid certificate there (see "Grid stuff") and was able to get a proxy, etc.  Actually, let me note right here that for this purpose, the command you must issue is

voms-proxy-init cms

This gives you credentials in the right VO.  I had to enter my passphrase (I'll have to keep remembering that!), and then I was granted a proxy that's good for twelve hours.  And of course I also had to re-establish my analysis code over at cmsuaf; I did that by making a new project, and doing a new mkedanlzr (gosh, that's a terrible name), and then I copied code and config file from gpn-husker before scramv1 build etc.  All seems right with that.

As for CRAB itself -- I would be dead in the water with out Oliver Gutsche, who wrote some excellent step-by-step instructions for how to use CRAB.  Follow that, for sure!  (It's definitely better than what I found on the CRAB documentation pages.)  But it covers many things that I already knew how to do.  On top of that, it also has a lot of instructions on how to install CRAB on your own machine, which isn't necessary on cmsuaf.  (We should make it so on gpn-husker too -- put the CRAB stuff in some reasonable directory.)  So the new stuff is:

Set up the CRAB stuff:

source /uscmst1/prod/grid/CRAB_1_5_1/crab.sh

(Oh look, I copied it from Oliver's twiki page, and I get that lovely formatting!)  You can put in a different version number, of course.  The very first time you do this, you need to set stuff up for BOSS:

$CRABDIR/configureBoss

I stumbled here the first time because I already had a .bossrc area in my home directory.  Make sure that you don't.

Then I needed a crab.cfg file.  This is the part that looks most dangerous, as there are many parameters that need to be set.  To first order, you could probably follow what is done in Oliver's example file.  And you could also get some help from the DBS discovery page.  When you find a dataset, you can click on the "more" link next to the dataset, and get a crab.cfg.  Within that, I had to set my "pset" and "output_file" parameters, and specify "outputdir" and "logdir".  I'll also note that Oliver's version uses the edg scheduler, while DBS pointed me to glitecoll.  I chose the latter, at least for now.  And I'm using the grid middleware sandbox for my output return.  Since I'm only creating a histogram file, this should be quite reasonable.  But if I were outputting any data file at all, I'd probably need to figure out how to use a storage element.

Anyhow, if I actually get all of that right, the next steps should be easy.  First, I create a job:

crab -create

For the particular dataset I chose, and the requirement of 1000 events/job, it made four jobs for submission.  And then I try submitting those jobs:

crab -submit all -c

I think the point of the -c is that you might have created multiple (sets of) CRAB jobs, and this points you to the most recent one.  (The directories from earlier attempts hang around.) 

But this is where I'm currently stuck.  The jobs fail, with a complaint that there's some issue with the CMSSW version I want not being available at the sites.  How could that be?  You would figure that this would be figured out when the job is created.  I'm waiting for more feedback from Oliver on this.

Here are some basics on Grid things. First, I know that my certificate needs to be
in place. I took the .p12 file that I had created when I got my certificate, and
copied it over to gpn-husker. Then, I followed the instructions at
<http://www.doegrids.org/pages/cert-request.html#Globus>. I did have to create
that .globus directory first. I also had to set the permissions right on the
two files that are created:

chmod go-rw /home/bloom/.globus/userkey.pem
chmod 644 /home/bloom/.globus/usercert.pem

Then I was able to do grid-proxy-init and give my password. And that in turn
allowed me to do all the basics given at <http://t2.unl.edu/grid_user>, such
as globusrun and voms-proxy-init (except I used cms rather than gpn) and
globus-job-run. This will all be helpful, I'm sure.

Latest update on how to do things...

To get the CMS stuff, do

source /mnt/nfs04/opt/osg/app/cmssoft/cms/cmsset_default.sh

and for OSG stuff, do

source /opt/osg/osg-080/setup.sh

and for CRAB, do

source /mnt/unl/CRAB/crab.sh

This cmsset_default.sh has some exciting commands in it:

alias cmsenv='eval `scramv1 runtime -sh`'
alias cmsrel='scramv1 project CMSSW'

so when setting up a new environment, you can do

cmsrel <name>

and then to get going for runtime stuff

cd <name>/src
cmsenv

Not so bad, eh?