Brian Wilt's Daily Log -- Archive, Week Ending Friday, 6/30

Current Log Book

Tracker Geometry

Saturday, July 1, 2006

Tracker Geometry files can be found here.

<ConstantsSection label="pixbarlayer.xml" eval="true">
 <Constant name="LayerDz"           value="55.40*cm"/>
 <Constant name="CoolDz"            value="55.40*cm"/>
 <Constant name="CoolSide"          value="0.40*cm"/>
 <Constant name="CoolThick"         value="0.03*cm"/>
</ConstantsSection>

<ConstantsSection label="pixbarlayer0.xml" eval="true">
 <Constant name="Ladders"           value="18"/>
 <Constant name="CoolDist"          value="4.4429*cm"/>
 <Constant name="CoolWidth"         value="0.3747*cm"/>
</ConstantsSection>

<ConstantsSection label="pixbarlayer1.xml" eval="true">
 <Constant name="Ladders"           value="30"/>
 <Constant name="CoolDist"          value="7.32575*cm"/>
 <Constant name="CoolWidth"         value="0.3432*cm"/>
</ConstantsSection>

<ConstantsSection label="pixbarlayer2.xml" eval="true">
 <Constant name="Ladders"           value="42"/>
 <Constant name="CoolDist"          value="10.1853*cm"/>
 <Constant name="CoolWidth"         value="0.3283*cm"/>
</ConstantsSection>

Things I might need to call:

Geometry/TrackerSimAlgo/src/TrackerGeomBuilderFromGeometricDet::build(const DDCompactView * cpv, const GeometricDet * gd)

Geometry/TrackerBaseAlgo/src/TrackerGeometricDetESModule::produce(const IdealGeometryRecord & iRecord)

I think what I need to do is construct a parameter set (of XML files), read those in and turn them into IdealGeometryRecords with GeometryReaders/XMLIdealGeometryESSource/interface/XMLIdealGeometryESSource(const edm::ParameterSet & p), and feed those IdealGeometryRecords to TrackerGeometricDetESModule to finally produce GeometricDet.

Histograms

Friday, June 30, 2006

Found a useful page for helping with detector geometry here.

Mystery solved: detId = layer*100000 + ring*1000 + module

Getting places with understanding how to convert between local frame of the detector and Geometry/CommonTopologies/interface/Topology.h.

After hours of wrestling, I'm not convinced that I will be able to convert from the local detector frame into the global frame. All of the methods and objects needed to do so are constructed at runtime in the CMSSW framework -- I don't have those objects in the ROOT file. I still want to play with it a little bit, but at this point, things aren't looking that great ...

I spoke to big Phil and did some more thinking -- actually, I think I should be able to just convert the position into the global coordinate system manually without much trouble.

For the pixel detectors in the barrel, the global z will be a simple linear correspondence one of the local variables. The only thing that will be difficult will be x and y coordinates, but those should just correspond to the sin or cos of the other local variable.

For the barrel encaps, z should be constant (just needs to be added) and, if I'm not mistaken, the x and y should be already given to us! Not that much trouble

I'll try to mess around with it a little bit over the weekend, I really want to see some plots and hopefully the deposited charge vs. pseudorapidity of cluster distribution that Bolek mentioned.

First Histograms ... tomorrow

Thursday, June 29, 2006

I didn't write a whole lot today (in fact, it's Friday right now ...) but I think that it's a good thing -- that means that things were going relatively smoothly without hangups. My work:

• Run simulations (simulate + digitize + cluster) on cgate.mit.edu -> ssh -> hibat000(1 - 6).mit.edu
• Analyze with ROOT on X-Win32 on pc2mit.cern.ch (currently working in the /data/02b/pharris/bwilt directory)

Currently, I'm working with 70 pp events (minimum bias). I've got a ROOT file working and I've started generating very basic histograms. Tomorrow, I hope that I'll have my first particles vs. interacting particles vs. hits vs. clusters histograms.

