Difference between revisions of "Solid eventgenerator"

From Hall A Wiki
Jump to: navigation, search
(general note)
(problem)
Line 220: Line 220:
 
== problem ==
 
== problem ==
  
the rate on He3 cell glass window seems overestimated
+
the rate on He3 cell glass window seems underestimated
  
window  has Z=17 A=35 lumi_nuclei=0.054e36Hz/cm^2
+
window  has Z=17 A=35 lumi_nuclei=0.054e36Hz/cm^2
https://jlabsvn.jlab.org/svnroot/solid/evgen/eicRate_20101102/output/input_solid_SIDIS_He3_window_upstream.dat
+
https://jlabsvn.jlab.org/svnroot/solid/evgen/eicRate_20101102/output/input_solid_SIDIS_He3_window_upstream.dat
  
For files Rakitha made at /work/halla/solid/evgen/solid_bggen/lund_format/10k_lundfiles/SIDIS_He3
+
For files Rakitha made at /work/halla/solid/evgen/solid_bggen/lund_format/10k_lundfiles/SIDIS_He3
pi+ for He3 of "hallD_pion_p_3He_10k_1.lund", the rate factor at the end of header line is 7704
+
pi+ for He3 of "hallD_pion_p_3He_10k_1.lund", the rate factor at the end of header line is 7704
pi+ for one window of "hallD_pion_p_DST_Winu_10k_1.lund", the same factor is 230
+
pi+ for one window of "hallD_pion_p_DST_Winu_10k_1.lund", the same factor is 230
the ratio is 7704/230=33
+
the ratio is 7704/230=33
Assuming pi+ crossection is same for neutron and proton, this ratio is only proportional to nucleon luminosity ratio
+
Assuming pi+ crosssection is same for neutron and proton, this ratio is only proportional to nucleon luminosity ratio
  
nucleon luminosity ratio between 3He and one window should 1.6  
+
nucleon luminosity ratio between 3He and one window should 1.6  
refer to https://hallaweb.jlab.org/wiki/index.php/SoLID_full_simulation_and_file_sharing#luminosity_and_radiation_thickness
+
refer to https://hallaweb.jlab.org/wiki/index.php/SoLID_full_simulation_and_file_sharing#luminosity_and_radiation_thickness
  
So there is a discrepancy of factor 21=33/1.6
+
So there is a discrepancy of factor 21=33/1.6
  
Even adding Z/A is 2/3 for He3 gas and 1/2 for window and pi+ crossection is actually different for neutron and proton, it should not be so different
+
Even adding Z/A is 2/3 for He3 gas and 1/2 for window and pi+ crosssection is actually different for neutron and proton, it should not be so different
  
 
== desired feature ==
 
== desired feature ==

Revision as of 18:10, 21 May 2018

general note

location

https://jlabsvn.jlab.org/svnroot/solid/evgen/

normalization

General rule is to use (crossection*luminosity*phasespace/Ntrials) as weight for events, then sum events with weight in any kinematic region to get rate in Hz in that region.

Ntrials is equal to Nevent if no trial is rejected within the phasespace.

events in one file should use Ntrials/Nevent for that file, then when sum events from many files with equal number of events, it needs to divide number of files to get correct normalization for example, there are 100 files, each file has 10000 events, the rate in each file has normalized by 10000, then add 100 files, the final result needs normalization by 10000*100=1e6, so the weight needs to divide by number of file 100

It's a good practice to put weight as last number in lund file header line, it will be transferred into in GEMC output as var8 in header bank.

inclusive event generator

solid_inclusive_e

https://jlabsvn.jlab.org/svnroot/solid/evgen/solid_inclusive_e

[1], Yuxiang's talk

see "readme"

SoLID inclusive electron generator

This is a generator to generate inclusive electrons in the (Ep, theta) phase space.

It's wriiten for JLab HallA SoLID, but it can have general use too.

The process includes QE + resonance + DIS for nucleus target with Z protons and A atoms.

The W<3 GeV region uses Peter Bosted fit

the W>3 GeV region uses world PDF sets, the LHAPDF6 interface is used

pure C/C++ code, using CMake compiler

single_rate

see "readme"

https://jlabsvn.jlab.org/svnroot/solid/evgen/single_rate/

eicRate

