D-Hadronic Analysis - 9.03 - Details

Check the current release

c3rel 

20080228_FULL

Set the src version 3.0

cd $dhad/src
cvs co -d 3.0 dhad/src

Tag the current src with name V02-01-00

Notice, the python in the src is different than the script.

Sync the script to src.

Make softlink in the local bin.

Difference between 20050417_FULL and 20080228_FULL, ask on HyperNews … sent.

Problem comes from the import DHadTools, move it out and fix later.

Now dhad -h works.

1. Copy the necessary scripts

   cp -r $dhad/src/2.1/gen $dhad/src/3.0
   

2. Edit the submit_mc_jobs.sh

   Use MCGEN: 20080624_MCGEN, MCP2: 20071023_MCP2_A

3. Ask Peter about the new decay fragments file … sent.

   Message from Peter:

   The files in tag_fragments/ show the resonant structure for
   each decay mode.  You should verify each one with the new DECAY.DEC
   (easiest way to do this is with my decparser.py tool - do you know how
   to use this?)  If the new cleog/pass2 releases include the versions of
   the tools that I checked out locally and compiled, you can run
   straight from that release (this means you can remove the lines where
   I cd to one of my directories and run local_setup).
   

   Compare the dec file.

From page: https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/CodeReleases

MCP2 : 20041104_MCP2_A_1

This patched release is a subset of CLEO code to be used in
conjunction with the 20071207_MCGEN or newer MCGEN release to pass2
Monte Carlo data to match the 20041104_P2 release on real data
(data31-37). Hot crystal suppression in C3ccProd is turned on for
MCPASS2. Contains preFSR changes to MCInfo.

Need to document them on the process and post on HN … OK.

Copy the tag-fragments dir:

cp -r /home/ponyisi/cleog/scripts-summerconf/tag_fragments $dhad/src/3.0/gen

Find decparser.py : => https://www.lepp.cornell.edu/~ponyisi/decparser.html

Setup hep.pdt … OK.

Get the decparser.py, place at $dhad/src/3.0/python/.

Test run:

% python decparser.py     
(Cmd) readfile 
(Cmd) dump D0  
[many more decay modes of D0 snipped.  These are the decay modes listed in DECAY.DEC for this particle]

(Cmd) final D+

Verify one mode a time: D0 to Kpi.

In the fragments/D0_to_Kpi file:

Decay myD0
1.000    K- pi+                        PHSP;
Enddecay

Make sure it's using the default DEC file:

 % python decparser.py    
---->  Using default DECAY.DEC: /nfs/cleo3/Offline/rel/20080228_FULL/data/DECAY.DEC

Find the D0 in the default decay file:

(Cmd) readfile 
(Cmd) dump D0
....
0.0382 K- pi+

Then use this

(Cmd) readfile  /home/xs32/work/CLEO/analysis/DHad/src/3.0/gen/tag_fragments/D0_to_Kpi
(Cmd) dump myD0
------------- myD0 -------------
1.0 K- pi+

Ask Peter: the dir of tag fragments and why different with the default one? … sent.

Message from Peter:

The standard DECAY.DEC is in $C3_DATA for each release (not in the
signal MC area).  It looks like you have all the correct directories. 
The mechanism is:

-  the tag fragments decay a D0 or a D0bar to a given final state
-  there are headers that select for whether you want signal ST D0,
D0bar, or DT decays (by using 'myD0' instead of 'D0').

Reply sent.

Message from Peter:

> Hi Peter,
>
> I see. To make it more specific,  if I want to produce the signal MC with the latest MCGEN release, i.e.
>
> c3rel 20080624_MCGEN
>
> I should compare the file:
> /nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC
>
> with each files in :
> /home/ponyisi/cleog/scripts-summerconf/tag_fragments
Up to the overall branching fraction, yes (if the sum of modes in the fragment is less than 1, everything will be rescaled).
>
> However, I'm still puzzled by where in the script did they use the files in the tag_fragments dir? Because I saw the line in simple-cleog-generic-array.sh:
The script doesn't use those files directly.  There is a python script in the parent directory that merges them before a run (gen_decfiles.py I think).

Ask how to get the mode files … sent.

Got reply, need to create my own dec files according to the DECAY.DEC, then do the comparison.

Goal:

dhad gen decfiles single

Manual: for mode 0 - D0 to Kpi

1. Set the cleog env

   c3rel 20080624_MCGEN
   

