(r26) SWGuideUsersFAQ < CMSPublic

CMSPublic Web>SWGuideUsersFAQ (revision 26) (raw view)~~EditAttachPDF~~
---+!! Questions and answers

%TOC%

#GoAls
This page collects frequently asked questions. Some questions (and answers) concerning common problems have been included here from the Hypernews forums.
You can also submit question through  the [[https://savannah.cern.ch/projects/cmssw/][CMSSW Savannah page]]. Choose
"Submit" from the "Support" menu bar or go directly to [[https://savannah.cern.ch/support/?func=additem&group=cmssw][the Submit page]].

There's also a possibility of having the questions answered by experts in User Support Questions&Answers sessions which can be held on Tuesdays at 9:30 am. in 40-RA-10. The next session will be held when need arises. 


Please check [[http://cmsdoc.cern.ch/cms/cpt/UserSupport/helppage.htm][the existing documentation]], especially
[[WorkBook][the CMSWorkbook]] before adding your question. 

---+++ Naming of the samples in DBS
hn-cms-btag, Pavel Demin, 07 February 2007 

Could someone please explain me what QCD samples are intended to be used for b-tag validation? I can see that currently there are 
two types of samples: 
   * mc-onsel-120_PU_QCD_pt_80_120
   * mc-onsel-120_QCD_pt_80_120
I could not find any description of the samples in DBS.

__Answer:__

  In http://cmsdbs.cern.ch/discovery/ :

   1 Datasets with "onsel" in the name were produced at the request of the HLT group. The corresponding configuration files are in the CMSSW directory =Configuration/CSAProduction/data/=.
   1 Datasets with "physval" in the name were requested by the Physics Validation Group. The .cfg files are in =Configuration/PhysicsValidation/data/=.
   1 Datasets with "relval" in the name were requested by the Software Validation Group. The .cfg files are in =Configuration/ReleaseValidation/data/=.

The =data/= directories all contain a subdirectory =PileUp/=, which contains any .cfg files used for pileup production.

  (In some cases, you may need to check out the CVS HEAD of
Configuration to find them ...)

  So in your example: =mc-onsel-120_PU_QCD_pt_80_120= was produced with
=Configuration/CSA06Production/data/PileUp/CSA06Production/data/PileUp/QCD_pt_80_120_PU_OnSel.cfg= , whilst =mc-onsel-120_QCD_pt_80_120= was produced
with =Configuration/CSA06Production/data/QCD_pt_80_120_OnSel.cfg= . And
our pileup bb and cc dijets are produced with
=PhysicsValidation/data/PileUp/BBbar_pt80to120_LowLumi.cfg= etc. (Ian Tomalin)



---+++ Compatibility between !CMSSW versions
hn-cms-edmFramework,  Pedrame Bargassa, 23 Nov 2006

Is there any known 120pre2 -> 106 incompatibility as well ?

__Answer:__

Yes, you should expect to read the CSA06 MC data only up to CMSSW_1_0_6.

  The general picture is:

| *Type of data* | *produced in* | *run in* | 
| GEN-SIM-DIGI  | 0_8_x-1_0_x |1_0_x (preferably 1_0_6) |
| GEN-SIM-DIGI-RECO |1_0_x   |1_0_x (preferably 1_0_6) |
| GEN-SIM-DIGI      | 1_1_1       |1_1_x |
| GEN-SIM-DIGI-RECO | 1_1_1  |1_1_x |
 
i.e. in general don't expect to read any MC data written in 1_0_x with 
1_1_x and don't expect to read anything written in 1_1_x with 1_2_x. (It 
may run, but produce garbage results, don't waste your time on it.)

 Right now it looks like only GEN-SIM data will be usefully compatible
between 1_1_x and 1_2_x. (Peter Elmer)

NB, this table has been updated in WorkBookWhichRelease

---+++ How to access trajectories and track state on each crossed layers
hn-cms-swDevelopment, Boris Mangano, 18 Oct 2006

In the past, there were many requests to access track's parameters (in
particular the complete !TrajectoryMeasurement) on the surface of each
layer crossed by the track. The trajectory is the object devoted to
collect all the !TrajectoryMeasurements (TM) of the tracks.
Nevertheless !TrajectoryMeasurement objects were not designed to be saved
on disk and, after the final fit of the tracks is done, the
informations about the TMs is discarded. Final Track contain only the
TSOS on the innermost and outermost hits.

__Answer:__

Since last nightly and, hopefully, in120pre2:
Thanks to a very recent update of the Framework, there is the
possibility to define transient-only product which can be put into the
event, even if they are not allowed to be saved on the
root file.

The !RecoTracker/TrackProducer has been accordingly modified to be able
to put the vector of trajectories into the event. The default behavior,
for saving cpu time, is to discard the copy. Nevertheless,the user can
now change the new !TrackProducer's parameter "TrajectoryInEvent" from
'false' to 'true' and the trajectories will be put into the Event during
the execution of the job.

A subsequent module can get them back from the event using the standard
commands:
<verbatim>
Handle<vector<Trajectory> > trajCollectionHandle;
iEvent.getByLabel(param_.getParameter<string>("trajectoryInput"),trajCollectionHandle);
</verbatim>
and then analyze them:
<verbatim>
for(vector<Trajectory>::const_iterator it =
trajCollectionHandle->begin(); it!=trajCollectionHandle->end();it++){
      edm::LogVerbatim("TrajectoryAnalyzer") << "this traj has " <<
         it->foundHits() << " valid hits" ;

vector<TrajectoryMeasurement> tmColl = it->measurements();
.............
</verbatim>
A complete analyzer (=TrajectoryAnalyzer .cc .cfg=) has been committed in
the [[http://cmsdoc.cern.ch/swdev/viewcvs/viewcvs.cgi/CMSSW/RecoTracker/TrackProducer/test/?cvsroot=CMSSW][RecoTracker/TrackProducer/test]] directory. It explains how the value
of the TMs can be accessed.

Last remarks, the trajectories can be accessed after the !TrackProducer
module is executed (with its default !TrajectoryInEvent parameter
changed) or after the Refitter module: this second producer, has also
the new !TrjectoryInEvent parameter.

The important thing is that the 2 modules (!TrackProducer+"user defined
trajectory analyzer" or !TrackRefitter+"user defined..") are run in the
same job. The trajectories are not persistent! (Boris Mangano)

---+++Can't compile an EDAnalyzer created with =mkedanlzr=
hn-cms-swDevelopment, Benedict Huckvale, 10 Oct 2006

I've done nothing more than
<verbatim>
> eval ...
> mkedanlzr WGAnalyser
> rm -r interface/ test/ doc/
</verbatim>
But when I try to build I get this:
<verbatim>
benedict@lxplus061:~/w0/cmssw/CMSSW_1_0_1/src/WGAnalyser > scramv1 b -r
Resetting caches
Parsing BuildFiles
..
 /afs/cern.ch/user/b/benedict/w0/cmssw/CMSSW_1_0_1/tmp/slc3_ia32_gcc323/Makefile:536: *** target file
`src_clean' has both : and :: entries.  Stop.
</verbatim>

__Answer:__

You need to put the generated package into a subsystem (i.e. NOT under
<project>/src/myAnalyzer but <project>/src/subsys/myAnalyzer. (Shaun Ashby)
<br/>
Unfortunately you might also find you need to check out an entirely new CMSSW project area.
Try not to build a wrongly placed package by accident in future! (Benedict Huckvale)

#NoReco
---+++Problems when removing =RECO.cff= from a config file
hn-cms-swDevelopment Taylan Yetkin, Sep 23, 

I would like to remove reconstruction part from the others. When I remove
=include "Configuration/Examples/data/RECO.cff"=
and reconstruction from path
=path p = {smear_and_geant,digitization, reconstruction}=
which are in the exampleRunAll.cfg my naive guess is that it should  
work. However it does not.

__Answer:__

I have found what in =RECO.cff= depends on the !ParticleDataTable: it  
is the =HepMCCandidateProducer= which is then used by different Jet and  
Met algorithms to do their work on the mc particles instead of the  
reconstructed quantities.  So I guess =RECO.cff= is not a completely  
accurate name, it probably should be called =MCRECO.cff= since it is  
designed to work with MC and not actual data.
To solve your problem, I suggest adding

 =include "SimGeneral/HepPDTESSource/data/pdt.cfi"=

to your config file.
(Chris Jones)

#MoreThan1File
---+++ Problems accessing more than one file 

hn-cms-swDevelopment,  Christian Veelken, Wed, 13 Sep 2006


I have two Monte Carlo files that were produced independently and each
contain 500 events. I have written a class derived from EDAnalyzer to make
plots of the file content. When I run over one of the two files at a time,
everything is fine, no problem. But when I run over both MC files in the
same cmsRun job, cmsRun crashes when processing the first event in the
second file.

__Answer:__

My guess is the program crashes in
your EDAnalyzer.  Are you by chance filling your own ROOT file from
within the EDAnalyzer?  If so, then other have found that when the
!PoolSource goes from one input ROOT file to another one their code
crashes.  What was determined is unless you've explicitly openned
your own ROOT file and tied your histogram, ntuples, etc. to your
file, then ROOT will tie those things to the first 'input' file and
when that input file goes away the pointers to your histograms,
ntuples, etc. then point to object that no longer exist (since ROOT
deleted them when the file closed).   So it look like you need to
modify the ROOT calls you are making in your EDAnalyzer.
(Chris Jones)

If Chris' diagnosis is correct (very likely), you can have a
look at
[[http://cmsdoc.cern.ch/swdev/viewcvs/viewcvs.cgi/CMSSW/RecoEcal/EgammaClusterProducers/src/EgammaSimpleAnalyzer.cc?rev=1.6&cvsroot=CMSSW][RecoEcal/EgammaClusterProducers/src/EgammaSimpleAnalyzer.cc]]
where I had a similar problem and is now solved by correctly
binding the histos and trees to my root file w/o interfering
with !PoolSource.
(Shahram Rahatlou)


#FindData
---+++ Where can I find the data?

How do I know what data is available (real data from MTCC or simulation data) and how can I access it?

__Answer:__

See [[WorkBookDataSamples][the Workbook page on data access]].

For the MTCC data (cosmic muons at CMS) see the instructions in [[IGUANA][the IGUANA web page]],
and in particular [[EventDisplayShifterIntroduction#MTCCDataFiles][the data file location]].

The CSA06 samples can be found using [[http://cmslcgco01.cern.ch:8001/][DBS]] tool.

For each release of the !CMSSW packages, a set
of of small event samples are produced which are mainly used to validate the release.
Find the instructions how to access this data in [[RelValSamples][the release validation samples page]].
 
#AddCrossSection
---+++ How to save cross section in the root file?
Sami Lehti, 21 Jul 2006

In an analysis containing several channels (signal+backgr), it is very helpful 
if some normalization constants, like cross section and preselection efficiency, 
can be stored in the root file.
How is this done in practise (a working example would be nice)? How is the 
cross section read from the root file? Can the stored cross section be 
changed by hand afterwards? For example if i have 1M events in root file(s), 
and i get a new cross section from theorists, do i have to rerun the 1M events,
or can i change the cross section value in the root file(s)? If yes, how?

__Answer:__

The mechanism to add a cross-section to the run or job (i.e. one number per run) is not yet ready, it is planned but not yet there (it is foreseen by the end of August, at the earliest)

Meanwhile, you can try the following solution which [[UserSupportNumberToEachEvent][writes a number to each event]].




-- Main.KatiLassilaPerini - 13 Jul 2006