https://jlabsvn.jlab.org/svnroot/solid/evgen/eicRate_20101102/

What it can do

It can generate:

  • <math>e^- </math> DIS events
  • <math>\pi^+ , \pi^-, \pi^0, K^+, K^-, K_s, p</math> with cross section given by the WISER fits. The <math>\pi^0</math> then decay in two photons. The two photons output are in the tree as pi0_g1 and pi0_g2.
  • <math>e^- </math> ELASTIC events
  • The output is then written also in LUND and SOLLUND format (the decay products will be part of the same event)
  • The vertex position is decided in an uniform way randomly inside the raster. For the two decayed <math>\gamma</math>s from the <math>\pi^0</math> the vertex is shifted by a displacement determined selecting randomly the decay time. If the radius is set to "0.0" in the input file, the vertex will not be generated

see "readme" for details

The input file

the input file it commands the event generator with information in common to every process. an example can be found at https://jlabsvn.jlab.org/svnroot/solid/evgen/eicRate_20101102/output/input.dat The flags are (they need to be in the same order as in the example)

  • nevt : Number of events to be generated (for example 25000)
  • nprint : Number of events every which to print and output on screen (for example 1000000)
  • lumin  : Luminosity for nuclei (not for nucleon) (for example 1.0e37 Hz/cm^2)
  • runtime  : Runtime (for example 48.0 hours)
  • e-_en  : Beam energy (for example 6.0 GeV)
  • ion_en : Energy of the ions of the target (for example 0.938 GeV)
  • ion_m : Mass of the ions of the target (for example 0.938 GeV)
  • ion_Z : Number of protons in the target (for example 1)
  • ion_N : Number of neutrons in the target (for example 1)
  • dens : Density of the target (g/cm^3): if 0.0, will try to search one in his own database. If you rather than want to use your own (or it is not in the database), specify it here (for example 0.162 g/cm^3)
  • length : Length of the target (cm): if 0.0, will try to search one in his own database. If you rather than want to use your own (or it is not in the database), specify it here (for example 40 cm)
  • lenx : size in X of the raster (cm , it is assumed to be of cylindrical shape): if 0.0 The vertex will not be generated (for example 0.2 cm)
  • leny : size in Y of the raster (cm , it is assumed to be of cylindrical shape): if 0.0 The vertex will not be generated (for example 0.2 cm)
  • model : Model for the cross section used: 1= electron DIS ; 2=pi+ ; 3=pi- ; 4=pi0 ; 5= electron ELASTIC ( for example 1)
  • output : Output format: 1=root ; 2=root+LUND ' 3=root+SOLLUND (for example 3)

Output file