2. Use decparser to explain K- pi+

   cd /home/xs32/work/CLEO/analysis/DHad/src/3.0/python/
   python decparser.py
   (Cmd) readfile 
   

   (Cmd) readfile /nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC
   

   ['0.3504', 'J/psi', 'pi+', 'pi-', 'VVPIPI_WEIGHTED']
   Traceback (most recent call last):
   File "decparser.py", line 402, in ?
   interactive().cmdloop(
   File "/nfs/cleo3/Offline/other_sources/pkg/python/Python-2.4/install/lib/python2.4/cmd.py", line 142, in cmdloop
   stop = self.onecmd(line)
   File "/nfs/cleo3/Offline/other_sources/pkg/python/Python-2.4/install/lib/python2.4/cmd.py", line 219, in onecmd
   return func(arg)
   File "decparser.py", line 228, in do_readfile
   q.cmdloop()
   File "/nfs/cleo3/Offline/other_sources/pkg/python/Python-2.4/install/lib/python2.4/cmd.py", line 142, in cmdloop
   stop = self.onecmd(line)
   File "/nfs/cleo3/Offline/other_sources/pkg/python/Python-2.4/install/lib/python2.4/cmd.py", line 218, in onecmd
   return self.default(line)
   File "decparser.py", line 75, in default
   self.addline(line)
   File "decparser.py", line 184, in addline
   raise Exception('No decay model specified: %s' % line)
   Exception: No decay model specified: 0.3504     J/psi  pi+ pi-                VVPIPI_WEIGHTED;
   

   Use 2008:

   (Cmd) readfile /nfs/cleo3/Offline/rel/20080228_FULL/data/DECAY.DEC
   

   OK.

   Ask Peter … sent.

3. Use the fragments to assemble the decay file, drop the "3.0" in the VPHOTOVISR

   Only need to change the header file.

   Copy Peter's python file …

    cp ~ponyisi/cleog/scripts-summerconf/gen_decfiles.py $dhad/src/3.0/gen/
   

   Change Dp header manually first. Single_Dpheader

   ./gen_decfiles.py  OK.
   

   Now, change the Single_Dmheader, Single_D0header, Single_D0Bheader

   Assemble … OK.

4. Compare the assembled decay files with 2.1

   Do it later. Generate the decay files first.

5. Generate the workable decay files from 2.1

   dhad gen decfiles single OK.
   

1. CLEOG

   Test one mode … failed.

   In the cleog log file:

   EvtGen:VPHOTOVISR generator expected 
   

   Edit cleog-generic-array.sh … comment out the

   cd /nfs/cor/an1/ponyisi/2007-4/
   . local_setup
   

   For testing, just change the number of jobs to be 1.

   Remove the logs .

   Try again … same error.

   Save the log file => cleog.txt

   Ask Peter … sent.

   Message from Peter:

   Go to your decay file and make sure it says
   
   Decay vpho
   1.000    psi(3770)  gamma     VPHOTOVISR;
   Enddecay
   
   (There shouldn't be anything after VPHOTOVISR.  This was a change in
   EvtGen.)
   

   Find the line:

   Decay vpho
   1.000    psi(3770)  gamma     VPHOTOVISR 3.0;
   Enddecay
   

   Remove the 3.0 … OK.

2. PASS2

   Use "P2RELEASE=20071023_MCP2A"

   Running … done OK.

3. Run all the modes after re-assembled the dec file.

   Test 1 mode again Single_Dm_to_Kspipi0 … Looks OK.

   Clean the log area.

   Now run all the signal MC.

   Edit the submit_mc_jobs.sh:

   FILELISTINGS="single_mode_list"
   

   Change the number of jobs back to 10.

   ./submit_mc_jobs.sh ... OK.
   

   dhad-3.0  check cleog single
   

   Still waiting for some to finish.

   dhad.check.cleog.channel: Single_D0toKpipi0 …

   3

   N/A

   N/A

   dhad.check.cleog.channel: Single_DmtoKspi …

   7

   N/A

   N/A

   dhad.check.cleog.channel: Single_DptoKspipi0 …

   8

   N/A

   N/A

   Fix them later, run the pass2 … sent.

   Fix them …

   dhad-3.0  gen cleog Single_D0_to_Kpipi0 task 3 ... need to check ... 
   

   Need to use previous Pass2.

   Check the fixed cleog.

   dhad-3.0 check cleog Single_D0_to_Kpipi0 
   

   3

   N/A

   N/A

   Not work.

   Check code …

   Edit the fix_mc_job.sh.template with the right MCGEN release and path dir.

   Re-submit.

   dhad-3.0  gen cleog Single_D0_to_Kpipi0 task 3 ... 
   dhad-3.0  gen cleog Single_Dm_to_Kspi task 7 ...
   dhad-3.0  gen cleog Single_Dp_to_Kspipi0 task 8 ...
   

   Finished . Check result.

   Because pass2 has deleted all the cleog files, so, they have to be generated again.

   Clear the dir dat/signal/3.0.

   Start the script:

   dhad-3.0 gen cleog single
   

Use the new generated decfile.

Clean the previous

cd /home/xs32/work/CLEO/analysis/DHad/dat/signal/3.0
rm -rf *

dhad gen cleog single  ... OK.

dhad check cleog single

dhad.check.cleog.channel: Single_DptoKpipi …

6

N/A

N/A

dhad.check.cleog.channel: Single_DptoKspi …

4

N/A

N/A

dhad.check.cleog.channel: Single_DmtoKKpi …

6	N/A	N/A
8	N/A	N/A

Fix these channels.

dhad-3.0 gen cleog Single_Dp_to_Kpipi task 6 ... 
dhad-3.0 gen cleog Single_Dp_to_Kspi task 4 ... 
dhad-3.0 gen cleog Single_Dm_to_KKpi task 6,8 ... 

dhad-3.0 check cleog Single_Dm_to_KKpi ... OK.
dhad-3.0 check cleog Single_Dp_to_Kpipi OK.
dhad-3.0 check cleog Single_Dp_to_Kspi OK.

Use the new generated decfile.

dhad check cleog single

Only two failed:

Single_D0_to_Kpi task 10
Single_Dm_to_Kpipi task 2

Fix them:

dhad gen cleog Single_D0_to_Kpi task 10 ... done. 
dhad gen cleog Single_Dm_to_Kpipi task 2 ... done. 

dhad check cleog Single_D0_to_Kpi  OK.
dhad check cleog Single_Dm_to_Kpipi OK.

dhad-3.0 gen pass2 single 

dhad-3.0 check pass2 single

Got error in the log file:

suez.exe: /nfs/cleo3/Offline/rel/20041104_MCP2/src/include/StorageManagement/SMStorageHelper.h:70: T* SMStorageHelper<T>::deliver(SMSourceStream&, unsigned int) [with T = MCParticle]: Assertion `(iVersion-kFirstVersionNumber) < m_deliverers.size()' failed.

pass2.txt

Ask Peter … sent.

Message from Peter:

I think you need to switch to pass2 release 20041104_MCP2_A_1 .

Found page : https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/CodeReleases

Try it …

dhad-3.0 gen pass2 single

dhad-3.0 check pass2 single OK.

Clear the cleog pds file.

Use the new decay files:

dhad gen pass2 single OK. 

Check the jobs:

dhad check pass2 single

Only the above 2 jobs failed, wait for them to be finished. …

dhad gen pass2 Single_D0_to_Kpi task 10 ... done.
dhad gen pass2 Single_Dm_to_Kpipi task 2 ... done. 

dhad check pass2 Single_D0_to_Kpi OK.
dhad check pass2 Single_Dm_to_Kpipi OK. 

Remove the cleog files.

rm /home/xs32/work/CLEO/analysis/DHad/dat/signal/3.0/cleog_20080624_MCGEN/*.*

dhad-3.0 gen ntuple single

Get error:

suez.exe: /nfs/cleo3/Offline/rel/20050316_FULL/src/include/StorageManagement/SMStorageHelper.h:70: T* SMStorageHelper<T>::deliver(SMSourceStream&, unsigned int) [with T = MCParticle]: Assertion `(iVersion-kFirstVersionNumber) < m_deliverers.size()' failed.

Check the c3rel and see: 20050614_FULL_1

Check the env setup in Peter's code: /nfs/cor/user/ponyisi/daf9/2005-3/local_setup

c3rel 20050316_FULL

Copy the setup file :

cp  /nfs/cor/user/ponyisi/daf9/2005-3/local_setup  $dhad/src/3.0/gen

Edit the setup file: c3rel 20050316_FULL_1 .

Edit the dtuple-generic-array.sh :

. /home/xs32/work/CLEO/analysis/DHad/src/3.0/gen/local_setup

Test on one channel …

dhad-3.0 gen ntuple Single_Dp_to_Kpipi

Found error:

%% ERROR-DynamicLoader.DLSharedObjectHandler: /nfs/cor/user/ponyisi/daf9/2005-3/build/Linux/shlib/MCBeamEnergyFromMCBeamParametersProd.so_20050316_FULL_1:
cannot open shared object file: No such file or directory
%% SYSTEM-Interpreter.TclInterpreter: Tcl_Eval error: ERROR: cannot load /nfs/cor/user/ponyisi/daf9/2005-3/build/Linux/shlib/MCBeamEnergyFromMCBeamParametersProd.

Need to compile the code… done.

1. Log on lnx134

   Change the CLEOSW Release in the setup.sh : 20050316_FULL_1

   dhadrel 3.0 
   

2. Check out code

   cd $dhad/src/3.0
   export CVSROOT=/nfs/cleo3/cvsroot 
   cleo3cvs co -rponyisi060929 HadronicDNtupleProc
   

   Error:

   cvs checkout: cannot find module `HadronicDNtupleProc' - ignored
   

   Can not check out in the dir $dhad/src/3.0, due to the CVS dir.

   Create sub dir

   cd $dhad/src/3.0
   mkdir cleo
   cd cleo
   cleo3cvs co -rponyisi060929 HadronicDNtupleProc OK. 
   

3. Compile

   Change the setup.sh

   USER_SRC=$dhad/src/$rel/cleo
   

   cd $dhad/src/3.0/cleo/
   c3make 
   

   Need : CWNFramework

   export CVSROOT=/nfs/cleo3/cvsroot 
   cleo3cvs co CWNFramework 
   c3make  ... OK.
   

   Check out MCBeamEnergyFromMCBeamParametersProd and MCCCTagger

   cleo3cvs co MCBeamEnergyFromMCBeamParametersProd 
   cleo3cvs co -rv02_00_04  MCCCTagger 
   c3make  ... OK.
   

Change the dtuple-generic-array.sh:

export USER_SRC=/home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo
export USER_SHLIB=$USER_SRC/build/Linux/shlib
c3rel 20050316_FULL_1

Test run …

dhad-3.0 gen ntuple Single_Dp_to_Kpipi

Error message:

suez.exe: /nfs/cleo3/Offline/rel/20050316_FULL/src/include/StorageManagement/SMStorageHelper.h:70: T* SMStorageHelper<T>::deliver(SMSourceStream&, unsigned

Save the log file => dtuple.txt

Ask Peter … sent.

Need to try Release 20080228_FULL …done.

Log on lnx134

Change the CLEOSW release in the setup.sh

dhadrel 3.0

cd /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo
c3make clean
c3make 

Error message:

This library was last compiled using 20050316_FULL_1, \n but you
are now using 20080228_FULL. \n Please do 'c3rel 20050316_FULL_1'
or delete all old \n libraries and the "../lib/.release" file.

Delete the .release file

rm /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/build/Linux/lib/.release

Compile again: => compile.txt

Try another complete new compile:

Relogin to lnx134:

setdhad
dhadrel 3.0
cd /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo
rm -rf build/Linux
c3make 

Compile log => compile.txt

Ask question on HyperNews … sent.

Message from Surik:

I look at your code and I'd like you ask about   operator
overloading (line 266) - where do you define SelectionResult
object? According to your inline function definition (the same
line), it should have boolean type.

Message from Dan:

In SelectionResult operator()( CDPi0& iPi0 )

what's the type of SelectionResult?  I can't find a typedef for that
anywhere.  I'd have expected that to be type DChainBoolean.

Message from Peter:

I think it's the same compiler, but some header files changed and in
particular SelectionResult vanished in the DChain headers.  Try
replacing SelectionResult by bool.  The code in
/nfs/cor/an1/ponyisi/2008-8/HadronicDNtupleProc compiles against
20080228_FULL, you might want to take a look there.

Compare the code … Notice the cvs version has changed from 1.8 to 1.11.

Do cvs update:

cd $dhad/src/3.0/cleo/HadronicDNtupleProc/
cleo3cvs update -A 

rcsmerge warning:

cvs update: conflicts found in Class/HadronicDNtupleProc.cc

Remove files and update again:

cleo3cvs co HadronicDNtupleProc

Compile …OK. => compile.txt

Change the local setup to: 20080228_FULL

Test run …

dhad gen ntuple Single_Dp_to_Kpipi ... OK.

Run whole…

dhad gen ntuple single ... sent. done. 

Check the finish status.

dhad  check ntuple single

Single_D0_to_Kpi didn't run.

Redo this mode again …

dhad gen ntuple Single_D0_to_Kpi

Still the same problem. => dptokpi.txt

Save one OK file => dptokpipi.txt

Ask Peter … sent.

Message from Peter:

You should be careful about using the head - it is optimized for 4170
use, not for 3770, so I don' t know whether there are any incompatible
changes.

As for the deathVtx problem, it happens sometimes (there's probably some
rare GEANT process that messes things up).  If it bothers you,
regenerate the cleog file.

Regenerate the channel.

dhad gen cleog Single_D0_to_Kpi task 1-10 OK. 
dhad check cleog Single_D0_to_Kpi  OK. 

dhad gen pass2 Single_D0_to_Kpi task 1-10 
dhad check pass2 Single_D0_to_Kpi  OK. 

dhad gen ntuple Single_D0_to_Kpi ... done. 
dhad check ntuple Single_D0_to_Kpi  ... Still problem.

See log file => d0tokpi.txt

%% WARNING-MCInfo.MCDecayMode: Potential Energy nonconservation: vpho --> psi(3770) gamma 
%% ERROR-MCInfo.MCDecayMode: Charge NONconservation: Xi_c+ --> 
parent chg,type = 1,125   dau chg = 0
PARTICLE   Xi_c+  125    0    2.4656    1  0.50.000106003      0   2.47   2.47
PDG:   4232/Geant:   -666      P/C:0/0
%% ERROR-MCInfo.MCDecayMode: Charge NONconservation: anti-Xi_c- --> 
parent chg,type = -1,126   dau chg = 0
PARTICLE  anti-Xi_c-  126    0    2.4656   -1  0.50.000106003      0   2.47   2.47
PDG:  -4232/Geant:   -666      P/C:0/0
%% WARNING-Processor.HadronicDNtupleProc:    4  27    D0 ( 0.207683, 0.185618, 0.062497; 1.886564)  0.0  2   2   0 
suez.exe: /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:1367: static int HadronicDNtupleProc::constructMCDmode(const MCParticle&): Assertion `deathVtx != __null' failed.

Ask Peter …

Use the new generated pass2 files.

dhad gen ntuple single  ... 

dhad check ntuple single

Channel	Processed	Stream event
SingleD0toKpi	62732	62702
SingleD0BtoKpi	62732	62702
SingleD0toKpipi0	197247	197217
SingleD0BtoKpipi0	197247	197217
SingleD0toKpipipi	99443	99413
SingleD0BtoKpipipi	99443	99413
SingleDptoKpipi	79959	79929
SingleDmtoKpipi	79959	79929
SingleDptoKpipipi0	73365	73335
SingleDmtoKpipipi0	73365	73335
SingleDptoKspi	79979	79949
SingleDmtoKspi	79979	79949
SingleDptoKspipi0	57156	57126
SingleDmtoKspipi0	57156	57126
SingleDptoKspipipi	39319	39289
SingleDmtoKspipipi	39319	39289
SingleDptoKKpi	20018	19988
SingleDmtoKKpi	20018	19988

Message from Peter:

I do an extra dskim step in the code in ~ponyisi/cleog/scripts-ds-600/.
The driving file is simple-dskim-generic-array.sh.  The tcl file is
~ponyisi/cleog/dskim.tcl.  In fire_up_jobs_new.sh I fix the skim release
to 20060224_FULL_A_3, but this should be changed to whatever the correct
skim release is for version 1 cuts.  Let me know if you have questions.

Copy the sh and tcl file.

cd /home/xs32/work/CLEO/analysis/DHad/src/3.0/gen
cp ~ponyisi/cleog/scripts-ds-600/simple-dskim-generic-array.sh . 
cp ~ponyisi/cleog/scripts-ds-600/fire_up_jobs_new.sh  . 
cp ~ponyisi/cleog/dskim.tcl . 
cp ~ponyisi/cleog/scripts-ds-600/simple-gziplogs-generic-array.sh . 

Find the version 1 cuts release.

In the previous CBX, it mentioned DTag : CBX 04-32(2004)

CLEO-c D Tagging for Summer 2004 Analyses PS.

On page 6, section 4.3:

D skimming was done with a new frozen code release so that things are 
reproducible. It is the Jun 22 release: 20040622_FULL. In particular, 
the TagD*Prod selectors are preserved in this release. 

Ask Peter for confirm. … sent.

Coding for the job submission.

dhad gen dskim Single_Dp_to_Kpipi ... OK.

Backup the previous dtuple:

mv dtuple_20080624_MCGEN_20041104_MCP2_A_1/ dtuple_20080624_MCGEN_20041104_MCP2_A_1_v1

Start Dskim …

dhad gen dskim single

Error:

/nfs/cleo3/Offline/rel/20040622_FULL/bin/Linux/g++/suez: line 296: ulimit: stack size: cannot modify limit: Operation not permitted

Save the log file => dskim.txt

Ask Peter … sent.

Need to test one mode at a time.

Message from Peter:

You're using a release that's so old that my dskim.tcl doesn't work. 
Probably instead of running setup_dtag and dtag_output, you want to run
/nfs/cleo3/Offline/rel/20040622_FULL/src/SuezScripts/DTagScripts/DTagDSkim.tcl
and
/nfs/cleo3/Offline/rel/20040622_FULL/src/SuezScripts/DTagScripts/DTagOut.tcl
or something like that.

Edit the dskim.tcl … OK.

Test for one mode:

dhad gen dskim Single_Dp_to_Kpipi ... stoped.

Problem at

param DTagProd BCM_Cut $env(DSMassWin)

Save the log => dskim.txt

Try "run_file DTagOut.tcl" command… Similar error. => dskim-1.txt

Ask Peter …

Locate the previous stage for processing Dskim.

Start from the src 2.1 dtuple-generic-arrar.sh

HadronicDNtupleProc/Test/loadHadronicDNtupleProc.tcl :

Qestion: where does the "global skim" set?

Check the output from 2.1 … some yes some no. Depend on what?

Read HadronicDNtupleProc/Test/dataselection.tcl : OK. The "skim" is set at here.

Now, it looks I need to start from the src 2.1 and make it work at 3.0.

In src 3.0, check the DTuple code back to previous stage

cd $dhad/src/3.0/cleo/HadronicDNtupleProc/
cleo3cvs update -rponyisi060929 
rm -rf build/Linux/HadronicDNtupleProc
c3make 

Same error as before. Now check with Peter's new code:

/nfs/cor/an1/ponyisi/2008-8/HadronicDNtupleProc 

In Class/HadronicDNtupleProc.cc:

bool operator()( CDPi0& iPi0 )

Setup local cvs … done.

cd $dhad/src/3.0
mkdir -p proc/dntuple
cp cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc proc/dtuple/.
cvs add proc
cvs add proc/dtuple
cvs add proc/dtuple/*
cvs ci -m "add from tag ponyisi060929"

Soft link the HadronicDNtupleProc.cc and compile … => compile.txt

c3make >& $dhad/log/2009/0429/compile.txt

Change the HadronicDNtupleProc.cc :

SelectionResult operator()( CDPi0& iPi0 ) => bool operator()( CDPi0& iPi0 )

Compile. … => compile.txt.1 Error reduced.

Fix the .h file:

cp cleo/HadronicDNtupleProc/HadronicDNtupleProc/HadronicDNtupleProc.h proc/dtuple/.
cvs add proc/dtuple/HadronicDNtupleProc.h 
cvs ci -m "add from tag ponyisi060929" proc/dtuple/HadronicDNtupleProc.h 
cd  cleo/HadronicDNtupleProc/HadronicDNtupleProc/
ln -sf $dhad/src/3.0/proc/dtuple/HadronicDNtupleProc.h .

Change the .h file:

#include "DTag/DTagDecayModes.h"
typedef DTagDecayModes::const_iterator dtdmci ;

Compile … compile.txt.2 didn't help. So change it back.

Continue to change the .cc file:

807   DCReferenceHolder' undeclared

//const STL_VECTOR(DCReferenceHolder<CDCandidate>) & vect = tagDecay.children();
STL_LIST(dchain::ReferenceHolder<CDCandidate>) vect;

Compile … compile.txt.3.

Compare with v1 :

match for `std::list<dchain::ReferenceHolder<CDCandidate>, 
std::allocator<dchain::ReferenceHolder<CDCandidate> > >& [int&]' operator

Use "#include <list>" and compile … compile.txt.4

Compare with v3, stays the same.

Change the whole section of the code based on Peter's code and compile … compile.txt.5

Not work.

Copy both cc and h file from Peter and compile … compile.txt.6

Compiles OK only complains the new DTuple names.

Comment out those names and compile … compile.txt.7

Now, error comes from the missingMass:

HadronicDNtupleProc/Class/HadronicDNtupleProc_missingMass.cc:135: 
syntax error before `operator'

Register the missingMass code to local, link, change and compile … compile.txt.8

No error! Check in local cvs.

Trim the cc file. first version compile. check in local.

Need continue to find the critical part… next.

Compare the HadronicDNtupleProc.cc file local 1.1 and current (1.3 compile version).

Too many changes. Start from 1.1 and nail down the problem.

1. First compile => compile.txt.1
2. Change line 269: bool => compile.txt.2

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:315: 
   no matching function for call to `Parameter<DABoolean>::Parameter()'
   /nfs/cleo3/Offline/rel/20080228_FULL/include/CommandPattern/Parameter.h:89: candidates
   are: Parameter<T>::Parameter(const Parameter<T>&) [with T = DABoolean]
   /nfs/cleo3/Offline/rel/20080228_FULL/include/CommandPattern/Parameter.h:60:     
   Parameter<T>::Parameter(const std::string&, Module*) [with T = : DABoolean]
   /nfs/cleo3/Offline/rel/20080228_FULL/include/CommandPattern/Parameter.h:57:     
   Parameter<T>::Parameter(const std::string&, Module*, const T&) : [with T = DABoolean]
   

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:807: `
   DCReferenceHolder' undeclared (first use this function)
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:807: 
   (Each undeclared identifier is reported only once for each function it appears : in.)
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:807:
   parse error before `>' token
   

3. Change the DCReferenceHolder

   // const STL_VECTOR(DCReferenceHolder<CDCandidate>) & vect = tagDecay.children();
   const STL_VECTOR(dchain::ReferenceHolder<CDCandidate>) & vect = tagDecay.children();
   

   … => compile.txt.3

   Problem 807 fixed.

   315 still there.

   Ask on HN … sent.

   Message from Dan:

   looks like your HadronicDNtupleProc.h and .cc files are out of
   sync.  Your .h file includes these declarations:
   
   Parameter<DABoolean> m_processD0Dp;
   Parameter<DABoolean> m_processDs;
   Parameter<DABoolean> m_doDoubTagChiSq;
   
   but those are not in the initializer list of the HadronicDNtupleProc()
   constructor, hence the error--every declared parameter has to be
   initialized in the constructor initializer list, since Parameter
   doesn't have a default constructor.  I think you somehow picked up a
   version of the header file from a later tag than the .cc file.  Since
   you aren't using those in the .cc file, you can comment them out of
   the header file to fix the compilation problem.
   

   Message from Peter:

   I think 'DABoolean' should be changed to 'bool' in this case.
   

4. Restore to previous .h file. … => compile.txt.4

   Problem 315 fixed.

   Deal with 909:

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:909:
   no matching function for call to `DDoubleTag::cosThetaFit() const'
   /nfs/cleo3/Offline/rel/20080228_FULL/include/DDoubleTag/DDoubleTag.h:194: candidates
   are: double DDoubleTag::cosThetaFit(const MagneticField*, const  LabNet4Momentum*)
   

5. Use the MagneticField

   Need to compare with 1.1

   #include "MagField/MagneticField.h"
   tuple.cosangle[tuple.nddcand] = doubleTag.cosThetaFit(&*magField, &*labMomentum) ;
   tuple.chi2vd[tuple.nddcand] = doubleTag.chi2VertexD(&*magField, &*labMomentum) ;
   tuple.chi2vdb[tuple.nddcand] = doubleTag.chi2VertexDbar(&*magField, &*labMomentum) ;
   tuple.chi2ed[tuple.nddcand] = doubleTag.chi2EnergyD(&*magField, &*labMomentum) ;
   tuple.chi2edb[tuple.nddcand] = doubleTag.chi2EnergyDbar(&*magField, &*labMomentum) ;
   tuple.chi2md[tuple.nddcand] = doubleTag.chi2MassD(&*magField, &*labMomentum) ;
   tuple.chi2mdb[tuple.nddcand] = doubleTag.chi2MassDbar(&*magField, &*labMomentum) ;
   tuple.chi2vddb[tuple.nddcand] = doubleTag.chi2VertexDDbar(&*magField, &*labMomentum) ;
   

   => compile.txt.5

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:924:
   passing `const DDoubleTag' as `this' argument of `double 
   DDoubleTag::cosThetaFit(const MagneticField*, const LabNet4Momentum*)' discards qualifiers
   

   Ask again … sent.

   Message from Dan:

   Your doubleTag variable is a reference to a const object, but the member functions it is calling are not const--so calling those functions is discarding the "const" attribute of the object ("this").  This is why in version 1.39 of HadronicDNtupleProc.cc, the initialization of the doubleTag variable was changed from this:
   
   const DDoubleTag& doubleTag = dynamic_cast< const DDoubleTag& >(( *ttItr ).particle() ) ;
   
   to this:
   
   DDoubleTag doubleTag = ( *ttItr ).particle() ;
   
   which make a non-const copy of the object.  I found this by looking at
   the current version of HadronicDNtupleProc.cc in LXR, here:
   
   http://www.lns.cornell.edu/restricted/webtools/cleo3/source/Offline/src/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc
   
   and then using the "CVS Blame" link to find out when that line was
   changed, and then clicking on the version number in "CVS BLame" to see
   the diffs between 1.38 and 1.39.  These are very handy tools,
   especially since you seem to be redoing a lot of past development.
   

   Message from Jim:

   "discarding a qualifier" means you are asking the compiler
   to ignore the "const" declaration.
   
   class A {
   void f() const;
   void g();
   };
   
   const A* a = new A();
   
   a->f() ; // ok
   a->g(); // will not work because a is "const"
   
   the only way to call g
   is to declare A as
   
   A* a = new A();
   instead of
   const A* a = new A();
   
   I have no clue how DDoubleTag works
   but ... what your code is doing seems
   a bit strange because you are looping
   over a const iterator... and then trying
   to modify something that is const.
   
   hope that helps,
   

6. Remove const DDoubleTag

   //const DDoubleTag& doubleTag = dynamic_cast< const DDoubleTag& >(( *ttItr ).particle() ) ;
   DDoubleTag doubleTag = ( *ttItr ).particle() ;
   

   … => compile.txt.6 No error !

   Check in local to v1.4.

   Now deal with the warnings.

1. Add ~CWNTuple

   In file included from /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/HadronicDNtupleProc/HadronicDTuple.h:38,
   from /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/HadronicDNtupleProc/HadronicDNtupleProc.h:73,
   from /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:163:
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/include/CWNFramework/CWNTuple.h:63: warning: `
   class CWNTuple' has virtual functions but non-virtual destructor
   

   Register CWNTuple.h at local cvs.

   Link to CWNFramework.

   Compile … compile.txt.0

   In file included from /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/Class/CWNTuple.cc:23:
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/CWNFramework/CWNTuple.h:66: warning: `
   class CWNTuple' has virtual functions but non-virtual destructor
   

   Add ~CWNTuple : … compile.txt.1 fixed this warning. Check in.

2. HbookCWNtupler.cc - unsigned int

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/Class/HbookCWNtupler.cc: In
   function `std::string& local_toupper(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/Class/HbookCWNtupler.cc:55: warning: comparison
   between signed and unsigned integer expressions
   

   Register HbookCWNtupler.cc and link. Edit:

     for (int i = 0; i < str.length(); i++) {
    (unsigned int i = 0; i < str.length(); i++) {
   

   Compile … compile.txt.2 OK. Check in .

3. RootCWNtupler.cc - unsigned int

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/Class/RootCWNtupler.cc:46: warning: comparison
   between signed and unsigned integer expressions
   

   Register RootCWNtupler.cc and link, edit:

     for (int i = 0; i < str.length(); i++) {
    (unsigned int i = 0; i < str.length(); i++) {
   

   Compile … compile.txt.3 OK. Check in .

4. Comment out int istat

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/CWNFramework/Class/RootCWNtupler.cc:57: warning: unused
   variable `int istat'
   

   Comment out int istat, compile … compile.txt.4 No warning!

   Check in.

   Cleaned up the build area and compile again for all modules … compile-all.txt

   Still warnings. Compile again … compile.txt.5 No warnings.

5. static_cast<;unsigned int>

   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:
   In member function `virtual ActionBase::ActionResult HadronicDNtupleProc::event(Frame&)':
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:867:
   warning: comparison between signed and unsigned integer expressions
   

   From the tuple_cxxstructure.h, ndcand is int.

   //   assert(tuple.ndcand == footPrintArray.size());
   assert(static_cast<unsigned int>(tuple.ndcand) == footPrintArray.size());
   

   Compile … compile.txt.6 OK for 867.

   Change for rest lines … compile.txt.7 No warnings.

Clean the log dir.

cd $dhad/dat/signal/3.0/log_20080624_MCGEN_20041104_MCP2_A_1
rm dtuple* 
dhad gen ntuple Single_D0_to_Kpi ... Error.

Log file => dtuple.txt

%% ERROR-DynamicLoader.DLSharedObjectHandler: /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/build/Linux/shlib/HadronicDNtupleProc.so_20080228_FULL: undefined symbol: _ZTI8CWNTuple
%% SYSTEM-Interpreter.TclInterpreter: Tcl_Eval error: ERROR: cannot load HadronicDNtupleProc.

Clean the build dir and compile again. … compile-all.txt

Noticed warning…

Try again … same error.

dhad gen ntuple Single_D0_to_Kpi 

Ask on HN … sent.

Message from Surik:

You can use c++filt to demangle C++ symbols.

Message from Laura:

Maybe you already know this, but the c++filt command can help you understand undefined symbols, e.g.

[ljf26@lnx6143 ~]$ c++filt _ZTI8CWNTuple
typeinfo for CWNTuple

Sometimes this makes it easier to figure out what's going on, and sometimes not.

Need to fix the warnings … done.

Try again … still same problem.

dhad gen ntuple Single_D0_to_Kpi 

Reply to Surik and Larua … sent.

Message from Dan:

It means the typeinfo and vtable for the type haven't been
instantiated.  There's a set of heuristics the compiler uses for where
it instantiates those, so it doesn't create lots and lots of copies of
the typeinfo and vtable.  One of the first heuristics is that if the
class has a virtual destructor that isn't inline, the typeinfo and
vtable are instantiated at the point where the virtual destructor is
defined.  In your case, it looks like you added a virtual destructor
declaration to the class (which is generally good form), but didn't
implement it, so the typeinfo and vtable aren't getting instantiated.

So, you need to implement the destructor for the CWNTuple class to the
get typeinfo and vtable implemented.

Edit the source file not using virtual… compile.txt.8

Leave the warning there and try again for the run :

dhad gen ntuple Single_D0_to_Kpi ... same problem. 

Compare with Peter's working version

/nfs/cor/an1/ponyisi/2008-8/

Take off the virtual function. => compile.txt.1

dhad gen ntuple Single_D0_to_Kpi ... running OK!

Kill job and delete the log file … OK.

1. HadronicDNtupleProc

   cd $dhad/src/3.0/cleo/HadronicDNtupleProc/HadronicDNtupleProc
   mv HadronicDNtupleProc.h bak.h
   cleo3cvs update
   diff HadronicDNtupleProc.h bak.h
   

   No change.

   cd ../Class
   mv HadronicDNtupleProc_missingMass.cc bak.h
   mv HadronicDNtupleProc.cc HadronicDNtupleProc_bak.cc
   cleo3cvs update
   diff HadronicDNtupleProc_missingMass.cc  bak.h
   

   Have change. Leave it there.

   Delete from local cvs: HadronicDNtupleProc.h

2. CWNFramework

   Delete from local cvs:

   • [X] CWNTuple.h (no change)
   • [X] HbookCWNtupler.cc (only unsigned int for warning)
   • [X] RootCWNtupler.cc (only unsigned int for warning)

   Compiele and test again before delete … compile.txt.2 Just warning.

   dhad gen ntuple Single_D0_to_Kpi ... OK.
   

   Kill job and log file.

   Delet file from CVS.

dhad gen ntuple single  ... done.

dhad check ntuple single

Channel	Processed	Stream event
SingleD0toKpi	62732	62702
SingleD0BtoKpi	62732	62702
SingleD0toKpipi0	197247	197217
SingleD0BtoKpipi0	197247	197217
SingleD0toKpipipi	99443	99413
SingleD0BtoKpipipi	99443	99413
SingleDptoKpipi	79959	79929
SingleDmtoKpipi	79959	79929
SingleDptoKpipipi0	73365	73335
SingleDmtoKpipipi0	73365	73335
SingleDptoKspi	79979	79949
SingleDmtoKspi	79979	79949
SingleDptoKspipi0	57156	57126
SingleDmtoKspipi0	57156	57126
SingleDptoKspipipi	39319	39289
SingleDmtoKspipipi	39319	39289
SingleDptoKKpi	20018	19988
SingleDmtoKKpi	20018	19988

Make the softlink for dat signal.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular

dhad yield regular -t s -m 1 OK.

dhad yield regular -t s  ... done.

Use new results.

dhad yield regular -t s ... done.

Use on the minimal changed results.

dhad yield regular -t s ... done.

dhad fit regular -t s -m 1

Error:

dlopen error: /home/xs32/work/CLEO/analysis/DHad/lib/RooFitCore/libRooFitCore.so: undefined symbol: _ZN6TGraph8InitExpoEii
Load Error: Failed to load Dynamic link library /home/xs32/work/CLEO/analysis/DHad/lib/RooFitCore/libRooFitCore.so
DHadFit:: Failed to load RooFit lib.

Try c3rel 20050417_FULL

c3rel 20050417_FULL

Same problem.

Try a complete new log in with 20050417 full.

No ROOT module. Have to use the 20080228 full.

Compile the RooFit core under new release …

cd $src
cp -r $dhad/src/1.0/RooFit* .
cd RooFitCore 
gmake -f GNUmakefile.standalone
cp $dhad/src/3.0/cleo/RooFitCore/tmp/libRooFitCore.so $dhad/lib/RooFitCore/libRooFitCore_3_0.so

RooFitCore OK.

Need file: /home/xs32/work/CLEO/analysis/DHad/9.03/tab/line_shapeparas.txt

Copy from previous version:

cp $dhad/7.06/tab/line_shape_paras.txt $dhad/9.03/tab/

segmentation violation => fiterr.txt

Compile the RooFitModels …

cd $dhad/src/3.0/cleo/RooFitModels
gmake -f GNUmakefile.standalone
cp tmp/libRooFitModels.so $dhad/lib/RooFitModels/libRooFitModels_3_0.so

Fitting is OK now.

Run qsub …

dhad fit regular -t s -m 1 --qsub

log-2009-03-30 15:32:31 running OK.

Test the mode 0

dhad fit regular -t s -m 0  ...running OK.

Delete the previous job.

Run job for allmodes:

dhad fit regular -t s --qsub

log-2009-03-30 15:51:23

Run job for new signal.

dhad fit regular -t s --qsub  ... done.

log-2009-04-08 15:55:10

Run job for minimal change sample

dhad fit regular -t s --qsub  ... done. 

log-2009-05-07 13:45:08

ln -s $dhad/7.06/dat/fit/regular $dhad/9.03/dat/fit/7.06
dhad table compare yields signal 7.06

In DHadTable.py

tab.column_append_by_diff_sigma_pct

In tabletools.py

cell = self.cell_diff_sigma_pct(cell_a, cell_b, rnd, factor)

def cell_diff_sigma_pct(self, a, b, rnd, factor=100):
    c  = self.cell_subtract(a, b)
    c  = self.cell_divide(c, b, err_type= 'Sgma')
    c  = self.cell_trim(c, err_type= 'Sgma', rnd=rnd, factor=factor)
    return c

      Sgma:

                      a_val
             c_val = -------
                      b_val


                      a_val
             c_err = -------
                      b_err

Compare a +/- σ_a and b +/- σ_b:

Diff = (a-b)/b with a/σ_b σ

Change it to the general form: change the cell diff function.

Correction, the default error in the subtraction cell_subtract:

            add1  = a_err**2
            add2  = b_err**2
            c_err = math.sqrt(add1+add2)

Trace the original CBX calculation. Label: tab:ddbarmcdoubletagyields

Found in the DHadAttr.py: cbx_double_generic_eff.

In the DHadTable.py function.

Divide with "Efcy".

?? So, if just compare the yields, the procedure should be correct?? -> Ask.

Now compare the efficiencies.

Add columns for efficiency

Check the NTuple info …

https://www.lepp.cornell.edu/~ponyisi/private/DNT_doc.html

mce [0]

Look up archive: http://www.lepp.cornell.edu/~xs32/private/DHad/archives/2006/03.html

c3python DHad.py -a 1 -t s --tag s

DHad.py version 1.21

Evt = DHad_Sig(dt_type, tag, mode, sign)
Evt.drawTree("ecm-mce[0]")
Evt.eps2png()

Make the plot

dhad plot E_psi3770 regular signal Single_D0_to_Kpi

Notice the beam energy shift.

Ask question on HN … sent.

Message from Surik:

    The MCGEN releases that you are using have differences, and
 it is possible that existing differences are affecting to your result.
 If 20050214_MCGEN  release is based on PostPASS2-C_5
 constants ( constant version 5), then 20080624_MCGEN
 release is based on PostPASS2-C_6 (constant version 6).  In the
 cleog stage, we are using   BeamEnergyShift, and here,
http://www.lepp.cornell.edu/restricted/webtools/cleo3/source/
Offline/doc/web/Constants/ConstantsFreeze_CLEO-c.html#mctags
 I found the following description, what could clarify things:
 ...

 Freeze constants for post-Pass2 processing of the dataset

Tag: PostPASS2-C_6
After the completion of Pass2, the first set of post-Pass2 constants
 is frozen from default (types MagFudge, BeamEnergyShift until
 data38, and SuperConductingQuadFieldMap). This is used to

   * generate runinfo data (typically by Brian Heltsley) and
   * for cleog (the generation stage of CLEO MC)  -
      BeamEnergyShift only
      Note: Since the BeamEnergyShift values are usually not
      known at the beginning of Pass2 processing (until data38),
      Pass2 is done with zero BeamEnergyShift (until data38).
      For consistency, it is preferable to stick to this rule for all
      datasets until data38, although the effect is believed to be
      small enough to be ignored for most analysis work except
      precision mass measurements. In parallel, MC generation
      should use correct (nonzero) BeamEnergyShift, to model the
      real world better. However, Pass2 (_5) for some run ranges
      has been done with nonzero BeamEnergyShift (which were
      known from a previous round of Pass2): 200978 - 202522
      (data31 and part of data32), 202670 - 203111, 203429 -
      203634, and from data39 onwards. Until April, 2005, all MC
      had been generated and Pass2'ed with the same
      BeamEnergyShift constants that were used in Pass2 (zero or
      nonzero).

      In April, 2005, this was corrected by modifying
      setup_constants_command.tcl to retrieve BeamEnergyShift
      from the PostPASS2-C_5 tag - for cleog only (MCPass2
      continues to get BeamEnergyShift from the PASS2-C_6
      tag).

      Starting in January, 2006, the final BeamEnergyShift
      constants are determined before the start of Pass2, and
      added to the PASS2-C_6 tag.

---------------------- end of quotation --------------------------------

 I believe that the issue is not BeamEnergyShift constants
 themselves - the way we are handling them. Maybe expert
 could elaborate why final result, the beam energy,  come out
 differently (about 0.5MeV shift) for the  20050214_MCGEN and
 20080624_MCGEN  releases (I assume that you are using
 the same correct mcpass2 release, which is dataset dependent).

 According to CLEO MC sample generation policy, you should use
 the latest 20080624_MCGEN release in the cleog stage. For the
 mcpass2 stage, you could check MCstatus web page:
https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/CLEOcMCstatus

    It would be great if you could present additional information.  I am
 suggesting the following: make a table, where the first column
 represent dataset , if discrepancy that you have discovered is true
 fore entire dataset,  or run number, and  other columns represent
 MC samples and data beam energy (at this point two MC
 beam energy values and  data).  If you create this kind of table our
 discussion could be more productive.

Make the table for the energy distribution … OK.

Find the run number when generating signal MC … in gen/./src/3.0.2/gen/runlist

2*Beam Energy - MC1: 20050214 MC2: 20080624

Run (data)	MC1[GeV]	MC2[GeV]	Data[GeV]	MC2-MC1[MeV]	MC1-DT[keV]	MC2-DT[keV]
201911 (31)	3.7728419	3.7728419	3.7728500	0.	-8.1	-8.1
202919 (32)	3.7741241	3.7741241	3.7741298	0.	-5.7	-5.7
205456 (35)	3.7726001	3.7746400	3.7726099	2.0399	-9.8	2030.1
206080 (35)	3.7729997	3.7744598	3.7730100	1.4601	-10.3	1449.8
206937 (36)	3.7732658	3.7745857	3.7732698	1.3199	-4.	1315.9
207636 (36)	3.7732539	3.7744936	3.7732498	1.2397	4.1	1243.8
208217 (37)	3.7735219	3.7735419	3.7735300	0.02	-8.1	11.9
208729 (37)	3.7735357	3.7737960	3.7735300	0.2603	5.7	266.
209275 (37)	3.7735180	3.7739577	3.7735099	0.4397	8.1	447.8
209750 (37)	3.7736640	3.7741041	3.7736699	0.4401	-5.9	434.2

Post on HN … sent.

Message from Surik:

   Thank for producing the table, which is very useful,however,
( MC1 -Data) as well as (MC2-Data) columns look strange
(maybe you could check ).  I'd like to ask you for one more thing,
 could you use  20080215_MCGEN release, which is used to
 regenerate 20xLumi Generic sample, instead of 20080624_MCGEN
 release, which is used to regenerate Psi(2S)  Generic sample.

 Please use 20080215_MCGEN for your test, but the same time,
 I need to understand why we see this kind of strange MCGEN
 release dependent behavior.

Open another task.

Message from Steve:

I'm not sure why they would be different. I assume one should be able to
look at the beam energy data files
when the 2 different CLEO environments are set up? Can we confirm that
these numbers you see
correspond to the numbers in the official beam energy files?

I don't know where the "official" Beam Energy files are stored, so I
can't be of much help in doing
the comparison...

Message from David: link

Dear All
  On the suspicion that the beam energy shifts might have
something to do with the problems Xin is having, I looked up the beam
energy shift constants on the web page
https://www.lepp.cornell.edu/restricted/CLEO/CLEO3/soft/Constants/.
After printing out the validity table, I extracted the version numbers
of the beam energy shift constants appropriate to the runs in Xin's
table.  The constants version number is the last column in the table below.
  It is important to note that the data35- beam shifts had not
yet been determined by 20050214.
  Anyhow, the next to last column gives the beam energy shift
(doubled to match CM energy).  Except for a difference in sign
convention, the shifts track exactly.  I presume therefore that 20050214
was not employing the beam energy shifts, but that 20080624 was.  In
general, we DO want to apply the beam energy shifts, which use the known
D mass and observed D momenta to fine tune the reported CESR energy on
an absolute scale.
  This table is adapted from Xin's.

Run (data)	MC1[GeV]	MC2[GeV]	Data[GeV]	MC2-MC1[MeV]	Ecm shift [MeV]	Consts vsn
201911 (31)	3.7728419	3.7728419	3.7728500	0.	0.80	14
202919 (32)	3.7741241	3.7741241	3.7741298	0.	-0.80	16
205456 (35)	3.7726001	3.7746400	3.7726099	2.0399	-2.04	27
206080 (35)	3.7729997	3.7744598	3.7730100	1.4601	-1.46	32
206937 (36)	3.7732658	3.7745857	3.7732698	1.3199	-1.32	36
207636 (36)	3.7732539	3.7744936	3.7732498	1.2397	-1.24	37
208217 (37)	3.7735219	3.7735419	3.7735300	0.02	-0.02	43
208729 (37)	3.7735357	3.7737960	3.7735300	0.2603	-0.26	45
209275 (37)	3.7735180	3.7739577	3.7735099	0.4397	-0.44	46
209750 (37)	3.7736640	3.7741041	3.7736699	0.4401	-0.44	47

1. Test on one mode:

   dhad gen cleog Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN
   

   dhad check cleog Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN... OK for task 1.
   

   dhad gen pass2 Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN
   

   dhad check pass2 Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN ... OK
   

   dhad gen ntuple Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN done.
   

   Only one run. Need to run for 10 jobs

2. Full run on one mode

   dhad gen cleog Single_Dp_to_Kspipipi task 2-10 --version_cleog 20080215_MCGEN
   

   dhad check cleog Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN ... OK
   

   dhad gen pass2 Single_Dp_to_Kspipipi task 2-10 --version_cleog 20080215_MCGEN 
   dhad check  pass2 Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN ... OK.
   

   dhad gen ntuple Single_Dp_to_Kspipipi --version_cleog 20080215_MCGEN 
   

3. Make the table

   MC1: 20050214_MCGEN MC2: 20080624_MCGEN MC3: 20080215_MCGEN

   Run (data)	Data[GeV]	MC1[GeV]	MC2[GeV]	MC3[GeV]	MC1-DT[keV]	MC2-DT	MC3-DT
   201911 (31)	3.7728500	3.7728419	3.7728419	3.7728419	-8.1	-8.1	-8.1
   202919 (32)	3.7741298	3.7741241	3.7741241	3.7741241	-5.7	-5.7	-5.7
   205456 (35)	3.7726099	3.7726001	3.7746400	3.7746400	-9.8	2030.1	2030.1
   206080 (35)	3.7730100	3.7729997	3.7744598	3.7744598	-10.3	1449.8	1449.8
   206937 (36)	3.7732698	3.7732658	3.7745857	3.7745857	-4.	1315.9	1315.9
   207636 (36)	3.7732498	3.7732539	3.7744936	3.7744936	4.1	1243.8	1243.8
   208217 (37)	3.7735300	3.7735219	3.7735419	3.7735419	-8.1	11.9	11.9
   208729 (37)	3.7735300	3.7735357	3.7737960	3.7737960	5.7	266.	266.
   209275 (37)	3.7735099	3.7735180	3.7739577	3.7739577	8.1	447.8	447.8
   209750 (37)	3.7736699	3.7736640	3.7741041	3.7741041	-5.9	434.2	434.2

   Respond to Surik on HN … sent.

1. Set src branch 3.0.2

   cd $dhad/src
   cp -r 3.0 3.0.2 
   cd 3.0.2/python
   cvs tag V03-00-02
   cvs tag -b -r V03-00-02 B03-00-02 
   cvs up -r B03-00-02
   setdhad 3.0.2
   

2. Trace the location of the Generic DEC file

   Input from Anders, copy the entire $C3_DATA.

   cp -r /nfs/cleo3/Offline/rel/20080228_FULL/data /home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo 
   

   Change the setup file.

   cvs tag -b B03-00-02
   cvs up -r B03-00-02
   

   Add :

   export C3_DATA=${USER_SRC}/data
   

3. Use the old DECAY file

   cd /home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo/data
   cp DECAY.DEC DECAY.DEC.default
   cp /nfs/cleo3/Offline/rel/20050316_FULL/data/DECAY.DEC DECAY.DEC.2005
   

   Difference: 306 places!

   In the old one (20050316_FULL):

   Decay vpho
   1.000                   JSCONT 0;
   Enddecay
   

   In the new one (20080228_FULL):

   Decay vpho
   1.000  psi(2S)          VPHOTOV;
   Enddecay
   

   What should be changed …?

   Go ahead to generate one mode …

   ln -sf DECAY.DEC.2005 DECAY.DEC
   dhad gen cleog Single_Dp_to_Kspipipi
   

   Notice the env in the log file:

   /nfs/cleo3/Offline/rel/20080624_MCGEN/data
   

   Need to change the env in the cleog-generic-array.sh. … OK.

   Re-submit job … OK.

   Fix the duplicated lines … OK.

   Run on other modes:

   dhad gen cleog Single_Dp_to_KKpi ... OK. 
   dhad gen cleog Single_D0_to_Kpi ... OK. 
   

   Delte jobs and clean the log dir.

4. Submit CLEOG jobs

   dhad gen cleog single ... done. 
   dhad check cleog single ... 
   

   Failed job:

   Single_D0_to_Kpi  4
   

   Fix

   dhad gen cleog Single_D0_to_Kpi task 4 ... done.  
   dhad check cleog Single_D0_to_Kpi  ... OK.
   

5. Submit Pass2 jobs

   dhad gen pass2 single ... 
   qmod -cj 1271433
   qmod -cj 1271435
   

   dhad check pass2 single ... OK.
   

6. Submit Ntuple jobs

   dhad gen ntuple single ... 
   

   Error:

   suez.exe:
   /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:1196:
   static int HadronicDNtupleProc::constructMCDmode(const
   MCParticle&): Assertion `deathVtx != __null' failed.
   

   Need to re-compile …

    sl lc
   setdhad 3.0.2
   cd $dhad/src/3.0.2/cleo
   c3make  ... done.
   

   Clean the dtuple log file.

   Test one mode:

   dhad gen ntuple Single_Dp_to_KKpi
   

   Same error.

   Check the dtuple script… change:

   cd /home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo/
   

   dhad gen ntuple Single_Dp_to_KKpi
   

   Still the same error.

   Check local_setup&hellip; change

   export USER_SRC=/home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo
   

   Clean log file.

   dhad gen ntuple Single_Dp_to_KKpi
   

   Loading the right code, but same error:

   suez.exe:
   /home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo/HadronicDNtupleProc/Class/HadronicDNtupleProc.cc:1196:
   static int HadronicDNtupleProc::constructMCDmode(const MCParticle&):
   Assertion `deathVtx != __null' failed.
   

   Try another mode:

   dhad gen ntuple Single_D0_to_Kpi ... same error.
   

   Archive the log

   dtuple-Single_D0toKpi.txt, dtuple-Single_DptoKKpi.txt

   A last check before asking.

   Compare the default 2005 DEC file with the fixed version.

   Uncomment the line 516-8.

        0.000002     phi pi0                SVS;
        0.000005     phi K_S0               SSD_CP dm 0.0 1.0 minusTwoBeta 1.0 0.0 -1.0 0.0;
        0.000005     phi K_L0               SSD_CP dm 0.0 1.0 minusTwoBeta 1.0 0.0 1.0 0.0;
   

   Try one mode:

   dhad gen cleog Single_Dp_to_Kspipipi
   

   Got error:

   EvtGen:Two matching decays with same parent in decay table
   EvtGen:Please fix that
   EvtGen:Parent anti-B0
   EvtGen:Daughter phi
   EvtGen:Daughter pi0
   

   Change it back.

   Ask on DHad HN … sent.

   Help from Lawrence:

   1. Add debug info in HadronicDNtupleProc.cc (1201)

       if (deathVtx == NULL) {
        cout << mcpart << endl;
      }
      

      From the output:

      24 616 gammaFSR (-0.000007,-0.000007,-0.000007; 0.000016)  0.0 20   5   0 
      

   2. Add debug info in the MCDecayTree (950)

      cout << *decaytree << endl;
      

      Output:

      debug.txt

      So, the problem should be that the "gammaFSR" has never been simulated in the CLEOG.

   3. Search for the gammaFSR in the DEC file

      Found the missing lines in the new dec file:

      Decay gammaFSR
      1.0000 gamma                                         PHSP;
      Enddecay
      

   Now re-do the process for generating the MC.

   Comment out the debug info.

1. Add the gammaFSR in the bottom of the DEC file.

   Decay gammaFSR
   1.0000 gamma                                         PHSP;
   Enddecay
   

2. Clean the output area.

   cd /home/xs32/work/CLEO/analysis/DHad/dat/signal/3.0.2
   rm -r *
   

3. Submit CLEOG jobs

   dhad gen cleog Single_Dp_to_Kspipipi ... OK.
   dhad gen cleog single ... done. 
   dhad check cleog single ... 
   

   dhad gen cleog Single_D0B_to_Kpi task 6 
   dhad gen cleog Single_D0B_to_Kpipipi task 3
   dhad gen cleog Single_Dp_to_Kpipi task 3
   dhad gen cleog Single_Dp_to_Kspi task 2
   dhad gen cleog Single_Dp_to_KKpi task 8 
   

   dhad check cleog Single_D0B_to_Kpi ... OK.
   dhad check cleog Single_D0B_to_Kpipipi ... OK. 
   dhad check cleog Single_Dp_to_Kpipi ... OK.
   dhad check cleog Single_Dp_to_Kspi ... OK.
   dhad check cleog Single_Dp_to_KKpi ... OK.
   

4. Submit Pass2 Jobs

   dhad gen pass2 single ... done.
   

   dhad check pass2 single ... OK.
   

5. Submit Ntuple Jobs.

   dhad gen ntuple single ... done.
   

6. Extract yields

   cd $dhad/9.03/dat/signal
   ln -s $dhad/dat/signal/3.0.2/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular2
   

   dhad yield regular2 -t s -m 1 ... OK.
   

   dhad yield regular2 -t s  ... done.
   

7. DHad Fits

   dhad fit regular2 -t s -m 0 ... OK
   

   dlopen error:
   /home/xs32/work/CLEO/analysis/DHad/lib/RooFitCore/libRooFitCore.so:
   undefined symbol: _ZN6TGraph8 InitExpoEii Load Error: Failed to
   load Dynamic link library
   /home/xs32/work/CLEO/analysis/DHad/lib/RooFitCore/libRooFitCore.so
   

   Fix the load lib in DHadFit.py … OK.

   dhad fit regular2 -t s -m 0 --qsub
   

   log-2009-06-03 14:27:14

   dhad fit regular2 -t s -m 1 --qsub
   

   log-2009-06-03 14:27:32

   dhad fit regular2 -t s -m 3 --qsub
   

   log-2009-06-03 14:27:48

   dhad fit regular2 -t s -m 200 --qsub
   

   log-2009-06-03 14:28:14

   dhad fit regular2 -t s -m 201 --qsub
   

   log-2009-06-03 14:28:25

   dhad fit regular2 -t s -m 202 --qsub
   

   log-2009-06-03 14:28:34

   dhad fit regular2 -t s -m 203 --qsub
   

   log-2009-06-03 14:28:45

   dhad fit regular2 -t s -m 204 --qsub
   

   log-2009-06-03 14:28:53

   dhad fit regular2 -t s -m 205 --qsub
   

   log-2009-06-03 14:29:02

8. Compare with yields in 7.06

   dhad table compare yields signal 7.06 regular2
   

9. Compare yields regular and regular2

   dhad table compare yields signal regular regular2
   

10. Post on HN … sent.

    Dear all,
    
     I followed Ander's suggestion by using the DECAY.DEC
     file from 20050316_FULL in the new release 20080228_FULL. After
     fix the gammaFSR problem in CLEOG under Lawrence's help, I made
     a comparison of the yields with our previous result. Now,
     having the same DECAY file both on the signal side and untagged
     side, the only difference is the software release. In this
     table, "7.06" means our published 281/pb result, "regular2"
     means this new version. 
    
     http://www.lepp.cornell.edu/~xs32/private/DHad/rel-9.03#tab-compare_yields_signal_7.06_regular2
    
     I think the difference is caused by the energy shift as
     mentioned by David Kreinick's posting on HyperNews:
     
     https://hypernews.lepp.cornell.edu/HyperNews/get/Prelimbugs/74/1/1/1/2/1.html
    
    
     Xin
    

dhad gen ntuple data 31 
dhad gen ntuple data 32 
dhad gen ntuple data 33 

dhad gen ntuple data 35 
dhad gen ntuple data 36 
dhad gen ntuple data 37 

dhad check ntuple data 31,32,33,35,36,37

Dataset	Processed	Stream event
data31	290177	289173
data32	1279173	1277977
data33	178556	177902
data35	720374	718982
data36	1028011	1026028
data37	1659158	1656553

Extract the beam energy … done. Same.

1. Extract yields.

   cd $dhad/9.03/dat/
   mkdir data
   cd data
   ln -s $dhad/dat/data/3.0 regular
   dhad yield regular -t d -m 0 ... OK.
   dhad yield regular -t d --qsub 
   

   log-2009-06-08 09:59:24

2. Do the fit

   dhad fit regular -t d -m 0 --qsub
   

   log-2009-06-08 15:30:50

   dhad fit regular -t d -m 1 --qsub
   

   log-2009-06-08 15:31:18

   dhad fit regular -t d -m 3 --qsub
   

   log-2009-06-08 15:31:53

   dhad fit regular -t d -m 200 --qsub
   

   log-2009-06-08 15:32:24

   dhad fit regular -t d -m 201 --qsub
   

   log-2009-06-08 15:32:40

   dhad fit regular -t d -m 202 --qsub
   

   log-2009-06-08 15:32:55

   dhad fit regular -t d -m 203 --qsub
   

   log-2009-06-08 15:33:20

   dhad fit regular -t d -m 204 --qsub
   

   log-2009-06-08 15:33:30

   dhad fit regular -t d -m 205 --qsub
   

   log-2009-06-08 15:33:41

3. Make plots

   dhad-3.0 plot data single regular 
   

4. Compare yields

   dhad-3.0 table compare yields data 7.06  regular
   

Edit $dhad/src/3.0/HadronicDNtupleProc/Test/dataselection.tcl to include a section for 'data43_{dskimevtstore'}. Use Dskim 20070822

https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/FederationDetails

if { ( $env(INPUTDATA) == "data43_dskim_evtstore" ) } {
    set skim yes
    set preliminaryPass2 no
    set millionMC no
    set mc no
    set use_setup_analysis yes
    module sel EventStoreModule
    eventstore in 20070822 dtag all dataset data43
}

dhad gen ntuple data 43 

Error:

Suez.dataselection...> eventstore in 20070822 dtag all dataset data43
Suez.dataselection...> }
 %% SYSTEM-Module: added command "eventstore" from EventStoreModule
 %% ERROR-EventStoreModuleBase.EventStoreCommandBase: Problems doing query 
problem communicating with server : 502

Ask on HN bugs fix … sent.

Message from Surik:

 There was power outage on Sunday and computer group recovers
 all system, however, could be some system still offline. Maybe it
 could be useful to submit service request by providing additional
 details.

 If above error message happened on Sunday, could you resubmit
 your job(s) before submitting service request .

Resubmit jobs.

dhad gen ntuple data 43 

Same error.

Submit service request.

Restored.

Resubmit jobs.

rm $dhad/dat/data/3.0/dtuple-data43.txt
dhad gen ntuple data 43 

Other errors => data43.txt

Wait for another hour …

rm $dhad/dat/data/3.0/dtuple-data43.txt
dhad gen ntuple data 43 

Same errors => data43.txt

Problem events:

>> Mon Jun 15 11:33:11 2009 Run:  221242 Event:    6470 Stop: event << 
%% NOTICE-Processor.HadronicDNtupleProc: To many missing masses
... 

And the program stopped at here.

Check the 7.06 case for the stopper … confirmed the same event.

Need to solve the problem in 7.06 first.

Message from Peter:

So I have found the following:

   
* To set the constants tag, execute "setup_constants cleoc <processing
type> <tag>" before running cleog or mcpass2.  The processing type is
either cleog, mcpass2, or pass2, and the tag is the version number.  The
file $C3_SCRIPTS/cleog_command.tcl includes the version used for cleog
in that particular release; this is in the variable
"dataset_mcconstants_script", and is the line {30 {cleoc <tag>}}.

* EvtGen code changes between old and new MCGEN: the D+ -> K0B pi+ pi0
and D0 -> K0B pi+ pi- Dalitz structures changed.

Find the line in genmc_anders.tcl:

   #load in the cleog command
   run_file $env(C3_SCRIPTS)/cleog_command.tcl

In old CLEOG ( 20050525_MCGEN), the version is:

    {1 {cleo3 3}}
    {30 {cleoc 5}}

In the new CLEOG (20080624_MCGEN), the version is:

    {1 {cleo3 3}}
    {30 {cleoc 6}}

Need to put line in genmc_anders.tcl :

setup_constants cleoc cleog 5

Ask Peter to confirm to place the command before that … OK.

Submit CLEOG jobs for one mode:

dhad-3.0.2 gen cleog Single_Dp_to_Kspipipi --set 'setup_constants cleoc cleog 5'

Can not find the log file, need to create 3.0.3:

Leave out the cleo dir to be independent.

cd $dhad/src
cvs co -d 3.0.3 dhad/src

Merge with B03-00-02:

cvs up -j B03-00-02

Resolve conflicts.

cvs ci -m "merge with B03-00-02"

Merge with 3.0

cvs up -j B03-00 

Resolve conflicts.

cvs ci -m "merge with B03-00"

Create the cleo src :

cd $dhad/src
mkdir cleo
cd cleo
cp -r ../3.0.2/cleo/ 3.0

Create the gen dir inside cleo

mkdir gen
cp  -r ../3.0.2/gen gen/3.0.2

Create the gen dir for 3.0.3:

cp  -r 3.0.2 3.0.3

Edit the genmc_anders.tcl, add the set line.

setup_constants cleoc cleog 5

Change the cleog-generic-array.sh:

export C3_DATA=/home/xs32/work/CLEO/analysis/DHad/src/cleo/3.0/data

Submit CLEOG jobs for one mode:

setdhad 3.0.3
dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi

Found exception in the log file => cleog.txt

Check the file size:

210K Jun 12 17:24 cleog_Single_Dp_to_Kspipipi_1.pds

Post on DHad HN … sent.

Re-post on Bugs HN … sent.

Suggestion from Peter on DHad meeting: use the old producer for constants, or hack the new one.

Understand the error in log file => cleog.txt:

ERROR-JobControl.ProcessingPaths: Starting from  file: "/home/xs32/work/CLEO/analysis/DHad/dat/signal/
3.0.3/cleog_20080624_MCGEN/cleog_Single_Dp_to_Kspipipi_1.pds" parameter: "" we called extract for
[1] type "RawEventData" usage "" production ""
[2] type "RawTrigger" usage "" production "" <== exception occured
caught a DAException:
"No trigmcccatoc2 Record found in the Frame"
; will continue...

Not readable in the pds file.

Trace on which module it's using…

Look for "DAException" in LXR …

Found the ProcessingPath code:

http://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/JobControl/Class/ProcessingPaths.cc

From this Readme file, ask Valentine for more info … sent.

Talk with Valentien, need to know which producer to produce this data, or have to change the constants.

Help from Anders and Dan:

param MCRawDataProd useTileSharing false

Clean the log file.

rm  $dhad/dat/signal/3.0.3/log_20080624_MCGEN_20041104_MCP2_A_1/cleog-Single_Dp_to_Kspipipi-1.txt

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi

Terminated => cleog.txt

%% SYSTEM-JobControl.InteractCommand: no module MCRawDataProd

Try to put after the cleog_command.tcl. …

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi

Same problem, 210K pds, and log file => cleog.txt

Try it again by removing the pds file.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi 

Same error.

Move the param line before the proc sel.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi 

Same problem.

Suggestion from Dan:

Check out the MCRawData module and place the debug info.

Look up the release version for the MCRawData package.

/nfs/cleo3/Offline/rel/20080624_MCGEN/pkg_versions

Find line with MCRawData module:

MCRawData   MonteCarlo   v07_08_00   proc

Check out the code into different dir (suggestion by Valentin) …

cd $dhad/src/cleo/3.0.3
export CVSROOT=/nfs/cleo3/cvsroot
cleo3cvs co -r v07_08_00  MCRawData

Edit the local_setup file.

. local_setup
c3make 

Put print statement …

In the MCRawTriggerProxy.cc, line 2859:

cout << "xs32>>> m_useNewTOC  =  " << m_useNewTOC << endl;

Test for 10 events.

Edit the cleog-generic-array.sh for local env.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi --set tag_numbers=10 

Log file => cleog.txt.1

Print lines before and after the call updateTOC, MCRawTriggerProxy.cc line 2780.

Comment out line 392:

// bind(&MCRawTriggerProxy::updateTOC2,       TrigStream::kTrigMCCCATOC2);

Test for 10 events … => cleog.txt.2

Test for one mode in one task …

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi
dhad-3.0.3 check cleog Single_Dp_to_Kspipipi

OK. Ready for all modes.

dhad-3.0.3 gen cleog single

qmod -c 1291189    

dhad-3.0.3 check cleog single

dhad.check.cleog.channel: Single_DptoKpipi task 5 -> just started one.

Single_DmtoKspipipi : task 1 -> has problem.

dhad-3.0.3 gen cleog Single_Dm_to_Kspipipi task 1

dhad-3.0.3 check cleog Single_Dp_to_Kpipi OK.
dhad-3.0.3 check cleog Single_Dm_to_Kspipipi OK.

dhad-3.0.3 gen pass2 Single_Dp_to_Kspipipi task 1 ... OK.
dhad-3.0.3 gen pass2 single
dhad-3.0.3 check pass2 single ... OK.

Run on Dntuple.

Edit the dtuple-generic-array.sh.

cd /home/xs32/work/CLEO/analysis/DHad/src/cleo/3.0

dhad-3.0.3 gen ntuple single
dhad-3.0.3 check ntuple single OK.

Extract yield.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.3/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular3

dhad-3.0.3 yield regular3 -t s -m 1 ... OK. 
dhad-3.0.3 yield regular3 -t s --qsub ... OK.

log-2009-06-22 11:36:13

Fit.

dhad-3.0.3 fit regular3 -t s -m 1 … OK.

• dhad-3.0.3 fit regular3 -t s -m 0 –qsub log-2009-06-22 11:54:23
• dhad-3.0.3 fit regular3 -t s -m 1 –qsub log-2009-06-22 11:55:18
• dhad-3.0.3 fit regular3 -t s -m 3 –qsub log-2009-06-22 11:55:19
• dhad-3.0.3 fit regular3 -t s -m 200 –qsub log-2009-06-22 11:55:20
• dhad-3.0.3 fit regular3 -t s -m 201 –qsub log-2009-06-22 11:55:22
• dhad-3.0.3 fit regular3 -t s -m 202 –qsub log-2009-06-22 11:55:23
• dhad-3.0.3 fit regular3 -t s -m 203 –qsub log-2009-06-22 11:55:24
• dhad-3.0.3 fit regular3 -t s -m 204 –qsub log-2009-06-22 11:55:25 -> dhad-3.0.3 not found.
  • dhad-3.0.3 fit regular3 -t s -m 204 –qsub log-2009-06-22 11:58:22
• dhad-3.0.3 fit regular3 -t s -m 205 –qsub log-2009-06-22 11:55:26

Make the compare yields talbe. Still the same problem.

dhad-3.0.3 plot E_cm regular3 signal Single_D0_to_Kpi

Compare with the regular:

The energy dose not change.

Compare with the 7.06:

The energy changed.

So, the constants may still be using the new one. …???

    Suez.cleog_command...> {1 {cleo3 3}}
    Suez.cleog_command...> {30 {cleoc 6}}

Still using the new constants!

Test for 10 events.

Save the old log: cleog-1.txt

Edit cleog-generic-array.sh.

#export NUMEVT=`cat $SCRIPTDIR/tag_numbers/$1`
export NUMEVT=10
#export C3_DATA=/home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo/data

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1 

Error => cleog-2.txt

Edit the local_setup file about the cleo dir.

Clear the log dir for Kspipip task 1

Re-try .

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1 

Still the new constants.

Suez.cleog_command...> {1 {cleo3 3}}
Suez.cleog_command...> {30 {cleoc 6}} <== should be 5

Check the genmc_anders.tcl : the setup command may not work.

Get a local copy of the tcl file.

cp  $C3_SCRIPTS/cleog_command.tcl /home/xs32/work/CLEO/analysis/DHad/src/3.0.3/gen/

Edit the cleog_command.tcl :

{30 {cleoc 5}}

Edit the genmc_anders.tcl:

run_file $env(SCRIPTDIR)/cleog_command.tcl

Remove the old log.

Test … OK.

Clear the old log for pass2.

dhad-3.0.3 gen pass2 Single_Dp_to_Kspipipi task 1 OK.

Clear the ntuple log.

dhad-3.0.3 gen ntuple Single_Dp_to_Kspipipi

/nfs/sge/root/default/spool/lnx189/job_scripts/1345263: line 23:
cd: /home/xs32/work/CLEO/analysis/DHad/src/cleo/3.0: No such file
or directory

Edit the dtuple-generic-array.sh.

cd /home/xs32/work/CLEO/analysis/DHad/src/3.0/cleo

Remove the other pds files.

Try again … done.

Check the size of the ntuple. 35K.

Check the beam energy:

dhad-3.0.3 plot E_cm regular3 signal Single_Dp_to_Kspipipi

Need to do the one mode with normal events.

Clear the dat/signal/3.0.3 dir … done.

Edit cleog-generic-array.sh.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1-10
dhad-3.0.3 check cleog Single_Dp_to_Kspipipi OK.

dhad-3.0.3 gen pass2 Single_Dp_to_Kspipipi task 1-10
dhad-3.0.3 check pass2 Single_Dp_to_Kspipipi OK.

dhad-3.0.3 gen ntuple Single_Dp_to_Kspipipi 
dhad-3.0.3 check ntuple Single_Dp_to_Kspipipi OK.

Update plot:

dhad-3.0.3 plot E_cm regular3 signal Single_Dp_to_Kspipipi

Compare with the 7.06:

dhad-3.0.3 plot E_cm 7.06/regular3 signal Single_Dp_to_Kspipipi

Still different! ???

Re-run the job for one mode.

Clear the dat/signal/3.0.3 dir … done.

Try 10 event. Edit cleog-generic-array.sh.

dhad-3.0.3 gen cleog Single_D0_to_Kpi task 2

In the log cleog.txt:

Suez.cleog_command...> {30 {cleoc 5}}

It is using the old constants.

Run for one full modes.

dhad-3.0.3 gen cleog Single_D0_to_Kpi task 1-10 ... OK.
dhad-3.0.3 check cleog Single_D0_to_Kpi OK.

dhad-3.0.3 gen pass2 Single_D0_to_Kpi task 1-10 ... OK.
dhad-3.0.3 check pass2 Single_D0_to_Kpi OK.

dhad-3.0.3 gen ntuple Single_D0_to_Kpi ... OK.

Link to regular3.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.3/dtuple_20080624_MCGEN_20041104_MCP2_A_1 regular3

Make Ecm plot:

dhad-3.0.3 plot E_cm regular3 signal Single_D0_to_Kpi

Compare with the regular:

The energy dose not change.

Compare with the 7.06:

The energy changed.

Check the other log files.

Suez.cleog_command...> variable dataset_mcconstants_script {
Suez.cleog_command...> {1 {cleo3 3}}
Suez.cleog_command...> {30 {cleoc 5}}
Suez.cleog_command...> }

Compare with the regular:

Suez.cleog_command...> variable dataset_mcconstants_script {
Suez.cleog_command...> {1 {cleo3 3}}
Suez.cleog_command...> {30 {cleoc 6}}
Suez.cleog_command...> }

It is using the old constants.

In cleog_command.tcl:

::proc setup_mcconstants {runNumber dataSet} {
    global env
    variable setup_constants_called
    variable dataset_mcconstants_script
    
    #find the appropriate constant script to call
    set constants_args ""
    foreach entry $dataset_mcconstants_script {
  set presentDataSet [lindex $entry 0]
  if { $dataSet == $presentDataSet } {
      set constants_args [lindex $entry 1]
      break
  }
  if {$dataSet > $presentDataSet} {
      set constants_args [lindex $entry 1]
  } else {
      break;
  }
    }
    if {$constants_args == ""} {
  error "can not find appropriate mc constants script for data set $dataSet"
    }
    eval "::suez::setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"
}

Post question … link.

    I have been trying to load an old version (20050214) of cleoc
    constants in a newer release (20080624) . The major difference of these two
    releases is that the beam energy is changed, as clarified in this
    link:

    https://hypernews.lepp.cornell.edu/HyperNews/get/Prelimbugs/74/1/1/1/2/1.html
    
    To use the old constants, I copied the cleog_command.tcl from the
    new release to my local area and changed the variable
    "dataset_mcconstants_script" to match the old release number, namely:

    variable dataset_mcconstants_script {
    {1 {cleo3 3}}
    {30 {cleoc 5}}  <== the new version is 6.

    When I ran CLEOG, I could see the change in the log file. For
    example, this log is using the old constants (cleoc 5):

    http://www.lepp.cornell.edu/~xs32/private/DHad/log/2009/1012/cleog-3.0.3.txt
    
    And this one is using the new constants (cleoc 6):

    http://www.lepp.cornell.edu/~xs32/private/DHad/log/2009/1012/cleog-3.0.txt

    The distribution of the center of mass energy should be changed,
    but the result is not. 

    New constants:

    http://www.lepp.cornell.edu/~xs32/private/DHad/9.03/fig/regular3/E_cm_regular3_signal_Single_D0_to_Kpi.png
    
    Old constants:

    http://www.lepp.cornell.edu/~xs32/private/DHad/9.03/fig/regular/E_cm_regular_signal_Single_D0_to_Kpi.png

    Are there any other way to test that I'm using the old constants in addition of the cleog log file? 

Reply from David:

I don't know if you still care, but if you leave Suez at report level
DEBUG through the begin run sequence, the version numbers of all
constants used are printed out. Then a diff between two log files will
show you what changed.

https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/CleoSuezManual

Suez>  report help
Suez> report level DEBUG

Add line in the genmc_anderc.tcl:

report level DEBUG

Try 10 event. Edit cleog-generic-array.sh.

setdhad 3.0.3
rm -rf  $dhad/dat/signal/3.0.3/*
dhad-3.0.3 gen cleog Single_D0_to_Kpi task 2

Save the log cleog.txt

 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.16
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.0004 GeV
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.88706, spread = 0.0015, min=3.76352, max=3.78473

Try another 10 event, but with new constants in cleog_command.tcl …

variable dataset_mcconstants_script {
    {1 {cleo3 3}}
    {30 {cleoc 5}} <== change to 6

dhad-3.0.3 gen cleog Single_D0_to_Kpi task 2

Save the log cleog.txt.2

 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.16
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.0004 GeV
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.88706, spread = 0.0015, min=3.76352, max=3.78473

Paste the diff … 2 lines done.

Respond to David on HN …

setdhad 2.1
cd dat/signal/2.1/log_c_0525_photosnew_p2_1104
mv cleog-Single_D0_to_Kpi-2.txt  cleog-Single_D0_to_Kpi-2.txt.bak

Add line in the genmc_anderc.tcl:

report level DEBUG

Run 10 events: (Edit cleog-generic-array.sh)

dhad-2.1 gen cleog Single_D0_to_Kpi task 2

Save the log file cleog.txt.

Look for the constants version.

%% DEBUG-ConstantsPhase2Delivery.CP2SourceBinder: fdbName /nfs/cleo3/constants/db/Codi Tag PASS2-C_5
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.16
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.0004 GeV
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.89, spread = 0.0015, min=3.76, max=3.78

Compare the three tests, they have the same DBBeamEnergyShift (1.16) and DBBeamEnergySpread (1.11).

But the MCSymmetricBeamProd.MCBeamParametersProxy are different between 7.06 and 9.03:

Test	beam energy	spread	min	max
7.06	1.89	0.0015	3.76	3.78
9.03	1.88706	0.0015	3.76352	3.78473

Need to check the MCSymmetricBeamProd code.

DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.0004 GeV

Look up in the source code BeamEnergyProxy.cc:

Look up source code MCBeamParametersProxy.cc:

159    // -------------- beam energy and energy spread ----------------
160    // mean energy for each beam
161 
162    FAItem< BeamEnergy >                                iBeamEnergy;
163    extract( iRecord.frame().record(Stream::kStartRun), iBeamEnergy );
164 
165    const double beamEnergy ( iBeamEnergy->value() ) ;

Send email to Anders … done.

Reply from Anders:

if I understand you correctly you are saying that the constants (or constant versions) are
the same, but that the code has changed? If so can you use the cvs annotate feature to
figure out who changed the code?

Look up the producer for the beamEnergy.

Ask on CLEOG HN reply DLK and cc to Lawrence … sent.

Reply from Anders:

did you look at a distribution of events? I presume that this is the
sampled beam energy and it will be different from event to event.    

Look at other tasks …

Task	Run	beam energy - 7.06	9.03 (3.0)
1	201911	1.89	1.89
2	202919	1.89	1.89
3	205456	1.89	1.89
4	206080	1.89	1.89
5	206937	1.89	1.89
6	207636	1.89	1.89
7	208217	1.89	1.89
8	208729	1.89	1.89
9	209275	1.89	1.89
10	209750	1.89	1.89

Need to trace the beam energy in the full process… stalled.

Ask Anders, cc to Brian … sent.

Reply from Brian:

  I think BeamEnergy comes from

https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/CesrBeamEnergyProd/Class/BeamEnergyProxy.cc#155

This extracts CesrBeamEnergy from the startrun record

https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/CesrBeamEnergyProd/Class/BeamEnergyProxy.cc#136

and then if the flag is selected, corrects it here:

https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/CesrBeamEnergyProd/Class/BeamEnergyProxy.cc#142


All this is in the producer CesrBeamEnergyProd.

Ask for "startrun record" … sent.

Reply from Brian:

 The startrun record is more of a concept than a place. It comes after
a begin run but before the first event, but doesn't have to be located
in the event file (although it usually is). information "in" a record
is not necessarily, well, "in" it.  There can be other sources of
information in the startrun record, and in this case CesrBeamEnergy
comes from RunStatistics, the constants db that is written online,
which I am pretty sure is a different db than the one we generally use
offline.  CerBeamEnergy is meant to be the value that CESR gave us
based on their magnet settings.

But the beam energy is the same for each run…

Follow up from Anders:

in the end the beam energy (and 3-momentum) will be given to the
initial particle, the VPHO. You probably have this in your ntuple so
that you would not actually need to print it out.    

In the ntuple, mce [0].

Need to restore the regular3 files.

Clear the dat/signal/3.0.3 dir … done.

Edit cleog-generic-array.sh. to test 10 events.

Remove the debug level in the tcl.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1

Still has the debug level. Edited the wrong (2.1) version.

Change the 3.0.3 version tcl. Which version of the constants it's using … cleoc 5.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1

OK. Change to normal number of events.

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 1-10
dhad-3.0.3 check cleog Single_Dp_to_Kspipipi OK.

Check the log file … Nominal beam energy = 1.89

dhad-3.0.3 gen pass2 Single_Dp_to_Kspipipi task 1-10
dhad-3.0.3 check pass2 Single_Dp_to_Kspipipi OK.

dhad-3.0.3 gen ntuple Single_Dp_to_Kspipipi 
dhad-3.0.3 check ntuple Single_Dp_to_Kspipipi OK.

dhad-3.0.3 plot E_vpho regular3 signal Single_Dp_to_Kspipipi

Still the same mean 3.774GeV, different than the 3.773GeV in the 7.06 case.

That means the beam energy is still using the new one.

Email Anders and Peter … sent.

Make the vphoton for the four-vector case. Same energy as the original (7.06).

Message from Anders:

OK, I think that this was basically what we expected. But it is good to confirm.

The next thing I think we should try to do is to print out the beam energies in

MCBeamParametersProxy <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=MCBeamParametersProxy>::faultHandler <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=faultHandler>

In particular around these lines:

131 <https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/MCAsymmetricBeamProd/Class/MCBeamParametersProxy.cc#131>    newParams.setElectronBeamEnergy <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=setElectronBeamEnergy>( m_beamProducer->electronBeamEnergy() );
132 <https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/MCAsymmetricBeamProd/Class/MCBeamParametersProxy.cc#132>    newParams.setPositronBeamEnergy <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=setPositronBeamEnergy>( m_beamProducer->positronBeamEnergy() );
133 <https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/MCAsymmetricBeamProd/Class/MCBeamParametersProxy.cc#133>    newParams.setElectronBeamEnergySpread <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=setElectronBeamEnergySpread>( m_beamProducer->electronBeamEnergySpread() );
134 <https://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/src/MCAsymmetricBeamProd/Class/MCBeamParametersProxy.cc#134>    newParams.setPositronBeamEnergySpread <https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=setPositronBeamEnergySpread>( m_beamProducer->positronBeamEnergySpread() );

We need to do this in both the old and new release and compare.

Start backwards:

Ecm -> pte.ecm -> HadronicDNtuple.cc:

   FAItem< BeamEnergy > beamenergy;
   extract( iFrame.record( Stream::kStartRun ) , beamenergy );
   assert(beamenergy.valid());
   tuple.ecm = 2*beamenergy->value();

Read FAItem.h, BeamEnergy.h.

Notice: there is no module in 3.0.7/cleo for MCBeamEnergyFromMCBeamParametersProd

Search string "Taking Beam Energy from MCBeamParameters" in log file. … not found.

From the other way around:

cleog-generic-array.sh -> genmc_anders.tcl -> cleog_command.tcl

MCSymmetricBeamProd -> CesrBeamEnergyProd,

Read MCSymmetricBeamProd.cc, MCBeamParametersProxy.cc.

Suggestion from Lawrence: Continues this thread …

MCBeamParametersProxy https://www.lepp.cornell.edu/restricted/webtools/cleo3/ident?i=MCBeamParametersProxy

Look up the release version for the MCRawData package.

/nfs/cleo3/Offline/rel/20080624_MCGEN/pkg_versions

In the Old release (20050525_MCGEN) do this in the 7.06 … done.

beam energy:1.8863001

In the new release:

Look up the pkg versions for the CesrBeamEnergyProd

/nfs/cleo3/Offline/rel/20080624_MCGEN/pkg_versions

Found: (same as the original release).

CesrBeamEnergyProd   Infrastructure   v01_00_02   proc

Check out the CesrBeamEnergyProd:

cd $dhad/src/3.0.3/cleo/
export CVSROOT=/nfs/cleo3/cvsroot
cleo3cvs co -r v01_00_02 CesrBeamEnergyProd
. local_setup
c3make 

Edit the BeamEnergyProxy.cc:

#include <iostream>
#include <iomanip>
   std::cout << "xshi_debug >>> beam energy:" << std::setprecision(8) 
       << p_BeamEnergy->value() << std::endl;

Test

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

xshi_debug >>> beam energy:1.88732

Release	Beam Energy	x2	vpho energy
Original	1.8863001	3.7726002	3.77330
New	1.88732	3.77464	3.77405

Why there is less digits? … send to Anders … done.

Reply:

Is this consistent with what you see from the vpho energy?

Make the cut on the run number to get the vpho energy.

Task 3 means run 205456.

Original:

dhad-3.0.3 plot E_vpho 7.06/regular2 signal Single_Dp_to_Kspipipi -o run_205456 

NAME	VALUE	ERROR
Mean	3.77262e+00	3.37923e-05
Sigma	2.06394e-03	2.28507e-05

New Release:

dhad-3.0.3 plot E_vpho regular signal Single_Dp_to_Kspipipi -o run_205456  

NAME	VALUE	ERROR
Mean	3.77466e+00	3.40907e-05
Sigma	2.11434e-03	2.59560e-05

Update the table:

Release	Beam Energy	x2	vpho energy	vpho-x2 (MeV)
Original	1.8863001	3.7726002	3.77262	0.0198
New	1.88732	3.77464	3.77466	0.02

No difference.

Send to Anders … sent.

Sent email to Anders about the DEBUG logfile.

Reply from Anders:

in the 'original' I see:

%% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.27
%% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.00102 GeV
xshi_debug >>> beam energy:1.8863001
%% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

%% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
%% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.89, spread = 0.0015, min=3.76, max=3.78

and in the new I see:


%% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.1
%% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of 0 GeV
xshi_debug >>> beam energy:1.88732
%% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

%% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
%% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.88732, spread = 0.0015, min=3.76403, max=3.78525

so different versions of the DBBeamEnergyShifts are used in the two versions. I suggest two things:

1) Can you fix the code in the

%% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy ....

so that it prints out the beam energy with a precision of about 0.01 MeV? Othewise we
can not tell the energy.

2) You tried to run with the old constants. Can you try this again after fixing 1) so
that we can see if this works.    

Do the original release first …

Look up the pkg versions for the MCSymmetricBeamProd

/nfs/cleo3/Offline/rel/20080624_MCGEN/pkg_versions

Notice the orignial version is v01₀₂₀₃.

MCSymmetricBeamProd   MonteCarlo   v01_02_04   proc

cd $dhad/src/3.0.3/cleo/
export CVSROOT=/nfs/cleo3/cvsroot
cleo3cvs co -r v01_02_04 MCSymmetricBeamProd
. local_setup
c3make 

Add precision(8).

Check the cleog_command.tcl to use the new cleog constants first.

{30 {cleoc 6}}

Back up the previous log… OK.

Change the cleog-generic-array.sh for 10 event.

Test for 10 events…

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Save the log file cleog.txt.2

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.1
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of 0 GeV
xshi_debug >>> beam energy:1.88732
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.88732, spread = 0.0015, min=3.7640335, max=3.7852467

Now use the old constants.

{30 {cleoc 5}}

Test for 10 events…

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Save log cleog.txt.3

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.27
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.00102 GeV
xshi_debug >>> beam energy:1.8863001
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.8863001, spread = 0.0015, min=3.7619936, max=3.7832068

Make the comparison talbe.

	Original	New Release	Old CLEOG const
BeamEnergyShift version	1.27	1.1	1.27
Beam Energy shift (GeV)	-0.00102	0	-0.00102
Nominal beam energy	1.8863001	1.88732	1.8863001

Send to Anders.

Reply from Anders:

When you use the old cleog constants can you also check what the average
vpho energy is? I thought we had checked that you did not get back the old
beam energy when you used the old constants? Did I misunderstand this?

Check the log file when using the old cleog constants…

List the constants for the DptoKspipipi-3:

	Original	New Release	Old CLEOG const
BeamEnergyShift version	1.27	1.1	1.1

Take quick 10 events test on the DptoKspipipi-3.

Back up the old log

dhad-3.0.3 gen cleog Single_Dp_to_Kspipipi task 3

Save log cleog.txt.4

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.1
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of 0 GeV
xshi_debug >>> beam energy:1.88732
 %% DEBUG-ConstantsPhase2Delivery.DBCP2Proxy: getConstants: returned successfully.

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergySpread using version 1.11
 %% INFO-MCSymmetricBeamProd.MCBeamParametersProxy: Nominal beam energy = 1.88732, spread = 0.0015, min=3.7640335, max=3.7852467

Now try other modes:

dhad-3.0.3 gen cleog Single_Dm_to_Kspipipi task 3

Still 1.1!!

Test for all the modes and runs…

Clean up the files.

dhad-3.0.3 gen cleog single

Mode	Run	BeamEnergySpread version
D0toKpi	205456	1.1

Save the new cleog Single_DmtoKpipipi0 task 3 to log cleog.txt.5

Compare the two output. Starting release is different!!!

Test again on Single_DmtoKpipipi0 …

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3  Using release 20080624_MCGEN

Now, submit the job after set the cleo 2.4.

setdhad 2.4
dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3  

Get the same version for the new release again!! ???

OK. Do the test again for the 3.0.3!

Clear the log file… done.

Check the cleoc constants version … cleoc 5.

Test on 10 events:

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

No longer get that version.

Put the analysis and src version number info into the beginning of the local_setup.

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Log file cleog.txt.6 DBBeamEnergyShift using version 1.1

Run for full events…

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3
dhad-3.0.3 check cleog Single_Dm_to_Kpipipi0 ... too large to parse!

Need to turn off the DEBUG before running with full events!

grep DBBeamEnergyShift 
DBBeamEnergyShift using version 1.1

dhad-3.0.3 gen pass2 Single_Dm_to_Kpipipi0 task 3
dhad-3.0.3 check pass2 Single_Dm_to_Kpipipi0 OK.

dhad-3.0.3 gen ntuple Single_Dm_to_Kpipipi0
dhad-3.0.3 check ntuple Single_Dm_to_Kpipipi0

dhad-3.0.3 plot E_vpho regular3 signal Single_Dm_to_Kpipipi0 ...

For 10 events with DEBUG on…

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Save the log file cleog-1.txt

Use the new constants…

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Save the log file cleog-2.txt

Send Anders for the two files… done.

Talk with Anders and Brian, ask DLK … ask Peter Zweber… hold.

Use the postPass2 from Dan …

http://www.lepp.cornell.edu/restricted/webtools/cleo3/source/Offline/doc/web/Constants/ConstantsFreeze_CLEO-c.html#447

 -  Freeze constants for post-Pass2 processing of the dataset
    Tag: PostPASS2-C_6 After the completion of Pass2, the first set of
    post-Pass2 constants is frozen from default (types MagFudge,
    BeamEnergyShift until data38, and SuperConductingQuadFieldMap). This
    is used to

    * generate runinfo data (typically by Brian Heltsley) and
    * for cleog (the generation stage of CLEO MC) - BeamEnergyShift
      only Note: Since the BeamEnergyShift values are usually not
      known at the beginning of Pass2 processing (until data38), Pass2
      is done with zero BeamEnergyShift (until data38). For
      consistency, it is preferable to stick to this rule for all
      datasets until data38, although the effect is believed to be
      small enough to be ignored for most analysis work except
      precision mass measurements. In parallel, MC generation should
      use correct (nonzero) BeamEnergyShift, to model the real world
      better. However, Pass2 (_5) for some run ranges has been done
      with nonzero BeamEnergyShift (which were known from a previous
      round of Pass2): 200978 - 202522 (data31 and part of data32),
      202670 - 203111, 203429 - 203634, and from data39 onwards. Until
      April, 2005, all MC had been generated and Pass2'ed with the
      same BeamEnergyShift constants that were used in Pass2 (zero or
      nonzero).  In April, 2005, this was corrected by modifying
      setup_constants_command.tcl to retrieve BeamEnergyShift from the
      PostPASS2-C_5 tag - for cleog only (MCPass2 continues to get
      BeamEnergyShift from the PASS2-C_6 tag).  Starting in January,
      2006, the final BeamEnergyShift constants are determined before
      the start of Pass2, and added to the PASS2-C_6 tag.

Note: The type SuperConductingQuadFieldMap is unlikely to change
frequently. It is open ended for PostPASS2-C_5 and usually does not
need to be frozen.

cp  $C3_SCRIPTS/setup_constants_command.tcl /home/xs32/work/CLEO/analysis/DHad/src/3.0.3/gen/

tcl_proc setup_constants_cleoc_cleog {tag} {
    global env
    # First setup mcpass2 constants and then read in 
    # beamenergyshift stream with different (post-pass2
    # constants) tag:
    # Since we want to generate the MC using the best estimate
    # for the beam energy we apply a correction determined from
    # the D meson mass in the processed (pass2-ed) data.
    setup_constants_cleoc_mcpass2 $tag
    switch -exact -- $tag {
 5 {
     exclude_constants_streams {beamenergyshift}
     constants in $env(C3_CONST) standard PostPASS2-C_5 streams beamenergyshift
 }
 default {
     error "unknown cleoc cleog tag \"$tag\" requested"
 }
    }
}

The mapping from ::suez::setup_constants to running setup_constants_command.tcl happens inside suez.


eval "::suez::setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"

is equivalent to (something like)

   run_file $env(C3_SCRIPTS)/setup_constants_command.tcl
   eval "setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"

(though I'm not completely positive about the "eval").    

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

    I can't completely figure out what is up, because you don't say
where your driving scripts reside. But I do see on
dlk_lnx231> ls -lFrt
/nfs/cor/an2/xs32/cleo/dhad/dat/signal/3.0.3/cleog_20080624_MCGEN/
total 0
-rw-r--r-- 1 xs32 cms 0 Nov 10 15:01 cleog_Single_Dm_to_Kpipipi0_3.pds

The strange thing is that on the /nfs/cor/an2 disk you are in the cms
group, and on /nfs/cor/user/ you are in cleo. It may be that this is
part of the mysterious behavior.

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3 

     I can't, on cursory examination, see anything wrong with this
script or the script cleog-generic-array.sh that it invokes. I do have a
suggestion. Try running the job interactively on lnx201 or on your own
workstation. Then the mysterious loss of log output will be unveiled.    

%% DEBUG-ConstantsPhase2Delivery.CP2SourceBinder: fdbName /nfs/cleo3/constants/db/Codi Tag PASS2-C_5

%% DEBUG-ConstantsPhase2Delivery.CP2SourceBinder: fdbName /nfs/cleo3/constants/db/Codi Tag PASS2_3

eval "::suez::setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"

I dunno.  Somehow, it must think you are trying to analyze dataset 1. Do you have the run number wrong?

export RUNNUMBER=`nl -s " " $SCRIPTDIR/runlist | grep " $SGE_TASK_ID " | awk '{ print $2 }'`

Runnumber:  201911 202919 205456 206080 206937 207636 208217 208729 209275 209750

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3 

    #eval "::suez::setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"
    run_file $env(C3_SCRIPTS)/setup_constants_command.tcl
    eval "setup_constants cleog [lindex $constants_args 0] [lindex $constants_args 1]"

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

Added setup_constants command 
invalid command name "setup_constants"; type 'help' for available commands

Let's try something simpler--go back to the working version, and add


           exclude_constants_streams {beamenergyshift};
           constants in $env(C3_CONST) standard PostPASS2-C_5 streams beamenergyshift

to the -post block you give to the cleog command.     

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

mkdir: cannot create directory `/home/xs32/work/CLEO/analysis/DHad/dat/signal/3.0.3/dskim_20080624_MCGEN_20041104_MCP2_A_1'
: No space left on device                                                                                                 
mkdir: cannot create directory `/home/xs32/work/CLEO/analysis/DHad/dat/signal/3.0.3/dtuple_20080624_MCGEN_20041104_MCP2_A_1
': No space left on device                                                                                                

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3

 %% NOTICE-ConstantsPhase2Delivery.DBCP2Proxy: DBBeamEnergyShift using version 1.27
 %% DEBUG-CesrBeamEnergyProd.BeamEnergyProxy: Applying Beam Energy shift of -0.00102 GeV

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3 

dhad-3.0.3 gen cleog single
dhad-3.0.3 check cleog single

dhad-3.0.3 gen cleog Single_D0_to_Kpipi0 task 3
dhad-3.0.3 gen cleog Single_D0B_to_Kpipi0 task 10
dhad-3.0.3 gen cleog Single_D0B_to_Kpipipi task 8
dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 4 
dhad-3.0.3 gen cleog Single_Dp_to_KKpi task 8 

dhad-3.0.3 gen pass2 single ... done.
dhad-3.0.3 check pass2 single

dhad-3.0.3 gen pass2 Single_Dm_to_Kpipipi0 task 2
dhad-3.0.3 gen pass2 Single_Dm_to_KKpi task 7,9 

dhad-3.0.3 gen ntuple single
dhad-3.0.3 check ntuple single OK.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.3/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular3

dhad-3.0.3 yield regular3 -t s -m 0 ... OK. 
dhad-3.0.3 yield regular3 -t s --qsub ... OK.

dhad-3.0.3 fit regular3 -t s -m 1 ... OK.

Start from the page:

https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/EvtGen

Save the EvtGen doc to the dhad/doc/man.

Ask question on Prelim HN … sent.

Message from Surik:

Please look at the following webpage
https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/CLEOcMC

Hint from Peter: the intermediate step is stored inside pds.

Has done before by Brian, consult him … later.

Generate the four-vector in 7.03

cd $dhad/src/cleo/gen
rm -r 3.0.4 

Input DCTree as cleog

cd $dhad/src
cvs co -d 3.0.5 dhad/src 
cd $dhad/src/cleo/gen
cp -r $dhad/src/3.0/gen/  3.0.5

setdhad 3.0.5

Refer to page: https://wiki.lepp.cornell.edu/lepp/bin/view/CLEO/Private/SW/GeneratingMCDecayTree

Create run_cleog.tcl.

set filein  $env(INDIR)/cleog_decaytree_$env(DECAYTITLE)_$env(BATCH).pds
set fileout $env(OUTDIR)/cleog_$env(DECAYTITLE)_$env(BATCH).pds

Edit the cleog-generic-array.sh:

export NUMEVT=10
export INDIR=/home/xs32/work/CLEO/analysis/DHad/dat/signal/2.3/cleog_0214_photosnew

dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 1

Error: => cleog2.txt

Ask on HN … sent.

Message from Surik:

 One thing that you could do just try different MCGEN release,
 to be sure that problem is not related to the particular release.

 Which release are you using  in the "four-vector creation" and
 cleog stages?

Finish the cleog in the old release …

After a bug fix by Dan, not work in 7.06, try it here:

Edit the run_cleog.tcl:

#run_file $env(C3_SCRIPTS)/cleog_command.tcl
run_file /home/dsr/cleog_command.tcl
set filein $env(INDIR)/decaytree_$env(DECAYTITLE)_$env(BATCH).pds

Edit the cleog-genric-array.sh:

export INDIR=/home/xs32/work/CLEO/analysis/DHad/dat/signal/2.3/decaytree_0214_photosnew

dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 1

Save log => cleog.txt.3 OK.

Save the tcl file :

cp ~dsr/cleog_command.tcl /home/xs32/work/CLEO/analysis/DHad/src/cleo/gen/3.0.5/

Edit the run_cleog.tcl:

run_file /home/xs32/work/CLEO/analysis/DHad/src/cleo/gen/3.0.5/cleog_command.tcl

Test one normal number of event mode … done in 7.06.

Continue test for cleog:

dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 3  ... OK.

Clean up and ready for large files.

In 7.06 … problem.

Do it here in 9.03.

Merge with B02-03:

cd $dhad/src/3.0.5/python
cvs up -j B02-03

Create decaytree-generic-array.sh

In the file /nfs/cor/an1/ponyisi/2007-4/local_setup:

c3rel 20050525_MCGEN

Comment out the line with "c3rel $CGRELEASE".

Create gen_decaytree.tcl .

dhad-3.0.5 gen decaytree Single_Dm_to_Kspi task 3  ... OK. 

Continue test for cleog:

Edit the cleog-generic-array.sh:

export INDIR=$TOPDIR/decaytree$CGSUFFIX
export NUMEVT=`cat $SCRIPTDIR/tag_numbers/$1`

Edit run_cleog.tcl:

run_file $env(SCRIPTDIR)/cleog_command.tcl

dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 3  ... OK.

Generate Decay tree files:

dhad-3.0.5 gen decaytree single  ... OK. 

Test one mode :

dhad-3.0.5 gen cleog Single_Dp_to_KKpi task 2  ... OK.

dhad-3.0.5 gen cleog single ... OK.
dhad-3.0.5 check cleog single ... 

dhad-3.0.5 gen cleog Single_D0_to_Kpi task 6
dhad-3.0.5 gen cleog Single_D0_to_Kpipipi task 5
dhad-3.0.5 gen cleog Single_Dp_to_Kpipi task 5
dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 7
dhad-3.0.5 gen cleog Single_Dp_to_Kspipi0 task 1 

dhad-3.0.5 check cleog Single_D0_to_Kpi OK. 
dhad-3.0.5 check cleog Single_D0_to_Kpipipi OK. 
dhad-3.0.5 check cleog Single_Dp_to_Kpipi OK. 
dhad-3.0.5 check cleog Single_Dm_to_Kspi OK. 
dhad-3.0.5 check cleog Single_Dp_to_Kspipi0 OK.

Run four-vectors pass2

dhad-3.0.5 gen pass2 single 
dhad-3.0.5 check pass2 single 

dhad-3.0.5 gen pass2 Single_D0B_to_Kpi task 1
dhad-3.0.5 gen pass2 Single_D0B_to_Kpipi0 task 7,8
dhad-3.0.5 gen pass2 Single_D0_to_Kpipipi task 6-8 
dhad-3.0.5 gen pass2 Single_Dp_to_Kpipi task 10 
dhad-3.0.5 gen pass2 Single_Dm_to_Kpipi task 4
dhad-3.0.5 gen pass2 Single_Dm_to_Kpipipi0 task 2
dhad-3.0.5 gen pass2 Single_Dp_to_Kspi task 9
dhad-3.0.5 gen pass2 Single_Dp_to_Kspipi0 task 9
dhad-3.0.5 gen pass2 Single_Dm_to_Kspipi0 task 1,8
dhad-3.0.5 gen pass2 Single_Dp_to_KKpi task 6

dhad-3.0.5 check pass2 single ... OK.

Test one mode:

Edit dtuple-generic-array.sh

cd /home/xs32/work/CLEO/analysis/DHad/src/cleo/3.0/
c3make
dhad-3.0.5 gen ntuple Single_D0B_to_Kpi --test

dhad-3.0.5 gen ntuple Single_D0B_to_Kpi

Log file => dtuple.txt

Review a similar error … http://www.lepp.cornell.edu/~xs32/private/DHad/log/2009/0331/d0tokpi.txt

Try another mode:

dhad-3.0.5 gen ntuple Single_Dm_to_Kpipipi0 

Log file => dtuple.txt.1

Same error.

So, this problem is not just for one mode.

Look into the code: HadronicDNtupleProc.cc

Print out the mcpart:

   if (deathVtx == NULL) {
     cout << mcpart << endl;
   }

Test …

dhad-3.0.5 gen ntuple Single_Dm_to_Kpipipi0 

Log file => dtuple.txt.2

  43   1  GAMM (-0.025552, 0.049155,-0.098744; 0.113226)  0.0 37   8   2   39  1 44
                                                                           40  0    

Ask on DHad HN … sent.

Reply from Anders:

is this the problem where you are not decaying the FSR photons?

Check previous note:

24 616 gammaFSR (-0.000007,-0.000007,-0.000007; 0.000016)  0.0 20   5   0 

Maybe related to gammaFSR.

Check the FSR decay :

Refer to the cleog-generic-array.sh in 3.0.2:

Edit the decaytree-generic-array.sh and cleog-generic-array.sh in 3.0.5:

export C3_DATA=/home/xs32/work/CLEO/analysis/DHad/src/3.0.2/cleo/data
echo $C3_DATA

Clean the output dir.

Test for one mode:

dhad-3.0.5 gen decaytree Single_Dm_to_Kspi task 3  ... OK.
dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 3  ... OK.
dhad-3.0.5 gen pass2 Single_Dm_to_Kspi task 3  ... OK.
dhad-3.0.5 gen ntuple Single_Dm_to_Kspi  ... not work. 

Print out the decaytree …

std::cout << *decaytree << std::endl;

Test …

dhad-3.0.5 gen ntuple Single_Dm_to_Kspi

Log file => dtuple.txt

  id  #d typ position                          time
   1   2   1 (-0.000110,-0.000248, 0.002647) 2.900923e+04:  VPHO --> PS377 GAMM 
   2   2   1 (-0.000110,-0.000248, 0.002647) 2.900923e+04: PS377 -->   D+   D- 
   3   3   1 (-0.000096,-0.000238, 0.002663) 2.900993e+04:    D+ -->  K*- RHO+  PI+ 
   4   2   1 (-0.000096,-0.000238, 0.002663) 2.900993e+04:   K*- -->   K-  PI0 
   5   1   5 ( 0.360538, 0.316115,-0.587320) 3.378743e+04:    K- -->  MU- 
   6   1  35 ( 0.670444, 0.958060,-0.721121) 5.260126e+05:   MU- -->   E- 
   7   0  30 ( 0.678551, 0.953643,-0.734737) 5.260732e+05:    E- -->     
   8   2   1 (-0.000096,-0.000238, 0.002663) 2.900993e+04:   PI0 --> GAMM GAMM 
   9   0   6 (-0.889502,-0.645356, 1.359701) 3.483423e+04:  GAMM -->     

So, this GAMM is different with gammaFSR.

Try to generate decaytree in new release.

cd $dhad/src
cvs co -d 3.0.6 dhad/src
cd 3.0.6
cvs tag V03-00-05

Remove the gen module.

Remove the cleo dir.

Move the related dir into the src.

setdhad 3.0.6

Edit decaytree-generic-array.sh:

dhad-3.0.5 gen decaytree Single_Dp_to_KKpi task 1 

Pause here after the meeting. Not necessary for this step.

Use the MCInfoDelivery in the cleog_command.tcl

dhad-3.0.5 gen decaytree Single_Dm_to_Kspi task 1 

::proc setup_mcproperties { generator } {
   global env

    ::suez::prod sel MCInfoDeliveryEvtGenProd
    ::suez::param MCInfoDeliveryEvtGenProd transTable $env(C3_DATA)/trans.tab

#     if { 0 == [string compare $generator "EvtGen"] } {
#        ::suez::prod sel MCInfoDeliveryEvtGenProd
#        ::suez::param MCInfoDeliveryEvtGenProd transTable $env(C3_DATA)/trans.tab
#     } else {
#        ::suez::prod sel MCInfoDelivery
#     }  
    
}

dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 1

%% WARNING-MCInfo.MCParPropStore: 
No particle with the requested QQ ID 0exists in the store.
(The problem may also have originiated with an invalid GEANT ID)
suez.exe:
/nfs/linux/cleo3/Offline/rel/20080624_MCGEN/src/MCInfo/Class/MCParticleProperty/MCParticlePropertyStore.cc:577:
const MCParticleProperty& MCParticlePropertyStore::getUsingQQId(int)
const: Assertion `false' failed

dhad-3.0.5 gen decaytree Single_Dm_to_Kspi task 1 
dhad-3.0.5 gen cleog Single_Dm_to_Kspi task 1

c3rel 20080624_MCGEN
cd $dhad/src/3.0.5/cleo
export CVSROOT=/nfs/cleo3/cvsroot 
cleo3cvs co MCInfo

cleo3cvs co MCInfoDeliveryEvtGenProd

OK, I found a lot of old emails.

 This might be related to what you want to do:

>  select, and deselect, MCInfoDelivery up in the front of
>  the cleog and mcpass2 tcl files. You will also have to
>  deselect MCInfoDelivery in the -post{} portion of your mcpass2
>  tcl script. This is because you need the storage helper
>  but the property store from the EvtGen file, not from MCInfoDelivery
>  (subtle point!).

 So this would allow you to read in the property store
from the input file itself instead of the default
one for MCInfoDelivery.

::suez::prod sel MCInfoDelivery
run_file $env(SCRIPTDIR)/cleog_command.tcl
::suez::prod desel MCInfoDelivery
cleog file $filein out $fileout -post {
::suez::prod desel MCInfoDelivery
}

dhad-3.0.5 gen decaytree Single_Dm_to_Kspipi0 task 2
dhad-3.0.5 gen cleog Single_Dm_to_Kspipi0 task 2
dhad-3.0.5 gen pass2 Single_Dm_to_Kspipi0 task 2
dhad-3.0.5 gen ntuple Single_Dm_to_Kspipi0 task 2

dhad-3.0.5 gen ntuple Single_Dm_to_Kspipi0 

dhad-3.0.5 gen decaytree single Single_Dm_to_Kspipi0 task 1-10

qdel -u xs32 "*"

dhad-3.0.5 gen decaytree Single_Dm_to_Kspipi0 task 1-10
dhad-3.0.5 check decaytree Single_Dm_to_Kspipi0 OK.

dhad-3.0.5 gen cleog Single_Dm_to_Kspipi0 task 1-10
dhad-3.0.5 check cleog Single_Dm_to_Kspipi0 OK.

dhad-3.0.5 gen pass2 Single_Dm_to_Kspipi0 task 1-10
dhad-3.0.5 check pass2 Single_Dm_to_Kspipi0 OK.

dhad-3.0.5 gen ntuple Single_Dm_to_Kspipi0 
dhad-3.0.5 check ntuple Single_Dm_to_Kspipi0  OK.

dhad-3.0.5 gen decaytree Single_Dp_to_Kspipi0 task 1-10
dhad-3.0.5 check decaytree Single_Dp_to_Kspipi0 task 7 missing.
dhad-3.0.5 gen decaytree Single_Dp_to_Kspipi0 task 7 
dhad-3.0.5 check decaytree Single_Dp_to_Kspipi0 OK.

dhad-3.0.5 gen cleog Single_Dp_to_Kspipi0 task 1-10
dhad-3.0.5 check cleog Single_Dp_to_Kspipi0 OK.

dhad-3.0.5 gen pass2 Single_Dp_to_Kspipi0 task 1-10
dhad-3.0.5 check pass2 Single_Dp_to_Kspipi0 OK.

dhad-3.0.5 gen ntuple Single_Dp_to_Kspipi0 
dhad-3.0.5 check ntuple Single_Dp_to_Kspipi0 OK.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.5/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular4

dhad-3.0.5 yield regular4 -t s -m 203
dhad-3.0.5 fit regular4 -t s -m 203 --qsub 

dhad-3.0.5 table compare yields Single_Dm_to_Kspipi0 7.06 regular4

dhad-3.0.5 gen decaytree single 
dhad-3.0.5 check decaytree single 

dhad-3.0.5 gen cleog single 
dhad-3.0.5 check cleog single OK.

dhad-3.0.5 gen pass2 single 
dhad-3.0.5 check pass2 single OK.

dhad-3.0.5 gen ntuple single 
dhad-3.0.5 check ntuple single OK.

dhad-3.0.5 yield regular4 -t s 

dhad-3.0.5 fit regular4 -t s -m 0 –qsub log-2009-07-19 11:36:40

dhad-3.0.5 fit regular4 -t s -m 1 –qsub log-2009-07-19 11:37:36

dhad-3.0.5 fit regular4 -t s -m 3 –qsub log-2009-07-19 11:37:53

dhad-3.0.5 fit regular4 -t s -m 200 –qsub log-2009-07-19 11:38:48

dhad-3.0.5 fit regular4 -t s -m 201 –qsub log-2009-07-19 11:39:02

dhad-3.0.5 fit regular4 -t s -m 202 –qsub log-2009-07-19 11:39:14

dhad-3.0.5 fit regular4 -t s -m 203 –qsub log-2009-07-19 11:39:25

dhad-3.0.5 fit regular4 -t s -m 204 –qsub log-2009-07-19 11:39:38

dhad-3.0.5 fit regular4 -t s -m 205 –qsub log-2009-07-19 11:39:49

dhad-3.0.5 table compare yields signal 7.06 regular4

• Initial post

  Dear all,
  
  I've done the procedure of using the Decay Tree generated form the old
  EvtGen. The rest of the process, including CLEOG, MCPASS2,
  HadronicDNtupleProc, are done in the new release. The comparison
  between this check and the old result can be found at:
  
  http://www.lepp.cornell.edu/~xs32/private/DHad/rel-9.03#tab-compare_yields_signal_7.06_regular4
  
  Here one can see that the difference is very small, especially for
  those trouble modes.  To make it clear, I also made a table
  summarizing all the checks we have done in the past two months.
  
  http://www.lepp.cornell.edu/~xs32/private/DHad/rel-9.03#tab-compare_yields_signal_7.06_regular_1_4
  
  In the above table, you can see the problem modes in the column
  "diff(%) -regular".
  
  I'm open to suggestions on where to go from here. ...
  
  Thanks!    
  

• Reply from Anders:

  the conclusion I draw from this is that the efficiency changes you have seen are
  due to the new EvtGen version in the new release. Is this also your conclusion?
  (It is very useful if you include your conclusions in your postings.)
  
  Assuming this is the case there are several changes:
  
  1) The code.
  2) The decay table (DECAY.DEC)
  3) the particle masses and width specification.
  4) Constants, i.e. the beam energy.
  (Am I missing something here?)
  
  If I understood what you have done earlier you have verified that the changes
  in the decay table and the beam energy was not the cause of the changes in
  the signal efficiency. Correct?
  
  This would leave 1) and 3). It should be easy to test if it is 3) by using the old
  particle table listing. For 1) I would need to think about this a little more. I
  think Peter made most changes. We should look at the changes between the
  two versions and see if we see anything suspicious.
  

• My further comments:

  Yes. The major difference is due to the EvtGen version change. 
  
  The decay table (2)  is not the reason for the change. 
  
  For the constants, (4), I still need further test. I checked the beam
  energy of results from using the old constants, they looks still using
  the new constants. I also tried to change the constants version
  directly in the cleog_command.tcl, but still didn't match the old one.
  

  Could you tell me how to use the old particle table listing?  Thanks!
  

• Reply from Anders:

  copy over the evt.pdt file (I think this is what it is called) from
  the old release to the $C3DATA area you are using.
  

cd $dhad/src
cvs co -d 3.0.7 dhad/src
setdhad 3.0.7

Setup the local C3_DATA area.

cd $src
mkdir cleo

New release: 20080624_MCGEN

cp -r /nfs/cleo3/Offline/rel/20080624_MCGEN/data cleo 

Set the C3_DATA variable in setup.sh.

Check the evt.pdl file.

Old release: 20050525_MCGEN

Make soft link for the evt.pdl files in local C3_DATA dir.

cd cleo/data
mv evt.pdl evt.pdl.20080624_MCGEN
ln -s /nfs/cleo3/Offline/rel/20050525_MCGEN/data/evt.pdl evt.pdl.20050525_MCGEN
ln -s evt.pdl.20050525_MCGEN evt.pdl

Test for one mode:

cd $dhad/src
cp 3.0/gen/* 3.0.7/gen/ -r
dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2

In the log file:

EvtGen:Main decay file name  :/nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC
EvtGen:PDT table file name   :/nfs/cleo3/Offline/rel/20080624_MCGEN/data/evt.pdl

Set up the variable in the cleog-generic-array.sh separately as it runs on the qsub.

export C3_DATA=/home/xs32/work/CLEO/analysis/DHad/src/3.0.7/cleo/data
echo $C3_DATA

See the effect in the log file - cleog.txt:

EvtGen:Main decay file name  :/home/xs32/work/CLEO/analysis/DHad/src/3.0.7/cleo/data/DECAY.DEC
EvtGen:PDT table file name   :/home/xs32/work/CLEO/analysis/DHad/src/3.0.7/cleo/data/evt.pdl

But terminated with problem:

EvtGen:Unknown particle name:Xdd on line 6625
EvtGen:Will terminate execution!

Look at the problem decay file version: # $Id: rel-9.03-details.org,v 1.1 2010/01/22 20:18:43 xs32 Exp $

Advice from Anders: Use the files in the same release.

cd $src/cleo/data
mv DECAY.DEC DECAY.DEC.20080624_MCGEN
ln -s /nfs/cleo3/Offline/rel/20050525_MCGEN/data/DECAY.DEC DECAY.DEC.20050525_MCGEN
ln -s DECAY.DEC.20050525_MCGEN DECAY.DEC

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2

Error message in the log file: cleog.txt

EvtGen:Two matching decays with same parent in decay table
EvtGen:Please fix that
EvtGen:Parent anti-B0
EvtGen:Daughter rho0
EvtGen:Daughter f_0
suez.exe: /nfs/linux/cleo3/Offline/rel/20080624_MCGEN/src/EvtGenBase/Class/EvtParticleDecayList.cc:322:
void EvtParticleDecayList::addMode(EvtDecayBase*, double, double): Assertion `0' failed.

cd $src/cleo/data
cp /nfs/cleo3/Offline/rel/20050525_MCGEN/data/DECAY.DEC DECAY.DEC.fixed

In the source code (EvtParticleDecayList.cc), function addMode:

   void EvtParticleDecayList::addMode(EvtDecayBase* decay, double brfrsum,
                             double massmin){
  EvtDecayBase *newDec=newlist[_nmode]->getDecayModel();
  for(i=0;i<_nmode;i++){
    if ( newDec->matchingDecay(*(newlist[i]->getDecayModel())) ) {

      //sometimes its ok..
      if ( newDec->getModelName() == "JETSET" || newDec->getModelName() == "PYTHIA" ) continue;
      if ( newDec->getModelName() == "JSCONT" || newDec->getModelName() == "PYCONT" ) continue;
      if ( newDec->getModelName() == "PYGAGA"  ) continue;
      if ( newDec->getModelName() == "LUNDAREALAW"  ) continue;
      report(ERROR,"EvtGen") << "Two matching decays with same parent in decay table\n";
      report(ERROR,"EvtGen") << "Please fix that\n";
      report(ERROR,"EvtGen") << "Parent " << EvtPDL::name(newDec->getParentId()).c_str() << endl;
      for (int j=0; j<newDec->getNDaug(); j++)
  report(ERROR,"EvtGen") << "Daughter " << EvtPDL::name(newDec->getDaug(j)).c_str() << endl;
      assert(0);
    }
  }

Use the previous already fixed DECAY.DEC file.

cd $src/cleo/data
cp $dhad/src/3.0.2/cleo/data/DECAY.DEC.2005.fixed .
ln -sf DECAY.DEC.2005.fixed DECAY.DEC 

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2

Error: EvtGen:Unknown particle name:gammaFSR on line 6242

Comment out the decays for gammaFSR.

Decay gammaFSR
1.0000 gamma                                         PHSP;
Enddecay

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2

Error: cleog.txt.1

EvtGen:In EvtPHOTOS::doRadCorr():Particle:gammaFSR is not in EvtPDL

Start from the –test

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2 --test

Trace the fix_mcjob.sh… OK.

Try to set the 3.0.2. Use the gammaFSR, and use evt.pdl from 2008.

ln -sf evt.pdl.20080624_MCGEN evt.pdl

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2 

Runs OK.

So, the problem is in evt.pdl.

Confirmed in DHad meeting - 20091001.

cd $dhad/src/3.0.7/cleo/data
cp /nfs/cleo3/Offline/rel/20050525_MCGEN/data/evt.pdl evt.pdl.20050525_MCGEN.fixed

Add line in evt.pdl.20050525_MCGEN.fixed:

add  p InterBoson  gammaFSR          100022 0.0000001       0       0       0       2       0 0

Link the default evt.pdl.

cp /nfs/cleo3/Offline/rel/20050525_MCGEN/data/evt.pdl evt.pdl.20050525_MCGEN.fixed
ln -sf evt.pdl.20050525_MCGEN.fixed  evt.pdl

dhad-3.0.7 gen cleog Single_Dp_to_KKpi task 2 

Runs OK.

• Mass difference (Unit: /GeV)

  name	20050525	20080624	Diff(MeV)
  K*0	0.8961	0.89600	-0.1
  K*+	0.8916	0.89166	0.06

Clean the dirs.

dhad-3.0.7 gen cleog single 
dhad-3.0.7 check cleog single 

dhad-3.0.7 gen cleog Single_D0_to_Kpi task 1-3 ...
dhad-3.0.7 gen cleog Single_Dp_to_Kpipi task 4 ... 

dhad-3.0.7 check cleog Single_D0_to_Kpi OK.
dhad-3.0.7 check cleog Single_Dp_to_Kpipi OK.

Test for one mode.

dhad-3.0.7 gen pass2 Single_Dp_to_Kpipi task 2 OK.

dhad-3.0.7 gen pass2 single  
dhad-3.0.7 check pass2 single  OK.

Test for one mode:

dhad-3.0.7 gen ntuple Single_Dm_to_Kpipipi0 OK.
dhad-3.0.7 gen ntuple single ... OK.
dhad-3.0.7 check ntuple single OK.

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.7/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular5
dhad-3.0.7 yield regular5 -t s -m 1 ... OK.
dhad-3.0.7 yield regular5 -t s ... OK.

dhad-3.0.7 fit regular5 -t s -m 0 ... OK.

dhad-3.0.7 fit regular5 -t s -m 0 –qsub log-2009-10-05 13:36:10

dhad-3.0.7 fit regular5 -t s -m 1 –qsub log-2009-10-05 13:36:30

dhad-3.0.7 fit regular5 -t s -m 3 –qsub log-2009-10-05 13:36:56

dhad-3.0.7 fit regular5 -t s -m 200 –qsub log-2009-10-05 13:37:19

dhad-3.0.7 fit regular5 -t s -m 201 –qsub log-2009-10-05 13:37:38

dhad-3.0.7 fit regular5 -t s -m 202 –qsub log-2009-10-05 13:37:56

dhad-3.0.7 fit regular5 -t s -m 203 –qsub log-2009-10-05 13:38:13

dhad-3.0.7 fit regular5 -t s -m 204 –qsub log-2009-10-05 13:38:29

dhad-3.0.7 fit regular5 -t s -m 205 –qsub log-2009-10-05 13:38:44

dhad-3.0.7 table compare yields signal 7.06 regular5

Update the grand comparison table.

Comparing the regular5 and the regular, one can see that the difference in the trouble modes is still there, this means that the evt.pdl is not the reason causing the problem. So, evt.pdl should be turned "green" in the trace chart.

Now, we need to re-check the old constants before going into the EvtGen code.

cd $dhad/src
cp -r 3.0.3 3.0.8

Change the setup, localsetup … OK.

Change the cleog-generic-array.sh … OK.

Test for 10 events:

setdhad 3.0.8
dhad-3.0.8 gen cleog Single_Dm_to_Kpipipi0 task 3

Error cleog.txt.

Re-compile with 20080624_MCGEN … same error.

Quick test on 3.0.3

dhad-3.0.3 gen cleog Single_Dm_to_Kpipipi0 task 3 

Same error.

Post on HN … sent. Fixed.

dhad-3.0.8 gen cleog Single_Dm_to_Kpipipi0 task 3

OK.

cd $dhad/src
cp -r 3.0.7/cleo/data 3.0.8/cleo

Edit the cleog-generic-array.sh … OK.

Test on 10 events …

dhad-3.0.8 gen cleog Single_Dm_to_Kpipipi0 task 3

OK.

Reset the normal number of events… OK.

Test for one mode

dhad-3.0.8 gen cleog Single_Dm_to_Kpipipi0 task 3  OK.

Clear the dir … OK.

Run for all modes.

dhad-3.0.8 gen cleog single 
dhad-3.0.8 check cleog single 

dhad-3.0.8 gen cleog Single_Dp_to_Kpipipi0 task 2
dhad-3.0.8 gen cleog Single_Dp_to_Kspipi0 task 4

dhad-3.0.8 check cleog single OK.

dhad-3.0.8 gen pass2 single 
dhad-3.0.8 check pass2 single OK.

dhad-3.0.8 gen ntuple single 
dhad-3.0.8 check ntuple single OK.

Extract yields…

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.8/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular8
dhad-3.0.8 yield regular8 -t s -m 0 OK.
dhad-3.0.8 yield regular8 -t s ... done.

Fit … done.

dhad-3.0.8 fit regular8 -t s -m 0 ... ibRooFitCore.so error.

Update the DHad python and DHadFit.py … OK.

dhad-3.0.8 fit regular8 -t s -m 0 –qsub log-2009-11-19 11:15:28

dhad-3.0.8 fit regular8 -t s -m 1 –qsub log-2009-11-19 11:18:02

python: can't open file '/home/xs32/work/CLEO/analysis/DHad/bin/dhad-3.0.8': [Errno 2] No such file or directory

• dhad-3.0.8 fit regular8 -t s -m 1 –qsub log-2009-11-19 13:21:40

dhad-3.0.8 fit regular8 -t s -m 3 –qsub log-2009-11-19 11:18:09

dhad-3.0.8 fit regular8 -t s -m 200 –qsub log-2009-11-19 11:18:21

dhad-3.0.8 fit regular8 -t s -m 201 –qsub log-2009-11-19 11:18:30

dhad-3.0.8 fit regular8 -t s -m 202 –qsub log-2009-11-19 11:18:35

dhad-3.0.8 fit regular8 -t s -m 203 –qsub log-2009-11-19 11:18:40

dhad-3.0.8 fit regular8 -t s -m 204 –qsub log-2009-11-19 11:18:45

dhad-3.0.8 fit regular8 -t s -m 205 –qsub log-2009-11-19 11:18:50

OK.

Update the table in category … OK.

Update the grand table … OK.

Add gauss fit info into the grand table … OK.

Email to Anders … OK.

Reply from Anders:

not sure what you mean by 'I'll try to bin them into 18 and take a look at the result',
just use the "L" option to do a likelihood fit, see: http://root.cern.ch/root/html/TH1.html    

Update the fits with L option … OK.

Update the grand table … OK.

Email to Anders … OK.

Document the fitting plots and point to Anders… sent.

EvtGenModle and

EvtGenBase used in the original release

From the CLEO code releases page:

20050525_MCGEN :

This is a subset of CLEO code containing only modules needed for generating MC events (cleog). It supersedes the 20050214_MCGEN release. EvtGenModels package has fixed FSR simulation from the initial state quarks in continuum production and fixed energy-momentum conservation in VPHOTOV model. The constants tag for beamenergyshift is changed to postPass2-C_5 in order to use the corrected beam energy at event generation (cleog_command.tcl) while the PASS2-C_5 beam energy shift is used in mcpass2 reconstruction. The MCRawData package was patched later (June 24, 2005) to simulate failure of the ElTrack and RadTau trigger lines between run 208843-208889. SuezScripts has been patched later (Aug 17, 2005) to merge the correct detector noise to the simulated events in data36-37.

From the difference page: the EvtGenModels has changed.

Check the EvtGenModels CVS web: version.info

Check the pkg versions:

/nfs/cleo3/Offline/rel/20050525_MCGEN/pkg_versions

EvtGen   MonteCarlo   v01_06_00   lib
EvtGenBase   MonteCarlo   v01_01_00   lib
EvtGenModels   MonteCarlo   v01_02_04   lib
EvtGenProd   MonteCarlo   v01_03_00   proc

For the new release:

/nfs/cleo3/Offline/rel/20080624_MCGEN/pkg_versions

EvtGen   MonteCarlo   v01_06_01   lib
EvtGenBase   MonteCarlo   v02_03_00   lib
EvtGenModels   MonteCarlo   v02_07_01   lib
EvtGenProd   MonteCarlo   v02_11_01   proc

Next, check out code and do the cvs diff.

Check out the new code:

cd $dhad/src/3.0.8/cleo
export CVSROOT=/nfs/cleo3/cvsroot 
cleo3cvs co -r v02_03_00 EvtGenBase

'-N' for new files, '-c': conxtext output format. diffs

cleo3cvs diff -N -c -r v01_01_00 -r v02_03_00 > diffs

Use the cvs2pl: ChangeLog

cvs2cl.pl --delta v01_01_00:v02_03_00 

Find the changed files: Not work. log.txt

 cleo3cvs -q log -NSR  -rv01_01_00::v02_03_00 2>/dev/null >log.txt

Do the same for the EvtGenModels:

cd $dhad/src/3.0.8/cleo
cleo3cvs co -r v02_07_01 EvtGenModels

Get the ChangeLog

cvs2cl.pl --delta v01_02_04:v02_07_01

Get the diffs

cleo3cvs diff -N -c -r v01_02_04 -r v02_07_01 > diffs

Email to Anders … sent.

Browse the EvtGenBase

Read the Evt.ps … OK.

Read the changed code … EvtGenBase:

Suspicious lines:

2006-01-10 16:26  ryd

  * Class/: EvtParticle.cc, EvtRandom.cc:
     Two changes:

     1) Modified code in EvtParticle::initializePhaseSpace such
        that 4-momentum is conserved.

     2) Add Gaussian generator in EvtRandom.

2006-01-15 22:17  ryd

  * Class/: EvtDecayTable.cc, EvtParticleDecayList.cc,
    EvtRaritaSchwingerParticle.cc: Fixed basis states of the
    RaritaSchwinger particles.

2006-01-25 13:55  ryd

  * Class/EvtRelBreitWignerBarrierFact.cc: Bug from d. Lange for
    decays where the mean mass of the particles are below threshold
    and the decay is allowed only due to the width of the particles.

2006-02-04 22:05  ryd

  * Class/: EvtAbsLineShape.cc, EvtParticle.cc,
    EvtRelBreitWignerBarrierFact.cc:
     Try to improve the error message that you get when you you try
    to
    simulate events where the initial energy is to small to produce
    the particle. E.g. for a vpho -> psi(2S) decay.

2006-03-03 22:34  ryd

  * Class/EvtDecayAmp.cc: Added code to decay photons produced by
    PHOTOS in EvtDecayAmp

2007-10-22 22:34  ryd

  * Class/EvtParticle.cc: Corrected typo

Ask Anders … sent.

No problem with these.

Read the changed code … EvtGenBase:

2006-01-10 16:35  ryd

  * Class/EvtPHOTOS.cc: Addes constructor to EvtPHOTOS so we can
    controll what photons are called that are generated by PHOTOS.

2006-01-11 15:58  ryd

  * Class/EvtVPHOtoVISR.cc: Updated the lineshape code for the
    psi(3770)

2006-01-15 22:20  ryd

  * Class/: EvtKKLambdaCFF.cc, EvtModelReg.cc: Updated model
    registry.

2006-01-25 14:14  ryd

  * Class/: EvtModelReg.cc, EvtSLBKPole.cc, EvtSLBKPoleFF.cc: New
    model for 'BK' pole form factors

2006-12-13 10:59  ponyisi

  * Class/EvtModelReg.cc, Class/EvtVPHOtoVISRHi.cc,
    EvtGenModels/EvtVPHOtoVISRHi.hh: Add Brian Lang's code for vpho
    -> psi(xxxx) gamma ISR process
2006-12-14 12:22  ponyisi

  * Class/EvtVPHOtoVISRHi.cc: Revert VPHOtoVISRHi to MC-determined
    probMax

2007-02-26 11:24  ponyisi

  * Class/EvtDDalitz.cc: Flip sign of rho amplitude for D+ -> K0 pi+
    pi0
2007-03-26 23:32  pcs

  * Class/EvtISGW2.cc: setProbMax() for updated D and Ds semileptonic
    decays
2007-04-02 23:28  ponyisi

  * Class/EvtVPHOtoVISRHi.cc: Fix infrequent crash in certain decay
    modes

2007-10-17 10:10  ponyisi

  * Class/EvtVPHOtoVISRHi.cc: Assert if daughters in VPHOTOVISRHI are
    listed in an order that the code doesn't treat properly

2007-10-18 22:50  ryd

  * Class/EvtPHOTOS.cc: Store 4-vectors pre-Photos.

2008-01-09 12:34  ponyisi

  * Class/EvtDDalitz.cc: Add Qing He's implementation of Belle's D0
    -> anti-K0 pi+ pi- Dalitz model

Recall one of the largest discrepancies is :

D+ to K0S pi+ pi+ pi-

Maybe in the Class/EvtDDalitz.cc ? … list in the group meeting page …

Recall: old v01_02_04 new v02_07_01

Find the corresponding CVS version:

cd $dhad/src/3.0.8/cleo/EvtGenModels/Class
cleo3cvs status -v EvtVPHOtoVISR.cc      

v01_02_04                       (revision: 1.5)
v02_07_01                       (revision: 1.9)

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.9 dhad/src

Edit the setup … no need to do.

Update the DHad.py … OK.

cp -r 3.0/gen 3.0.9/

Edit the gen/tag_numbers/Single_Dp_to_Kspipipi: 3931 x 3 = 11,793

Edit the gen/tag_numbers/Single_Dm_to_Kspipipi: 3931 x 3 = 11,793

setdhad 3.0.9 
dhad-3.0.9 gen cleog Single_Dp_to_Kspipipi task 1 ... OK.

dhad-3.0.9 gen cleog Single_Dp_to_Kspipipi task 1-10 
dhad-3.0.9 gen cleog Single_Dm_to_Kspipipi task 1-10 

dhad-3.0.9 check cleog Single_Dp_to_Kspipipi ... still 3931!

Clean the files… OK.

dhad-3.0.9 gen cleog Single_Dp_to_Kspipipi task 1 --set tag_numbers=11793 OK.

dhad-3.0.9 gen cleog Single_Dp_to_Kspipipi task 1-10 --set tag_numbers=11793
dhad-3.0.9 gen cleog Single_Dm_to_Kspipipi task 1-10 --set tag_numbers=11793

dhad-3.0.9 check cleog Single_Dp_to_Kspipipi OK.
dhad-3.0.9 check cleog Single_Dm_to_Kspipipi OK.

dhad-3.0.9 gen pass2 Single_Dp_to_Kspipipi task 1-10
dhad-3.0.9 gen pass2 Single_Dm_to_Kspipipi task 1-10

dhad-3.0.9 check pass2 Single_Dp_to_Kspipipi OK.
dhad-3.0.9 check pass2 Single_Dm_to_Kspipipi OK.

dhad-3.0.9 gen ntuple Single_Dp_to_Kspipipi
dhad-3.0.9 gen ntuple Single_Dm_to_Kspipipi

dhad-3.0.9 check ntuple Single_Dp_to_Kspipipi OK.
dhad-3.0.9 check ntuple Single_Dm_to_Kspipipi OK.

Extract yields…

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.9/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular9
dhad-3.0.9 yield regular9 -t s -m 204  OK.
dhad-3.0.9 fit regular9 -t s -m 204 OK. 

dhad-3.0.9 fit regular9 -t s -m 204 –qsub log-2009-12-15 09:16:48

dhad-3.0.9 table compare yields signal 7.06 regular9 -m 204

Mode	7.06	regular9	diff(%)
D+ → K0Sπ+ π+ π-	12542 ± 116	38925 ± 202	+210.4(+227.4σ)
D→ K0Sππ-π+	12586 ± 116	39126 ± 203	+210.9(+228.8σ)

Need to compare efficiency:

dhad-3.0.9 table eff single signal regular9 -m 204 ... OK.

Mode	Generated	Yield	Efficiency(%)
D+ → K0Sπ+ π+ π-	117930	38925 ± 202	33.01 ± 0.14
D→ K0Sππ-π+	117930	39126 ± 203	33.18 ± 0.14

dhad-3.0.9 table compare eff single signal 7.06 regular9 -m 204

Mode	7.06	regular9	diff(%)
D+ → K0Sπ+ π+ π-	31.91 ± 0.24	33.01 ± 0.14	+3.4(+4.6σ)
D→ K0Sππ-π+	32.02 ± 0.24	33.18 ± 0.14	+3.6(+4.8σ)

Compare with previous sigmas:

Mode	Previous	3X statistics
D+ → K0Sπ+ π+ π-	+3.0(+3.2σ)	+3.4(+4.6σ)
D→ K0Sππ-π+	+2.6(+2.8σ)	+3.6(+4.8σ)

Need to generate more sample in CLEOG&PDL&DEC (3.0.8).

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.10 dhad/src
cp -r 3.0.8/gen 3.0.10

Edit DHad.py … OK.

setdhad 3.0.10 
dhad-3.0.10 gen cleog Single_Dp_to_Kspipipi task 1 --set tag_numbers=11793 --test ... OK.
dhad-3.0.10 gen cleog Single_Dp_to_Kspipipi task 1 --set tag_numbers=11793 OK.

dhad-3.0.10 gen cleog Single_Dp_to_Kspipipi task 1-10 --set tag_numbers=11793
dhad-3.0.10 gen cleog Single_Dm_to_Kspipipi task 1-10 --set tag_numbers=11793

dhad-3.0.10 check cleog Single_Dp_to_Kspipipi OK.
dhad-3.0.10 check cleog Single_Dm_to_Kspipipi OK.

dhad-3.0.10 gen pass2 Single_Dp_to_Kspipipi task 1-10
dhad-3.0.10 gen pass2 Single_Dm_to_Kspipipi task 1-10

dhad-3.0.10 check pass2 Single_Dp_to_Kspipipi OK.
dhad-3.0.10 check pass2 Single_Dm_to_Kspipipi OK.

dhad-3.0.10 gen ntuple Single_Dp_to_Kspipipi
dhad-3.0.10 gen ntuple Single_Dm_to_Kspipipi

dhad-3.0.10 check ntuple Single_Dp_to_Kspipipi OK.
dhad-3.0.10 check ntuple Single_Dm_to_Kspipipi OK.

Extract yields and fit:

cd $dhad/9.03/dat/signal
ln -s $dhad/dat/signal/3.0.10/dtuple_20080624_MCGEN_20041104_MCP2_A_1/ regular10
dhad-3.0.10 yield regular10 -t s -m 204  OK.

dhad-3.0.10 fit regular10 -t s -m 204 OK. 

dhad-3.0.10 fit regular10 -t s -m 204 –qsub log-2009-12-17 08:38:59

Make the efficiency table :

dhad-3.0.10 table eff single signal regular10  -m 204 

Mode	Generated	Yield	Efficiency(%)
D+ → K0Sπ+ π+ π-	117930	38594 ± 202	32.73 ± 0.14
D→ K0Sππ-π+	117930	38716 ± 203	32.83 ± 0.14

Compare with the previous result:

dhad-3.0.10 table compare eff single signal 7.06 regular10 -m 204

Mode	7.06	regular10	diff(%)
D+ → K0Sπ+ π+ π-	31.91 ± 0.24	32.73 ± 0.14	+2.6(+3.4σ)
D→ K0Sππ-π+	32.02 ± 0.24	32.83 ± 0.14	+2.5(+3.4σ)

Still increased. Compare with previous:

Mode	Previous	3X statistics
D+ → K0Sπ+ π+ π-	+2.5(+2.7σ)	+2.6(+3.4σ)
D→ K0Sππ-π+	+1.8(+1.8σ)	+2.5(+3.4σ)

Comfirmed with the problem.

Document in the table section … OK.

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.11 dhad/src

Edit the DHad.py … OK.

Update the DHadFit.py … OK.

cd $dhad/9.03/dat/signal
ln -s regular  regular11

dhad-3.0.11 yield regular11 -t s -m 204 OK.

dhad-3.0.11 yield regular11 -t s ... OK.

dhad-3.0.11 fit regular11 -t s -m 204 ... OK.

dhad-3.0.11 fit regular11 -t s -m 0 –qsub log-2009-12-22 15:15:06

dhad-3.0.11 fit regular11 -t s -m 1 –qsub log-2009-12-22 15:15:14

dhad-3.0.11 fit regular11 -t s -m 3 –qsub log-2009-12-22 15:15:19

dhad-3.0.11 fit regular11 -t s -m 200 –qsub log-2009-12-22 15:15:24

dhad-3.0.11 fit regular11 -t s -m 201 –qsub log-2009-12-22 15:15:30

dhad-3.0.11 fit regular11 -t s -m 202 –qsub log-2009-12-22 15:15:35

dhad-3.0.11 fit regular11 -t s -m 203 –qsub log-2009-12-22 15:15:39

dhad-3.0.11 fit regular11 -t s -m 204 –qsub log-2009-12-22 15:15:44

dhad-3.0.11 fit regular11 -t s -m 205 –qsub log-2009-12-22 15:15:49

Book the plots … OK.

Change the parameters… in DHadFit.py :

    if ver >= 7.06 and ver < 9.03:
        
        Gamma    = 0.0286
        Mres     = 3.7718
        R        = 12.3
        
    if ver == 9.03:
        Gamma = 0.0252
        Mres  = 3.7724
        R = 12.7

dhad-3.0.11 fit regular11 -t s -m 0 –qsub log-2009-12-23 09:48:05

dhad-3.0.11 fit regular11 -t s -m 1 –qsub log-2009-12-23 09:49:56

dhad-3.0.11 fit regular11 -t s -m 3 –qsub log-2009-12-23 09:50:02

dhad-3.0.11 fit regular11 -t s -m 200 –qsub log-2009-12-23 09:50:09

dhad-3.0.11 fit regular11 -t s -m 201 –qsub log-2009-12-23 09:50:14

dhad-3.0.11 fit regular11 -t s -m 202 –qsub log-2009-12-23 09:50:18

dhad-3.0.11 fit regular11 -t s -m 203 –qsub log-2009-12-23 09:50:24

dhad-3.0.11 fit regular11 -t s -m 204 –qsub log-2009-12-23 09:50:29

dhad-3.0.11 fit regular11 -t s -m 205 –qsub log-2009-12-23 09:50:34

Compare to the original… OK.

dhad-3.0.11 table compare yields signal 7.06 regular11

Fit the deviations … OK.

dhad-3.0.11 plot deviations compare yields signal 7.06 regular11 --set headname=LineShap,fit=L

Add to the grand comparison … OK.

dhad-3.0.11 table combine compare_yields_signal_7dot06_regular_all chisq gaus 

Update compare to the original … OK.

Update Fit the deviations … OK.

Update the grand comparison … OK.

Found the discrepancy.

In the RooDEnergyImp.cc:

  //MARK III shape
  if (fabs(m_mc-1.0)<0.5) {
    //double r=12.7; // 1/GeV
    //double r=12.7/5.0; // 1/GeV
    //double r=25.0; // 1/GeV
    static int first=1;
    if (first<10){
      std::cout << "MARK III gamma:"<<m_gamma<<std::endl;
      first++;
    }
    //double gamma=m_gamma;
    double gamma=m_gamma*(pp*pp*pp/(1.0+(m_r*pp)*(m_r*pp))+pn*pn*pn/(1.0+(m_r*pn)*(m_r*pn)))/
      (pp0*pp0*pp0/(1.0+(m_r*pp0)*(m_r*pp0))+pn0*pn0*pn0/(1.0+(m_r*pn0)*(m_r*pn0)));
    return (p*p*p/(1.0+(m_r*p)*(m_r*p)))/((e-m_mres)*(e-m_mres)+gamma*gamma/4.0);
  }

But in the EvtVPHOtoVISR.cc:

  double GammaTot=Gamma*(pp*pp*pp/(1+pp*pp*rp*rp)+p0*p0*p0/(1+p0*p0*r0*r0))/
    (ppnorm*ppnorm*ppnorm/(1+ppnorm*ppnorm*rp*rp)+
     p0norm*p0norm*p0norm/(1+p0norm*p0norm*r0*r0));
  

  sigma*=pd*pd*pd/((mres-m)*(mres-m)+0.25*GammaTot*GammaTot);

Notice the additional factor (1.0+(m_r*p)*(m_r*p)) in the fitter code.

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.12 dhad/src
cd 3.0.12
cp ../1.0/RooFitModels/ -r .
cp ../1.0/RooFitCore/ -r .

Edit the code RooDEnergyImp.cc:

    // Remove the factor to match the EvtGenModels/Class/EvtVPHOtoVISR.cc - xs32 12/23/2009
    
    return (p*p*p)/((e-m_mres)*(e-m_mres)+gamma*gamma/4.0);

gmake -f GNUmakefile.standalone      
cp tmp/libRooFitModels.so $dhad/lib/RooFitModels/libRooFitModels_3_0_12.so

Change the DHad.py … OK. Change the DHadFit.py … OK.

cd $dhad/9.03/dat/signal
ln -s regular  regular12
dhad-3.0.12 yield regular12 -t s OK.
dhad-3.0.12 fit regular12 -t s -m 201  ... OK.

dhad-3.0.12 fit regular12 -t s -m 0 –qsub log-2009-12-23 10:58:14

dhad-3.0.12 fit regular12 -t s -m 1 –qsub log-2009-12-23 10:58:19

dhad-3.0.12 fit regular12 -t s -m 3 –qsub log-2009-12-23 10:58:25

dhad-3.0.12 fit regular12 -t s -m 200 –qsub log-2009-12-23 10:58:31

dhad-3.0.12 fit regular12 -t s -m 201 –qsub log-2009-12-23 10:58:38

dhad-3.0.12 fit regular12 -t s -m 202 –qsub log-2009-12-23 10:58:43

dhad-3.0.12 fit regular12 -t s -m 203 –qsub log-2009-12-23 10:58:48

dhad-3.0.12 fit regular12 -t s -m 204 –qsub log-2009-12-23 10:58:53

dhad-3.0.12 fit regular12 -t s -m 205 –qsub log-2009-12-23 10:58:57

Book the plots … OK.

dhad-3.0.12 web plots regular12 -t s  

Compare to the original… OK.

dhad-3.0.12 table compare yields signal 7.06 regular12

Fit the deviations … OK.

dhad-3.0.12 plot deviations compare yields signal 7.06 regular12 --set headname=Factor,fit=L

Add to the grand comparison … OK.

dhad-3.0.12 table combine compare_yields_signal_7dot06_regular_all chisq gaus 

Compare chisq :

dhad-3.0.12 table compare parameter chisq1 signal 7.06 regular12 --set rnd=0.001,err_type=None

dhad-3.0.12 table compare parameter chisq2 signal 7.06 regular12 --set rnd=0.001,err_type=None

Book the page … OK.

Message from Anders:

I finally had a quiet moment to sit down and look at the plots and numbers. The fits are
clearly better with this change to the line shape. But there is still some problem remaining.

First, can you clarify what was done on the page 'Grand Comparison Table' for this fit.
Besides removing this factor in the fitter to agree with the implementation in the MC you also
had changed the values of the mass and width of the pis(3770)? The sample that you
are fitting here is the same as in the 'Default' table.

When you compare these 'Factor'  fit with e.g. the 'Pass2' fit it is clear that the mass of the
D mesons are shifted by about 0.3 MeV. Could you also refit the 'EvtGen' sample with the new
lineshape fitting code that you used in the 'Factor' test? This would then go back to use the old
constants, but using the new EvtGen lineshape code _and_ a consistent fitting function. I'm
optimistic that doing this will give you results that are in good agreement with what you had
in the 'original' study.  Let me know if this is not clear.

Update the description in the grand comparison table … OK.

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.13 dhad/src
cd 3.0.13

Update DHad.py … OK.

Update the DHadFit.py to use the 3.0.12 fitting model … OK.

cd $dhad/9.03/dat/signal
ln -s regular8 regular13
dhad-3.0.13 yield regular13 -t s ... OK.
dhad-3.0.13 fit regular13 -t s -m 201 ... OK.

dhad-3.0.13 fit regular13 -t s -m 0 –qsub log-2010-01-01 11:44:33

dhad-3.0.13 fit regular13 -t s -m 1 –qsub log-2010-01-01 11:44:41

dhad-3.0.13 fit regular13 -t s -m 3 –qsub log-2010-01-01 11:44:47

dhad-3.0.13 fit regular13 -t s -m 200 –qsub log-2010-01-01 11:44:52

dhad-3.0.13 fit regular13 -t s -m 201 –qsub log-2010-01-01 11:44:57

dhad-3.0.13 fit regular13 -t s -m 202 –qsub log-2010-01-01 11:45:03

dhad-3.0.13 fit regular13 -t s -m 203 –qsub log-2010-01-01 11:45:08

dhad-3.0.13 fit regular13 -t s -m 204 –qsub log-2010-01-01 11:45:15

dhad-3.0.13 fit regular13 -t s -m 205 –qsub log-2010-01-01 11:45:20

Book the plots … OK.

dhad-3.0.13 web plots regular13 -t s  

Compare to the original… OK.

dhad-3.0.13 table compare yields signal 7.06 regular13

Fit the deviations … OK.

dhad-3.0.13 plot deviations compare yields signal 7.06 regular13 --set headname=EvtFac,fit=L

Add to the grand comparison … OK.

dhad-3.0.13 table combine compare_yields_signal_7dot06_regular_all chisq gaus 

Reply to Anders … OK.

Reply from Anders:

that is good; but we still need to sort out a few 'details' about the beam energies etc.
Right before the holidays we scribbled down on a piece of paper the beam energies,
virtual photon energies and the fitted D masses, and D mass from the evt.pdl file.
Could you add this information to the 'Grand Comparison Table' web page. After I have
this I will suggest some further tests/checks to do.

Add info … OK. Reply to Anders … OK.

Reply from Anders:

could you add also the 'EvtGen', 'PDL&DEC', and 'EBeam' sample to the table you just added.
But I think that we should also refit the 'PDL&DEC' and 'EBeam' samples with the new fitting
code.

After doing this I think we should look at the data to see if the way we have the MC set up is
mimicking the data. In particular we should look at the position of the end point in mBC and
where the D mass peak from the fit is located. Some of this can be seen from plots that you
already have. I will take a look.

As you discussed in a DHad meeting a few weeks ago 
(https://www.lepp.cornell.edu/~xs32/private/DHad/rel-7.06#sec-3.2)
you found substantial differences in the yields in the new data for some modes with respect to
others. In particular, there were more pi0 and K0S in the new data. There were some changes
made to the pi0 selection, and possibly also K0S. I do not know if these changes would explain
what you see in the data. But, I think that you should go ahead and generate some MC, using
the 'Default' procedure for the new runs. The important thing here is to use the right release
for pass2 and Dtagging. Then we can compare the efficiencies between the 'old' 281/pb
samples and the new MC samples you generate.

Document the EvtGen with new code in anther table … OK.

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.14 dhad/src
cd 3.0.14

Update DHad.py … OK.

cd $dhad/9.03/dat/signal
ln -s regular5 regular14

dhad-3.0.14 yield regular14 -t s ... OK.
dhad-3.0.14 fit regular14 -t s -m 201 OK.

dhad-3.0.14 fit regular14 -t s -m 0 –qsub log-2010-01-04 10:28:05

dhad-3.0.14 fit regular14 -t s -m 1 –qsub log-2010-01-04 10:28:11

dhad-3.0.14 fit regular14 -t s -m 3 –qsub log-2010-01-04 10:28:17

dhad-3.0.14 fit regular14 -t s -m 200 –qsub log-2010-01-04 10:28:23

dhad-3.0.14 fit regular14 -t s -m 201 –qsub log-2010-01-04 10:28:29

dhad-3.0.14 fit regular14 -t s -m 202 –qsub log-2010-01-04 10:28:35

dhad-3.0.14 fit regular14 -t s -m 203 –qsub log-2010-01-04 10:28:40

dhad-3.0.14 fit regular14 -t s -m 204 –qsub log-2010-01-04 10:28:45

dhad-3.0.14 fit regular14 -t s -m 205 –qsub log-2010-01-04 10:28:52

Book the plots … OK.

Compare with the original… OK.

Fit the deviations … OK.

Add to the new grand comparison table … OK.

cd ~/work/CLEO/analysis/DHad/src
cvs co -d 3.0.15 dhad/src

Update DHad.py using the same as rel dynamically … OK.

Update the setup.sh … OK.

cd $dhad/9.03/dat/signal
ln -s regular3 regular15

dhad-3.0.15 yield regular15 -t s  ... OK.

dhad-3.0.15 fit regular15 -t s -m 204  ... OK.

dhad-3.0.15 fit regular15 -t s -m 0 –qsub log-2010-01-04 11:39:12

dhad-3.0.15 fit regular15 -t s -m 1 –qsub log-2010-01-04 11:39:23

dhad-3.0.15 fit regular15 -t s -m 3 –qsub log-2010-01-04 11:39:28

dhad-3.0.15 fit regular15 -t s -m 200 –qsub log-2010-01-04 11:39:33

dhad-3.0.15 fit regular15 -t s -m 201 –qsub log-2010-01-04 11:39:38

dhad-3.0.15 fit regular15 -t s -m 202 –qsub log-2010-01-04 11:39:44 No CPU

• dhad-3.0.15 fit regular15 -t s -m 202 –qsub log-2010-01-04 12:00:03

dhad-3.0.15 fit regular15 -t s -m 203 –qsub log-2010-01-04 11:39:49

dhad-3.0.15 fit regular15 -t s -m 204 –qsub log-2010-01-04 11:39:55

dhad-3.0.15 fit regular15 -t s -m 205 –qsub log-2010-01-04 11:40:01

Book plots … OK.

Compare with the original… OK.

Fit the deviations … OK.

Add to the new grand comparison table … OK.

Reply to Anders … OK.

Message from Anders:

is there some problem with the 'mean' and 'sigma' errors for the PDL&DEC fit? They
are very different than the other fits. Other than this it seems like the EBeam only
change was not enough to get a 'good' result. (Xin, it would be very useful for you to
try to analyze the results yourself and summarize conclusions as far as you can.)

Have you tried generating MC for the new data sets?

Check the deviation value … OK. (Used the wrong commnad PDL&DEC -> PDL_DEC)

Update the new grand table … OK.

Write summary … done.

Upate the setdhad … OK.

setdhad 3.0.16 
cd $dhad/9.03/dat/signal
ln -s regular2 regular16 

dhad-3.0.16 yield regular16 -t s  ... OK.

dhad-3.0.16 fit regular16 -t s -m 204  OK.

dhad-3.0.16 fit regular16 -t s -m 0 –qsub log-2010-01-05 17:04:14

dhad-3.0.16 fit regular16 -t s -m 1 –qsub log-2010-01-05 17:04:21

dhad-3.0.16 fit regular16 -t s -m 3 –qsub log-2010-01-05 17:04:27

dhad-3.0.16 fit regular16 -t s -m 200 –qsub log-2010-01-05 17:04:35

dhad-3.0.16 fit regular16 -t s -m 201 –qsub log-2010-01-05 17:04:40

dhad-3.0.16 fit regular16 -t s -m 202 –qsub log-2010-01-05 17:04:45

dhad-3.0.16 fit regular16 -t s -m 203 –qsub log-2010-01-05 17:04:51

dhad-3.0.16 fit regular16 -t s -m 204 –qsub log-2010-01-05 17:04:56

dhad-3.0.16 fit regular16 -t s -m 205 –qsub log-2010-01-05 17:05:01

Book plots … OK.

Compare with the original… OK.

Fit the deviations … OK.

Add to the new grand comparison table … OK.

Write summary … done.

Print out the D+ decay in the 20050525_MCGEN release:

cd $dhad/lib/python
python decparser.py       
(Cmd) readfile  /nfs/cleo3/Offline/rel/20050525_MCGEN/data/DECAY.DEC
(Cmd) dump D+

Save the output dp2005.txt.

(Cmd) readfile  /nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC
Exception: No decay model specified: 0.3504     J/psi  pi+ pi-                VVPIPI_WEIGHTED;

Add this model… OK.

Still problem.

Use the development version:

python decparser-development.py 
(Cmd) readfile  /nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC

*** Unknown syntax: CopyDecay phi_A phi
*** Unknown syntax: CopyDecay f_0_A f_0
*** Unknown syntax: CopyDecay f'_0_A f'_0
*** Unknown syntax: CopyDecay f_2_A f_2
copying
copying
copying
copying

(Cmd) dump D+

Save the output as dp2008.txt.

Compare the two files …

dhad-3.0.16 table diff dec dp2005 dp2008 common 
dhad-3.0.16 table diff dec dp2005 dp2008 1unique
dhad-3.0.16 table diff dec dp2005 dp2008 2unique

• Check for D0 particle

  cd $dhad/lib/python
  python decparser-development.py 
  (Cmd) readfile  /nfs/cleo3/Offline/rel/20050525_MCGEN/data/DECAY.DEC
  dump D0 
  

  Save the output as d02005.txt.

  (Cmd) readfile /nfs/cleo3/Offline/rel/20080624_MCGEN/data/DECAY.DEC
  

  Save the output as d02008.txt.

  Compare the two files:

  dhad-3.0.16 table diff dec d02005 d02008 common 
  

  Table link. Length 72.

  dhad-3.0.16 table diff dec d02005 d02008 1unique
  

  Table link. Length 7.

  dhad-3.0.16 table diff dec d02005 d02008 2unique
  

  Table link. Length 56.

dhad-3.0.16 table diff pdl 2005 2008 common 

See link.

Select the related particles:

dhad-3.0.16 table diff pdl 2005 2008 common selected

See link.