cepc / cepcsw Goto Github PK

As @vvolkl mentioned in key4hep/k4FWCore#18, the FWCore is renamed to k4FWCore. So the migration is necessary for us when the k4FWCore is ready for use.

Here is the task lists:

• test with the branch https://github.com/vvolkl/K4FWCore/tree/rename and give feedback to @vvolkl.
• Deploy the k4FWCore into the CEPCSW's LCG stack
• Test with both LCG and k4spack stack.

My idea is that the library names of FWCore and k4FWCore are different, so I can deploy both version in the same stack. After the migration is done, just remove the FWCore.

If you also encounter the problem that the drift chamber cannot be visualized, there are two solutions below：
First, use the terminal that comes with the MacOS system and follow the normal steps;
Second, use the command /cvmfs/container.ihep.ac.cn/bin/hep_container shell Centos7 to enter the container, and then proceed.
Both of the above solutions can solve this problem, I hope it can help everyone.

Currently, cepcsw cannot be built in the nightlies because AIDASoft/podio#193 means that edm4hep interfaces now should use the Const* types.

Unfortunately, the typenames will change again soon (AIDASoft/podio#205), so maybe you prefer to wait until after that one is merged with fixing this issue, but it will be necessary in order to make a new release of the full key4hep software.

The current nightly builds don't include cepcsw until this issue is fixed, but should have all the dependencies and can be used for testing:

source /cvmfs/sw-nightlies.hsf.org/key4hep/setup.sh

Please update the quickstart.md according to the example :
https://indico.ihep.ac.cn/event/12341/session/5/contribution/3/material/slides/0.pdf

• Require "Fork" with "user"
• git clone https://github.com/user/CEPCSW.git
• Add the remote commands:
• git remote add cepc https://github.com/cepc/CEPCSW.git
• git remote update
• git merge cepc/master

Both @fucd and I found that the CI does not run sometimes due to some API changes between Github and Travis-CI. The travis-ci.org will be closed soon, so we should migrate the CI to travis-ci.com

The users need to know the processes happened to the primary particles. In EDM4hep, there are several flags (see https://github.com/key4hep/EDM4hep/blob/master/edm4hep.yaml#L136). All these flags should be set in detector simulation.

K4-spack provides a complete software stack using Spack. The motivation of this issue is to compile CEPCSW with spack.

Setup the pre-compiled key4hep stack:

source /cvmfs/sw.hsf.org/key4hep/setup.sh

• In CEPCSW, there are some hard coded variables defined in CMakeLists.txt, so the first step is to remove them.

• swicth GearMgr to GeoSvc
  • parameters interface (#52 #68 )
  • surface interface (DDKalDet)

The setup and build process should be wrapped into two shell scripts (to simplify the maintaining work, we use bash as the default one):

setup.sh

build.sh

Then update the README.md.

An example can be found here:

https://github.com/cepc/hig2zz

For DC case. It could be helpful if there is a flag to specifiy the closest SimTrackerHit which contribute to the TrackerHit

During the track fitting the direction of the silicon detector plane is needed if detector is used as planer measurement. So the function to get geometry of silicon detectros through CellID is needed. But it have lower priority than to get correct truth hit on track.

See key4hep/key4hep-spack#114

• Create a directory under Detector (See commit 4f00fcc)
• Calorimeter (@LinghuiWuIHEP)
  • See PR #32
• Drift Chamber
  • See #18

Develop the silicon+drift chamber track fitting.

• detector description (DD4hep)
  • The dimensions are defined as the constants (See commit 2d3a664)
  • Envelope for the Drift Chamber
    • radii: 235 mm, 1716 mm
    • z: -2225 mm, 2225 mm
  • inner chamber
    • radii: 235 mm, 909 mm
    • z: -2225 mm, 2225 mm
  • outer chamber
    • radii: 1085 mm, 1716 mm
    • z: -2225 mm, 2225 mm
  • silicon between inner and outer chamber
  • B-Field: 3 Tesla, uniform: See commit a663edc
• detector response (Geant4 Sensitive Detector)
  • register the Tracker SD for Drift Chamber as the first step.
  • need a specific SD for Drift Chamber to simulate: (See PR #40)
    • the drift distance and time
    • dE/dx Tool Interface (See PR #40)
      • Check the units. ⚠️ The units for the dE/dx follows the Geant4 convention.
  • Need a DD4hep Segmentation to calculate the CellID
• digitization
• Definition of the cellID
  • system: 8bit
  • chamber: 1bit (0: inner, 1: outer)
  • layer: 7bit (for inner: 67 layers, for outer: 63 layers)

Progress:

• PR #13 : a very simple implementation of two tubes.

In the DD4hep based ECAL, the readout is defined as following:

  <readouts>
    <readout name="EcalBarrelCollection">
      <segmentation type="MegatileLayerGridXY"/>
      <id>system:5,module:3,stave:4,tower:5,layer:6,wafer:6,cellX:32:-16,cellY:-16</id>
    </readout>
  </readouts>

In Mokka, the decoder is defined as:

#define SHIFT_S_64 0 //Stave = 3 bits
#define SHIFT_M_64 3 //Module = 3 bits
#define SHIFT_K_64 6 //Layer = 6 bits
#define SHIFT_I_64 12 //Cell X index = 16 bits
#define SHIFT_Z_64 28 //Guard-ring zone = 3 bits
#define SHIFT_1_64 31 //Sign = 1 bit
#define SHIFT_J_64 0 //Cell Z index = 16 bits
#define SHIFT_P_64 16 //Provision = 15 bits
#define SHIFT_2_64 31 //Sign = 1 bit

#define MASK_S_64 (unsigned int) 0x00000007
#define MASK_M_64 (unsigned int) 0x00000038
#define MASK_K_64 (unsigned int) 0x00000FC0
#define MASK_I_64 (unsigned int) 0x0FFFF000
#define MASK_Z_64 (unsigned int) 0x70000000
#define MASK_1_64 (unsigned int) 0x80000000
#define MASK_J_64 (unsigned int) 0x0000FFFF
#define MASK_P_64 (unsigned int) 0x7FFF0000
#define MASK_2_64 (unsigned int) 0x80000000

Encoder64::Encoder64(void):VEncoder(true) {
        idString="S-1:3,M:3,K-1:6,I:16,GRZone:3,J:32:16";
}

Hi @mirguest @fucd ,

For the calorimeter, the steps of Geant4 simulation in the same cell should be merged before filling to SimCalorimeterHit. Where is the merging implemented?

Cheers,
Linghui

While implement CepC beam pipe (#28 and PR #82 ), the solid TGeoScaledShape is needed for CrotchAsymUp and CrotchAsymDn types. But current DD4hep version used for CEPCSW has a bug on the solid converter. DD4hep has fixed it in its PR #756. Once Key4hep implement this update, the beam pipe geometry will work fully, and Scale solid (new addition in AIDASoft/DD4hep#756) will be valid replacing with directive usage of TGeoScaledShape. Now, the CrotchAsymUp and CrotchAsymDn sections are commented.

https://gitlab.cern.ch/key4hep/k4-deploy/-/jobs/13243984

probably was introduced yesterday.

We find some times the alg ClupatraAlg will crash

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00002b4af26c489e in waitpid () from /lib64/libc.so.6
#1  0x00002b4af26564e9 in do_system () from /lib64/libc.so.6
#2  0x00002b4affb430ba in TUnixSystem::StackTrace() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.20.02-d9e99/x86_64-slc6-gcc8-opt/lib/libCore.so
#3  0x00002b4affb45914 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.20.02-d9e99/x86_64-slc6-gcc8-opt/lib/libCore.so
#4  <signal handler called>
#5  0x00002b4b1ceb17aa in podio::ObjBase::release (this=0x1a174bf0) at /cvmfs/cepcsw.ihep.ac.cn/prototype/releases/externals/97.0.2/podio/include/podio/ObjBase.h:27
#6  podio::ObjBase::release (this=0x1a174bf0) at /cvmfs/cepcsw.ihep.ac.cn/prototype/releases/externals/97.0.2/podio/include/podio/ObjBase.h:24
#7  edm4hep::ConstTrackerHit::~ConstTrackerHit (this=<optimized out>, __in_chrg=<optimized out>) at /cvmfs/cepcsw.ihep.ac.cn/prototype/releases/externals/97.0.2/EDM4hep-src/edm4hep/src/TrackerHitConst.cc:42
#8  0x00002b4b2e96c288 in std::_Rb_tree<edm4hep::ConstTrackerHit, std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*>, std::_Select1st<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> >, std::less<edm4hep::ConstTrackerHit>, std::allocator<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> > >::_M_erase(std::_Rb_tree_node<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> >*) () from /workfs/higgs/fangwx/fork_TrackerEcal_20201129/CEPCSW/build.97.0.2.x86_64-slc6-gcc8-opt/lib/libTracking.so
#9  0x00002b4b2e96c27b in std::_Rb_tree<edm4hep::ConstTrackerHit, std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*>, std::_Select1st<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> >, std::less<edm4hep::ConstTrackerHit>, std::allocator<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> > >::_M_erase(std::_Rb_tree_node<std::pair<edm4hep::ConstTrackerHit const, nnclu::Element<clupatra_new::ClupaHit>*> >*) () from /workfs/higgs/fangwx/fork_TrackerEcal_20201129/CEPCSW/build.97.0.2.x86_64-slc6-gcc8-opt/lib/libTracking.so
#10 0x00002b4b2e95c924 in ClupatraAlg::execute() () from /workfs/higgs/fangwx/fork_TrackerEcal_20201129/CEPCSW/build.97.0.2.x86_64-slc6-gcc8-opt/lib/libTracking.so
#11 0x00002b4aff725ced in Gaudi::details::LegacyAlgorithmAdapter::execute(EventContext const&) const () from /cvmfs/cepcsw.ihep.ac.cn/prototype/releases/externals/97.0.2/Gaudi/lib/libGaudiCoreSvc.so

Hi,
The production cut in xml seems doesn't work.

 >> 320    /tmp/gitlab-runner/spack-stage/spack-stage-cepcsw-commit.019f1a984e
            9c64459f2a2d86bb138d2e671063ef-bywzexlvxcuvuwdw5bc2wixf4jevlszh/spa
            ck-src/Detector/DetSegmentation/src/GridDriftChamber.cpp:148:1: err
            or: expected constructor, destructor, or type conversion before '}'
             token
     321     }
     322     ^
  >> 323    make[2]: *** [Detector/DetSegmentation/CMakeFiles/DetSegmentation.d
            ir/src/GridDriftChamber.cpp.o] Error 1
     324    make[2]: Leaving directory `/tmp/gitlab-runner/spack-stage/spack-st
            age-cepcsw-commit.019f1a984e9c64459f2a2d86bb138d2e671063ef-bywzexlv
            xcuvuwdw5bc2wixf4jevlszh/spack-build-bywzexl'
  >> 325    make[1]: *** [Detector/DetSegmentation/CMakeFiles/DetSegmentation.d
            ir/all] Error 2
     326    make[1]: *** Waiting for unfinished jobs....
     327    cd /tmp/gitlab-runner/spack-stage/spack-stage-cepcsw-commit.019f1a9
            84e9c64459f2a2d86bb138d2e671063ef-bywzexlvxcuvuwdw5bc2wixf4jevlszh/
            spack-build-bywzexl/Analysis/TotalInvMass && /cvmfs/sw.hsf.org/spac
            kages/linux-centos7-x86_64/gcc-8.3.0/cmake-3.18.4-u6ngummxdgl74t3g3
            wearb2sae7mxntr/bin/cmake -E create_symlink /tmp/gitlab-runner/spac
            k-stage/spack-stage-cepcsw-commit.019f1a984e9c64459f2a2d86bb138d2e6
            71063ef-bywzexlvxcuvuwdw5bc2wixf4jevlszh/spack-build-bywzexl/Analys
            is/TotalInvMass/libTotalInvMass.so /tmp/gitlab-runner/spack-stage/s
            pack-stage-cepcsw-commit.019f1a984e9c64459f2a2d86bb138d2e671063ef-b
            ywzexlvxcuvuwdw5bc2wixf4jevlszh/spack-build-bywzexl/.plugins/libTot
            alInvMass.so

As far as I can see this is due to the breaking change introduced in AIDASoft/DD4hep#817. I think the solution is to just use DECLARE_SEGMENTATION instead of REGISTER_SEGMENTATION, but @andresailer may comment

Hi @fucd , please coordinate with Fangyi. Thanks!
Tao

Need simulate the ionization process in drift chamber.

Crash when use edm4hep::MCParticleCollection exist() where MCParticleCollection is exist and can be read. Following are the error message.

 *** Break *** segmentation violation                                          
                                                                               
                                                                             
                                                                               
===========================================================                    
There was a crash.                                                             
This is the entire stack trace of all threads:                                 
===========================================================                    
#0  0x00007f3f277d846c in waitpid () from /lib64/libc.so.6                     
#1  0x00007f3f27755f62 in do_system () from /lib64/libc.so.6                   
#2  0x00007f3f18cac603 in TUnixSystem::StackTrace() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#3  0x00007f3f18caef25 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#4  <signal handler called>                                                    
#5  0x00007f3f18c2011d in TObjArray::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#6  0x00007f3eef6c0202 in TGeoVolume::~TGeoVolume() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#7  0x00007f3eef6c0429 in TGeoVolume::~TGeoVolume() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#8  0x00007f3f18c20128 in TObjArray::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#9  0x00007f3eef64cea2 in TGeoManager::~TGeoManager() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#10 0x00007f3eef64d229 in TGeoManager::~TGeoManager() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#11 0x00007f3f18c1a2c8 in TList::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#12 0x00007f3f18b5ff4f in TROOT::~TROOT() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#13 0x00007f3f2774cce9 in __run_exit_handlers () from /lib64/libc.so.6         
#14 0x00007f3f2774cd37 in exit () from /lib64/libc.so.6                        
#15 0x00007f3f287d16e9 in Py_Exit (sts=sts                                     
entry=6) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pylifecycle.c:2292
#16 0x00007f3f287d94b1 in handle_system_exit () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:636
#17 0x00007f3f287d990f in handle_system_exit () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:683
#18 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars                         
entry=1) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:646
#19 0x00007f3f287d9a5a in PyErr_Print () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:542
#20 0x00007f3f287dab98 in PyRun_SimpleFileExFlags (fp=fp                       
entry=0x9bf6a0, filename=<optimized out>, closeit=closeit                      
entry=1, flags=flags                                                           
entry=0x7ffd6eef09fc) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:435
#21 0x00007f3f287dae43 in PyRun_AnyFileExFlags (fp=fp                          
entry=0x9bf6a0, filename=<optimized out>, closeit=closeit                      
entry=1, flags=flags                                                           
entry=0x7ffd6eef09fc) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:84
#22 0x00007f3f287f9c82 in pymain_run_file (p_cf=0x7ffd6eef09fc, filename=<optimized out>, fp=0x9bf6a0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:428
#23 pymain_run_filename (cf=0x7ffd6eef09fc, pymain=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:1607
#24 pymain_run_python (pymain=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:2868
#25 pymain_main (pymain=pymain
entry=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:3029
#26 0x00007f3f287f9ec9 in _Py_UnixMain (argc=<optimized out>, argv=<optimized out>) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:3064
#27 0x00007f3f27735555 in __libc_start_main () from /lib64/libc.so.6           
#28 0x00000000004006ce in _start ()                                            
===========================================================                    
                                                                               
                                                                               
The lines below might hint at the cause of the crash.                          
You may get help by asking at the ROOT forum http://root.cern.ch/forum         
Only if you are really convinced it is a bug in ROOT then please submit a      
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace          
from above as an attachment in addition to anything else                       
that might help us fixing this issue.                                          
===========================================================                    
#5  0x00007f3f18c2011d in TObjArray::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#6  0x00007f3eef6c0202 in TGeoVolume::~TGeoVolume() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#7  0x00007f3eef6c0429 in TGeoVolume::~TGeoVolume() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#8  0x00007f3f18c20128 in TObjArray::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#9  0x00007f3eef64cea2 in TGeoManager::~TGeoManager() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#10 0x00007f3eef64d229 in TGeoManager::~TGeoManager() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libGeom.so
#11 0x00007f3f18c1a2c8 in TList::Delete(char const*) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#12 0x00007f3f18b5ff4f in TROOT::~TROOT() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/lib/libCore.so
#13 0x00007f3f2774cce9 in __run_exit_handlers () from /lib64/libc.so.6         
#14 0x00007f3f2774cd37 in exit () from /lib64/libc.so.6                        
#15 0x00007f3f287d16e9 in Py_Exit (sts=sts                                     
entry=6) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pylifecycle.c:2292
#16 0x00007f3f287d94b1 in handle_system_exit () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:636
#17 0x00007f3f287d990f in handle_system_exit () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:683
#18 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars                         
entry=1) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:646
#19 0x00007f3f287d9a5a in PyErr_Print () at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:542
#20 0x00007f3f287dab98 in PyRun_SimpleFileExFlags (fp=fp                       
entry=0x9bf6a0, filename=<optimized out>, closeit=closeit                      
entry=1, flags=flags                                                           
entry=0x7ffd6eef09fc) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:435
#21 0x00007f3f287dae43 in PyRun_AnyFileExFlags (fp=fp                          
entry=0x9bf6a0, filename=<optimized out>, closeit=closeit                      
entry=1, flags=flags                                                           
entry=0x7ffd6eef09fc) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Python/pythonrun.c:84
#22 0x00007f3f287f9c82 in pymain_run_file (p_cf=0x7ffd6eef09fc, filename=<optimized out>, fp=0x9bf6a0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:428
#23 pymain_run_filename (cf=0x7ffd6eef09fc, pymain=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:1607
#24 pymain_run_python (pymain=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:2868
#25 pymain_main (pymain=pymain                                                 
entry=0x7ffd6eef0ad0) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:3029
#26 0x00007f3f287f9ec9 in _Py_UnixMain (argc=<optimized out>, argv=<optimized out>) at /workspace/build/externals/Python-3.7.6/src/Python/3.7.6/Modules/main.c:3064
#27 0x00007f3f27735555 in __libc_start_main () from /lib64/libc.so.6           
#28 0x00000000004006ce in _start ()                                            
===========================================================

The track level dE/dx or dN/dx according to truth can be implemented in Reconstruction/Tracking/src/TruthTracker/ according to truth and sample tools. @wenxingfang @mirguest

Merge the dE/dx simulation and analysis code into the master from @rkiuchi

Problem: there are several extra code are copied into CEPCSW, which breaks the previous convention on the directory hierarchy.

The proposal of the directory hierarchy

Top Level

• Top level (following the data processing flow)
  • Generator
  • Simulation (Detector Simulation)
  • Digitization
  • Calibration
  • Reconstruction
  • Analysis
  • Detector (Detector description)
  • Examples (all the job options here)

Generator (TBD)

Simulation (WIP)

Digitization (TBD)

Calibration (TBD)

Reconstruction (TBD)

Analysis (TBD)

Detector (TBD)

Examples (TBD)

I suggest to migrate and test all the tracking modules in the following order.

• Merge data-type modified SiliconTracking to master.

  • pull request
  • brief code review
  • Test the SiliconTracking standalone.(Whole chain, start from simulation, with the modified data-type)
  • merge to master

• Merge clupatra (May be together with TPCDigi)

  • ... similar with silicon

• Merge FullLDCTracking

  • ... similar with silicon

• Re-organize the folders

@mirguest @fucd

See https://gitlab.cern.ch/key4hep/k4-deploy/-/jobs/12306746

I just checked the spack build of cepcsw v0.2.0 and see the following warning in the build log (/cvmfs/sw.hsf.org/spackages/linux-centos7-broadwell/gcc-8.3.0/cepcsw-0.2.0-qnxsfg3cdx6riyzkgzjxrcrp7uggnl3q/.spack/spack-build-out.txt):

CMake Warning at cmake/CEPCSWDependencies.cmake:27 (find_package):
  By not providing "FindHepMC.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "HepMC", but
  CMake did not find one.

  Could not find a package configuration file provided by "HepMC" with any of
  the following names:

    HepMCConfig.cmake
    hepmc-config.cmake

  Add the installation prefix of "HepMC" to CMAKE_PREFIX_PATH or set
  "HepMC_DIR" to a directory containing one of the above files.  If "HepMC"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:31 (include)

Indeed CEPCSW does not provide a FindHepMC.cmake. This is necessary for HepMC2 (HepMC3 already provides its CMake configuration and targets). I'd recommend using https://github.com/HSF/cmaketools, which includes a FindHepMC.cmake. Alternatively, you could also copy it to the cmake folder. Maybe this is not an issue when using the lcg releases, as they already set up the cmaketools package.

In the process of drift chamber simulation, charge geantino needs to be used to obtain some theoretical results, which are compared with the current results.
So need particle gun to support charge geantino

When I run the example of CEPCSW/Examples/options/detsim_Pan_ana.root in CEPCSW, I set the gun. Particles as "pi0". I can't get the MC information of 2 gammas in final state. The N_mc , number of MC particals, is always 1. The only MC information I can get are pi0's . Can I get the information of MC gammas?

======> EVENT:4
 N_mc            = 1
 N_rec           = 2
 m_pReco_PID     = 22,
                  22
 m_pReco_mass    = 0,
                  0
 m_pReco_energy  = 7.50405,
                  2.05038
 m_pReco_px      = 7.39686,
                  2.01176
 m_pReco_py      = -0.044182,
                  0.0341337
 m_pReco_pz      = 1.26302,
                  0.394613
 m_pReco_charge  = 0,
                  0
 m_mc_p_size     = 0
 m_mc_pid        = 111
 m_mc_mass       = 0.134977
 m_mc_px         = 9.84808
 m_mc_py         = 0
 m_mc_pz         = 1.73648
 m_mc_charge     = 0
 m_hasConversion = 0
 m_marlinTrack   = 0

During the simulation and digitization process, I encountered the following problems, which seem to be related to memory. The output of the problem is as follows:
7f8f18c0f000-7f8f18c10000 rw-p 00045000 00:5a 2022538116 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4graphics_reps.so 7f8f18c10000-7f8f18c11000 rw-p 00000000 00:00 0 7f8f18c11000-7f8f18ce4000 r-xp 00000000 00:5a 2022538139 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4materials.so 7f8f18ce4000-7f8f18ee3000 ---p 000d3000 00:5a 2022538139 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4materials.so 7f8f18ee3000-7f8f18ee4000 r--p 000d2000 00:5a 2022538139 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4materials.so 7f8f18ee4000-7f8f18ee5000 rw-p 000d3000 00:5a 2022538139 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4materials.so 7f8f18ee5000-7f8f18ee7000 rw-p 00000000 00:00 0 7f8f18ee7000-7f8f193be000 r-xp 00000000 00:5a 2026487573 /cvmfs/sft.cern.ch/lcg/releases/VecGeom/v1.1.5-35ded/x86_64-centos7-gcc8-opt/lib/libvecgeom.so 7f8f193be000-7f8f195be000 ---p 004d7000 00:5a 2026487573 /cvmfs/sft.cern.ch/lcg/releases/VecGeom/v1.1.5-35ded/x86_64-centos7-gcc8-opt/lib/libvecgeom.so 7f8f195be000-7f8f195ca000 r--p 004d7000 00:5a 2026487573 /cvmfs/sft.cern.ch/lcg/releases/VecGeom/v1.1.5-35ded/x86_64-centos7-gcc8-opt/lib/libvecgeom.so 7f8f195ca000-7f8f195cc000 rw-p 004e3000 00:5a 2026487573 /cvmfs/sft.cern.ch/lcg/releases/VecGeom/v1.1.5-35ded/x86_64-centos7-gcc8-opt/lib/libvecgeom.so 7f8f195cc000-7f8f195ce000 rw-p 00000000 00:00 0 7f8f195ce000-7f8f19a44000 r-xp 00000000 00:5a 2022538210 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4geometry.so 7f8f19a44000-7f8f19c43000 ---p 00476000 00:5a 2022538210 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4geometry.so 7f8f19c43000-7f8f19c53000 r--p 00475000 00:5a 2022538210 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4geometry.so 7f8f19c53000-7f8f19c57000 rw-p 00485000 00:5a 2022538210 /cvmfs/sft.cern.ch/lcg/releases/Geant4/10.06.p02-4eb2a/x86_64-centos7-gcc8-opt/lib64/libG4geometry.so

Hi @fucd and @wenxingfang,

I found both of you have contributed the classes such as HelixClass and LineClass,

• https://github.com/cepc/CEPCSW/tree/master/Utilities/DataHelper
• https://github.com/cepc/CEPCSW/tree/master/Reconstruction/PFA/Pandora/MarlinUtil/01-08/source

To avoid duplication, please consider to put all the same classes together.

Tao

Some properties of McParticle are missing. The vertex and endpoint both are (0,0,0). Then momentumAtEndpoint is not set.

The digitizaion of CRD drift chamber waveform include 3 steps:

1. Primary ion simulation
   [ ] Prameterized sampling
   [ ] Geant4 PAI model
   [ ] Garfield++ Heed
2. Induction current simulation
   [ ] Prameterized sampling
   [ ] Garfield++
3. Waveform simulation

Hi Mingrui @mirguest @zoujh ,

It seems that using ConstTrackerHit is our consensus. But object or pointer, which is best for transmission? I tend to pointer. My consider is:

1. Almost all tracking algorithm add tracker hit object into a hit helper class (for example, TrackerHitExtended in SiliconTrackingAlg), and then use the pointer of object saved in helper class will workable.
2. If transmit object, although the size of object is small (~10 bytes?), for thousands hits, the cost is 10 thousands bytes level memory and CPU time in each copy. The copy times are different for different algorithm. If ~10 times, it will be 100kb level. Is it worth to save the cost through transmit pointer in event?

Of course, the requirement is that each whole event is deal in one memory manager. I am not so clear on how multithreading work. So if it cannot work for multithreading, please let me know.

Chengdong

To do: Get the DCH cell position using DD4HEP in DCHDigi

add a demo for multithreading drift chamber simulation

Now that CEPCSW is part of the of the key4hep-stack, I noticed that both FCCSW and CEPCSW have a component named "GeoSvc". This is a very good example of something that could be moved to common key4hep repository and maintained together. (Also, if setting up both FCCSW and CEPCSW, Gaudi can only load one of the components, and there will most likely be an error)
But I just checked, and the GeoSvc here does some additional (experiment-specific?) things, also using GEAR. I'd propose to rename the experiment specific services, and add a DD4hepGeoSvc to a common key4hep repository, and see if we can refactor some things from the GeoSvc here.

• compact files
• geometry construct
  • Beampipe
  • VXD
  • SIT
  • FTD
  • TPC
  • SET
  • Ecal
  • Hcal
  • Coil
  • Yoke
• Validation

Due to the new rules of Travis CI, the initial credit balance of the open source project is 10,000. It is charged for 10 credit balance per min. Now the balance for us is negative and the CI stops working.

So I start the investigation of new CI solutions. Now I setup a self-hosted GitHub runners for CEPCSW. The setup of runners is setup manually. The final solution will be setup the runners on kubernetes automatically.

There are numerous occasions in cepcsw where a double is implicitly converted to a float. Newer compilers treat this as an error (-W-c++11-narrowing)

I have added the -W-no-c++11-narrowing to the recipe, but it's probably good practice to explicitly add the casts at one point (I started, but there are quite a few instances and this is not very urgent), for example:

diff --git a/Digitisers/SimpleDigi/src/TPCDigiAlg.cpp b/Digitisers/SimpleDigi/src/TPCDigiAlg.cpp
index ebb1df4..6aaa5f1 100644
--- a/Digitisers/SimpleDigi/src/TPCDigiAlg.cpp
+++ b/Digitisers/SimpleDigi/src/TPCDigiAlg.cpp
@@ -1231,12 +1231,13 @@ void TPCDigiAlg::writeVoxelToHit( Voxel_tpc* aVoxel){
   }
   debug() << "==============" << endmsg;
   // For no error in R
-  std::array<float,TRKHITNCOVMATRIX> covMat={sin(unsmearedPhi)*sin(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes,
-    -cos(unsmearedPhi)*sin(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes,
-    cos(unsmearedPhi)*cos(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes,
-    0.,
-    0.,
-    float(tpcZRes*tpcZRes)};
+    std::array<float,TRKHITNCOVMATRIX> covMat=
+        {static_cast<float>(sin(unsmearedPhi)*sin(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes),
+         static_cast<float>(-cos(unsmearedPhi)*sin(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes),
+         static_cast<float>(cos(unsmearedPhi)*cos(unsmearedPhi)*tpcRPhiRes*tpcRPhiRes),
+         0.,
+         0.,
+         static_cast<float>(tpcZRes*tpcZRes)};
 
   trkHit.setCovMatrix(covMat);
 

The drift chamber material is hard coded in the Detector/DetDriftChamber/src/driftchamber/DriftChamber.cpp.

clupatra_new::operator()

sometime while applying ClupatraAlg on CEPCSW simulated and TPCDigiAlg digitized data, cannot get available TrackerHit object while mtrk->getTrackerHitAtPositiveNDF( last_constrained_hit );
add protection and TODO: check how this problem causes

To study the detector performance and debuging, the stage of track finding or pattern recogonition is skipped. Truth hits are used ont the track fitting. The knowlage of truth hits on primary track are essencial for the accuracy of track fitting. According to our discussion, the attribute of the hits belonging could be recorded in the SimTrackerHit for each detectors. Could you please implement this in the near future?

Could not submit job under CEPCSW enviroment. The error ImportError: No module named site raised.

Iit will be very efficient for debug if Gaudi could skip fisrt N events in the event loop or only execute the specified events in the run and event number list.