Bolek met with me toward the end of the day, gave me a few tips on what the cosh(eta) cut was in the C. Smith paper. One expects that the primary particles will deposit energy in the silicon detectors E(cosh(eta)). This is due to the geometry of the detector. One can then determine whether particles are primaries or secondaries from that information -- or at least that's the theory. Smith wasn't able to finish the work. I think I should be able to do it with the processType() method in the PSimHit objects.

I spent the better part of the morning trying to tie down what exactly was stored in the ROOT files -- the results of which can be found at here.

Getting Things Under Control

Wednesday, June 28, 2006

Today, I'm going to try to get PYQUEN working, so I can begin generating heavy ion events. I'm going to meet with Christoph and Bolek to make sure I'm on the right track with the physics.

Christoph Paus helped set me up an account on the pcXmit.cern.ch servers, where X = 1, 2, 4. The directories which count:

/home/bwilt - crossmounted, 59GB to play with /data/04a, /02a, /02b, /01a - places to put copious amounts of data, with more space

Thanks, Christoph!

Christoph also suggested that instead of working with CMSSW_0_7_1, I begin working with the more stable (?) v. CMSSW_0_6_1. I'm a little skeptical about moving backward in versions, even if 0_7_1 has its problems ... I feel like it may be best to stick with the newest and just wait until they iron out the new issues.

Christoph also said that it was impossible to do any measurements without using track reconstruction -- the way that the Si strip detectors and pixels are laid out, it's very easy to get multiple counts, etc. He suggested that I implement the RECO stuff to get any meaningful measurements. I will have to speak with Christoph again though -- the C. Smith paper I was working with definitely argues that you can do a single layer analysis.

In order to get a reasonable idea of what he was suggesting, he pointed me toward the work he's been doing on the pcXmit cluster, in the /home/paus/cms/simulate/singleMuons directory (among others). Except for the track reconstruction, our .cfg files were virtually the same (except I was missing the calis and the muon chambers). Little Phil also had a few examples -- /data/04a/philten/code/simulate/cfg.

Apparently, it's hardcoded into IOMC/GeneratorInterface/src/PythiaSource.cc that the events are pp -- I'll have to edit / recompile those files specifically, and SCRAM should be able to sort out that it should use my versions of the new files. To recompile the files, I'll have to use these commands:

scramv1 b
SealPluginRefresh
eval `scramv1 runtime -sh` 

Spoke to Bolek -- he just wants me running pp for now, it seems that the heavy ion stuff is not yet integrated into CMSSW, and there isn't an easy way to do it yet. It's HYDJET that's the correct wrapper, fires Pythia multiple times to simulate ions (I think).

We're going to keep running pp collisions for now; I don't think we're going to be working with heavy ion stuff for a while. I'm going to meet with Bolek later this afternoon to discuss what he's expecting as far as plots. Also, I'm not going to work about the RECO yet -- I think I can construct a few basic plots as far as occupancy, etc.

As far as analysis, I think the most efficient way for me to go will be to do all the ROOT stuff on the lxplus machine. X-Win32 is just too damn slow across the ocean.

Running into issues with the quota on lxplus -- I think there's a 30MB limit. Might need to begin doing analysis on the pcXmit cluster.

Maarten made me another directory to store my data files, /net/t2dsk0001/d00/bwilt. He also suggested that if I need to compile things that I go to the n06 or n07 machines (?).

I set up the clustering (but not the entire RECO ensemble) to make it easier to count the number of hits in the layers of the detector.

I also spoke to Bolek about which particles will interact with the detector -- he said that all charged particles, as well as photons by e+e- production, Compton scattering, etc. (Compton scattering accounts for 30% - 40% of detector activity!) That will make it easier to compare what we "should" see in the detector vs. what we actually see.

Spoke with Phil Ilten about APIs for the Lite framework -- he said there is none and that it's a real pain in the ass to figure out what the methods to call are. He said that the best thing to do is to use tab completion to try to figure out what's in there, sounds like a good call.

Let's See Some Damn Simulations

Tuesday, June 27, 2006