The output file name is specified at the time of execution of eicRate. If not specified the default 'output.root' will be used. It is also possible to have text output in lund format in parallel of the root format

  • LUND format
    • used for input into GEMC. flag 'output 2' in the inputfile (a script will create another file, named changing the string "root" in the output name with "lund", so by default 'output.lund'
    • GEMC 2.x take all entries in 1st row as they are into GEMC output bank "header"
    • GEMC 1.x doesn't have header bank so no 1st row entry will pass into GEMC output, the workaround is to use the information from the LUND file or from eicRate root tree output, pay special attention the make sure the event index is right.
    • the lund format is at [2], the entries defined here are
     OUT << "1" << " \t " << Wprate  << " \t " << Wmrate  << " \t " << "0"  << " \t " << "0" << " \t "  << x << " \t " << y  << " \t " << W  << " \t " << Q2  << " \t " << rate << endl;
     OUT << " \t " << "1" << " \t " << charge << " \t " << "1" << " \t " << particle_id << " \t " << "0" << " \t " << "0" << " \t " << px << " \t " << py << " \t " << pz << " \t " << Ef << " \t " << mass << " \t " << p_vertex.X()  << " \t " << p_vertex.Y() << " \t " << p_vertex.Z() << endl;
  • SOLLUND format
    • this is an alternative workaround to overcome the shortcoming of GEMC 1.x
    • flag 'output 3' in the inputfile (a script will create another file, named changing the string "root" in the output name with "sollund", so by default 'output.sollund'
    • based on LUND format, except one more entry "weight" is added between "Number of particles" and "Number of target nucleons"
    • SOLLUND file can be as input for solgemc, the "weight" will be taken into output.

Generated events

2.5M events for 4.4GeV, 5.5GeV, 6.6GeV, 11.0GeV at http://hallaweb.jlab.org/12GeV/SoLID/download/event_gen/test_generator.tgz

Conversion from root to lund format

Following is shown a tool to convert and play with the output of the event generator https://jlabsvn.jlab.org/svnroot/solid/evgen/root_to_lund/


DEFINITION GEANTINO

     Arguments for constructor are as follows 
                  name             mass          width         charge
                2*spin           parity  C-conjugation
             2*Isospin       2*Isospin3       G-parity
                  type    lepton number  baryon number   PDG encoding
                stable         lifetime    decay table 
                shortlived      subType    anti_encoding
                 name,           0.0*MeV,       0.0*MeV,         0.0, 
                 0,                    0,             0,          
                 0,                    0,             0,             
                 "geantino",           0,             0,           0,
                 true,               0.0,          NULL,
                 false,        "geantino",            0
               

DEFINITION CHARGED GEANTINO

                name,         0.0*MeV,       0.0*MeV,   +1.*eplus, 
                   0,               0,             0,          
                   0,               0,             0,             
          "geantino",               0,             0,           0,
                true,             0.0,          NULL,
                false,     "geantino",             0


ROOT TO LUND CONVERSION


I modified my root to lund conversion so that one can filter the data 
based on the angle of scattering of the electron.
I have also put the option to use a "lund format" file as input for 
filtering based on the angle (you have these files right now).
There is also an option to have in the output a geantino or a charged geantino, rather than the electron.


          

If you running without flags you get this message (how to use it):

 root2lund : This Program translate the output from eicRate in LUND format and Filter the scattered electron angles
 Usage: root2lund -o outputfile -i inputfile [-th_min theta_min] [-th_max theta_max] [-ph_min phi_min] [-ph_max phi_max] [-l 1-0] [-g 2-1-0]
     -o outputfile     : output file name (example pluto.lund)  
     -i inputfile      : input file name (example pluto.root)  
     -h help, print this message 
   [optional] 
     -th_min theta_min : specify theta minimum for scattered electron 
     -th_max theta_max : specify theta maximum for scattered electron 
     -ph_min phi_min   : specify phi minimum for scattered electron 
     -ph_max phi_max   : specify phi maximum for scattered electron 
     -l 1-0            : specify format input file ( lund-> 1 (just angle filtering); root->0 (default) )
     -g 2-1-0          : specify if particle in output is a geantino ( geantino-> 1 ; charged geantino-> 2 ; normal->0 (default) )

solid_bggen

info

Based on bbgen from halld to generate dominant exclusive events of photonproduction on proton, electron production on any nuclear target is added by assuming EPA for virtual photons and bremsstrahlung for real photons. scattered electron is not included in the output.

Rakitha's note https://solid.jlab.org/cgi-bin/private/ShowDocument?docid=3

Rakitha's slides in time order [3][4][5]

HallD note http://hallaweb.jlab.org/12GeV/SoLID/download/sim/talk/trigger-review-2008.pdf

source code https://github.com/JeffersonLab/remoll_solid/tree/master/generators/halld/

some lund file generated /work/halla/solid/evgen/solid_bggen

Some information and instructions from Rakitha:

The last entry in the lund file contains total rate divided by the total events in the file. So this number is small if the file contain large no.of events. I think the two files you were comparing may have been 10k (old file) and 100K (new file). The variable fEvQ2 which is the one before the last entry stores the total absolute rate for the particle. This is per Zhiwen's request. So this number can be compared between lund files with different event sizes.

I wanted to give you the steps I followed to generate these files. Here they are, modify the fort.15 macro file to set no.of events and random number value then run bggen using "./bggen" 1. First run the hall D code and this will generate a PAW file with default file name, "bggen.nt" 2. Convert the PAW file to root format using h2root command for example "h2root bggen.nt /home/rakithab/Simulation_Analysis/Generators/HallD/ElectroProduction/FixRate_10k_rootfiles/bggen_LH40cm_output_300k_1.root" 3. Then I have a script called HallD_gen_lund.cc available in remoll repository, https://github.com/JeffersonLab/remoll_solid/tree/master/generators/halld/scripts to generate lund files. 4. For example "./HallD_gen_lund /home/rakithab/Simulation_Analysis/Generators/HallD/ElectroProduction/FixRate_10k_rootfiles/bggen_LH40cm_output_300k_8.root 1 2 1 " you can see what these options are in the code.

The final step will create 6 different lund files.

Compile and run solid_bggen on the current ifarm environment (centos7)

Previously, compiled version with instruction /group/solid/apps/evgen/solid_bggen (it only works on ifarm1101 with centos6.5 for now because of dependence on /site/cernlib/i386_rhel6)

here is new instruction by Ye Tian on centos7

  • 1) cp -r /group/solid/apps/evgen/solid_bggen target directory
  • 2) cd target directory/solid_bggen/bggen/
  • 3) cp -r /w/halla-scifs17exp/solid/tianye/group_bggen/bggen/build_ifarm ./

Here, within the /build_ifarm/ directory, the copied "/code/" directory contains all the adjusted files, which are needed to compile the "bggen" on current ifarm machine. Basically, Jixie commanded out all the HallD tracking software "HDDM", which are not needed for our purpose.

  • 4) source ifarm.bashrc or ifarm.cshrc, depends on the shell you preferred.
  • 5) cd ../run/, here you can modify file "fort.15" to adjust RNDMSEQ, TRING, and ... parameters to satisfy your purpose.
  • 6) ../build_ifarm/hdgen.Linux.x86_64.exe ---------run the code
  • 7) h2root bggen.nt--------convert to root file
  • 8) cd ../../scripts/ -------- to the directory to generate corresponding "lund" files
  • 9) make --------- use HallD_gen_lund to create "lund" files to feed to GEMC simulation.
  • 10) ./HallD_gen_lund ../bggen/run/bggen.root 1 1 1 -------example to generate "lund" files. The explanation of "1 1 1 " is shown in HallD_gen_lund.cc file.

If you want to submit the jobs on ifarm, this is an example job submission scrip: /w/halla-scifs17exp/solid/tianye/group_bggen/bggen/build_ifarm/submitjob_bggenpi0

  • Notice

For current version "bggen", you have to change target length, radiation length, and beam current in the file "/build_ifarm/code/bremsbeam_ini.F" and recompile the code. The more user friendly version is under working by Jixie.

  • "Contact"

If you any question on compiling the "bggen" on ifarm, just send email to Ye Tian (tianye@jlab.org)

problem

the rate on He3 cell glass window seems underestimated

window  has Z=17 A=35 lumi_nuclei=0.054e36Hz/cm^2
https://jlabsvn.jlab.org/svnroot/solid/evgen/eicRate_20101102/output/input_solid_SIDIS_He3_window_upstream.dat
For files Rakitha made at /work/halla/solid/evgen/solid_bggen/lund_format/10k_lundfiles/SIDIS_He3
pi+ for He3 of "hallD_pion_p_3He_10k_1.lund", the rate factor at the end of header line is 7704
pi+ for one window of "hallD_pion_p_DST_Winu_10k_1.lund", the same factor is 230
the ratio is 7704/230=33
Assuming pi+ crosssection is same for neutron and proton, this ratio is only proportional to nucleon luminosity ratio
nucleon luminosity ratio between 3He and one window should 1.6 
refer to https://hallaweb.jlab.org/wiki/index.php/SoLID_full_simulation_and_file_sharing#luminosity_and_radiation_thickness
So there is a discrepancy of factor 21=33/1.6
Even adding Z/A is 2/3 for He3 gas and 1/2 for window and pi+ crosssection is actually different for neutron and proton, it should not be so different

desired feature

Have a complete generator which can output both scattered electron and all hadrons

it would be very useful to study fake coincidence among detectors in single particle trigger and more complicated situation in multiple particles coincidence trigger

1. add scattered electron into output into solid_bbgen, maybe by EPA (Yuxiang and Rakitha's conclusion is it's not possible)

2. Follow bbgen approach to combine electron resonance model and electron pythia (haven't tried)

SIDIS event generator (outdated)

see readme

https://jlabsvn.jlab.org/svnroot/solid/evgen/sidis_model/

JPsi

see "readme"

https://jlabsvn.jlab.org/svnroot/solid/evgen/JPsi

genTCS

see "readme"

https://jlabsvn.jlab.org/svnroot/solid/evgen/genTCS