I've been learning Pythia and HepMC so I can have better control over the types of events that I'm generating. I constructed a .cfg file as well as a file specifically for my Pythia config to generate minimum bias events. I set the number of events to 300 (sounds reasonable, right?) and ran the process in the background with the output being piped to a text file. 20 events takes around 20 minutes, so if it scales linearly (a reasonable assumption), this should take around 5 hours. Maybe finished a little after 6 PM? Note from Maarten: I'm not to run anything on cgate that would last longer than 5 minutes or so, and nothing on the other MIT machines for more than an hour, limiting the number of events I can run to around 70.

I'm off to talk to Phil about Pythia a little bit. Cheers!

Running on cgate

Bolek suggested that I move operations to one of the larger, unused servers back at MIT. I'm SSHed into hibat0001, and I'm going to run the same job in the backround so I don't clog the cgate machine.

Particles Looping

I've encountered a problem where a lot of my computing time seems to be spent getting these error messages:

 G4Transportation is killing track that is looping or stuck 
   This track has 102.78714 MeV energy.

Apparently, it's an open issue that's going to be resolved eventually -- it has to do with low energy particles looping over and over again and going nowhere. Something to deal with, I suppose.

Open Issues

Kind of a frustrating day -- lots of open issues to be resolved.

I have a working configuration for running pp min bias events in CMS using the detector geometry and magnetic field as well as the pixels and Si strip detectors (the tracker). To be figured out:

• Configuring Pythia to do HI events instead of pp
  • Turns out this is another package that goes hand in hand with Pythia -- PYQUEN, and not many people have got it running yet.
• Different geometries? What?
  • Will talk to the Phils / Christoph about that.
• Get CMSSW to run faster than 1 evt/sec?
  • Maarten, the Phils, and Christoph all think this is pretty standard
• Get CRAB working -> if so, have to get certificate to run on the GRID?
  • Too much hassle to get on the GRID -- probably using Condor will be enough, said Maarten
• Use ROOT to compute histograms we need

Going on a Libraries Hunt ...

Monday, June 26, 2006

In order to get the lite framework running, I need to track down a whole bunch of libraries and add them to my path. Currently, the list is:

[bwilt@hisrv0001 slc3_ia32_gcc323]$ ldd libFWCoreFWLite.so 
        libReflex.so => not found
        libuuid.so.1 => not found
        libpcre.so.0 => not found
        
        libboost_regex-gcc-mt.so => not found
        libboost_filesystem-gcc-mt.so => not found
        libboost_thread-gcc-mt.so => not found
        libboost_signals-gcc-mt.so => not found
        
        liblcg_SealKernel.so => not found
        liblcg_SealBase.so => not found
        liblcg_PluginManager.so => not found

Getting Boost and SEAL

Trying to get just the precompiled needed libraries from the lxplus machine here at CERN. Think that should resolve most of my issues.

Directories:

/afs/cern.ch/sw/lcg/external/Boost/1.33.1/slc3_ia32_gcc323/lib
/afs/cern.ch/sw/packages/SEAL/SEAL_1_8_1/slc3_ia32_gcc323/lib
/afs/cern.ch/sw/lcg/external/pcre/4.4/slc3_ia32_gcc323/lib
/afs/cern.ch/sw/lcg/external/uuid/1.38/slc3_ia32_gcc323/lib

64 bit vs. 32 bit

Seems there's a problem -- all the libraries and the files for CMSSW are 32 bit Intel, while the machine we're running on is 64 bit AMD.

Someone posted a note on their attempts to compile it for 64 bit machines:

Compiling CMSSW on 64-bit Opterons

I'm going to see if I can compile it in 64 bit overnight so I can get things going ... with the help of that note. Otherwise, I'll probably head back to the 32 bit architecture and start trying to get the gene+simu+digi stuff going again.

And ... it's fixed

Something must have clicked somewhere, because all of the sudden the library is working. Score! I think I'm officially ready to start running gene+simu+digi. I did not compile anything in 64 bit.

-- BrianWilt - 26 Jun 2006