search

mirguest / MirguestIssueReport

5 stars 3 forks source link

Check issue 151 #152

Open chenqy opened 11 years ago

chenqy commented 11 years ago

dynamic_cast<HelloPMTManager*>(m_pmtmanager)

mirguest commented 11 years ago

邓老师已经找到问题了。因为我在初始化时，没有正确设置指针为NULL。

chenqy commented 11 years ago

@mirguest 哈哈，太好了，正想着要看这个文件呢~~

chenqy commented 11 years ago

“在交互模式，一句一句把run.mac里的输入那个命令行，为什么一个事例就可以显示” 稍微改变一点点，内存情况就不一样了的

chenqy commented 11 years ago

1

chenqy commented 11 years ago

Checking overlaps for volume PMTTube ... WARNING - G4PVPlacement::CheckOverlaps() Overlap is detected for volume PMTTube with its mother volume lTarget at mother local point (18446.5,60.9065,-3.55194), overlapping by at least: 2.37213 cm

* G4Exception : InvalidSetup issued by : G4PVPlacement::CheckOverlaps() Overlap with mother volume ! * This is just a warning message. Total: 1 为什么1个PMT还提示overlap呢？我几百个都不提示overlap。。。

chenqy commented 11 years ago

Checking overlaps for volume PMTTube ... WARNING - G4PVPlacement::CheckOverlaps() Overlap is detected for volume PMTTube with PMTTube volume's (PMT与PMToverlap。。。) local point (-143.662,257.738,283.532), overlapping by at least: 6.26242 mm

* G4Exception : InvalidSetup issued by : G4PVPlacement::CheckOverlaps() Overlap with volume already placed ! * This is just a warning message. Checking overlaps for volume PMTTube ... WARNING - G4PVPlacement::CheckOverlaps() Overlap is detected for volume PMTTube with PMTTube volume's local point (-227.158,132.568,213.62), overlapping by at least: 991.182 um

* G4Exception : InvalidSetup issued by : G4PVPlacement::CheckOverlaps() Overlap with volume already placed ! * This is just a warning message. Checking overlaps for volume PMTTube ... WARNING - G4PVPlacement::CheckOverlaps() Overlap is detected for volume PMTTube with PMTTube volume's local point (233.348,122.217,453.246), overlapping by at least: 753.902 um

* G4Exception : InvalidSetup issued by : G4PVPlacement::CheckOverlaps() Overlap with volume already placed ! * This is just a warning message. Checking overlaps for volume PMTTube ... OK! (这里有不overlap的。。。) Checking overlaps for volume PMTTube ... OK!

chenqy commented 11 years ago

任意找5个做测试，设置： m_radLS = 50.0 * m;

Checking overlaps for volume PMTTube ... OK! Checking overlaps for volume PMTTube ... OK! Checking overlaps for volume PMTTube ... OK! Checking overlaps for volume PMTTube ... OK! Checking overlaps for volume PMTTube ... OK! Total: 5

chenqy commented 11 years ago

pmt_top.csv中7124和7127有问题！

chenqy commented 11 years ago

674 //chenqy// m_radLS = sqrt( pow( (m_pmtPlaceRad + pmttubecover_h), 2) 675 //chenqy// +pow( pmttubecover_r, 2) ) + 2_gap; 676 //chenqy// m_radLS = 50.0 * m; 677 m_radLS = sqrt( pow( (m_pmtPlaceRad + (pmttubecover_h+pmttube_h)), 2) 678 +pow( pmttubecover_r, 2) ) + 2_gap;

@mirguest @dengzy 请@housj

液闪半径需要检查。 top的7124,7127需要检查。 其他部分一步一步来。

chenqy commented 11 years ago

pmt_47_49 本身ok，与其他的部分未检查。 pmt_44_46 本身ok，与其他的部分未检查。

mirguest commented 11 years ago

是不是PMT摆放的时候，尾部深入到钢罐里面了？

chenqy commented 11 years ago

overlap与下面设置的距离有关： /dyb2/det/filemode/distance 18 m

chenqy commented 11 years ago

Index : 6 used in the geometry : Yes recalculation needed : No Material : Vacuum Range cuts : gamma 1 mm e- 1 mm e+ 1 mm proton 1 mm Energy thresholds : gamma 990 eV e- 990 eV e+ 990 eV proton 100 keV Region(s) which use this couple : PMT_20inch_water_body_region

Start closing geometry. G4GeometryManager::ReportVoxelStats -- Voxel Statistics

Total memory consumed for geometry optimisation:   24073 kByte
Total CPU time elapsed for geometry optimisation: 30 seconds

Voxelisation: top CPU users:
Percent   Total CPU    System CPU       Memory  Volume
-------   ----------   ----------     --------  ----------
  99.90        29.95         0.04        24073k lTarget
   0.00         0.00         0.00            0k PMT_20inch_water_body_log
   0.00         0.00         0.00            0k PMT_20inch_waterCover_Whole

Voxelisation: top memory users:
Percent     Memory      Heads    Nodes   Pointers    Total CPU    Volume
-------   --------     ------   ------   --------   ----------    ----------
 100.00      24073k     38370   296855     954897        29.95    lTarget
   0.00          0k         2        4          8         0.00    PMT_20inch_waterCover_Whole
   0.00          0k         1        2          4         0.00    PMT_20inch_water_body_log

LSExpAnalysisManager: Histograms are booked and the run has been started

Run : 0

Start Run processing. Begin of Event --> 0 ========>chenqy: time diff of BeginOfEvent and EndOfEvent is 1 ========>chenqy: clock time diff of BeginOfEvent and EndOfEvent is1360000 Begin of Event --> 1 ========>chenqy: time diff of BeginOfEvent and EndOfEvent is 1 ========>chenqy: clock time diff of BeginOfEvent and EndOfEvent is1350000 Run terminated. Run Summary Number of events processed : 2 User=2.69s Real=2.73s Sys=0.02s UserDetectorConstruction deleted. UserPhysicsList deleted. UserRunAction deleted. UserPrimaryGenerator deleted. G4 kernel has come to Quit state. G4SDManager deleted. EventManager deleted. UImanager deleted. Units table cleared. StateManager deleted. RunManagerKernel is deleted. RunManager is deleting.

chenqy commented 11 years ago

旧

Index : 6 used in the geometry : Yes recalculation needed : No Material : Vacuum Range cuts : gamma 1 mm e- 1 mm e+ 1 mm proton 1 mm Energy thresholds : gamma 990 eV e- 990 eV e+ 990 eV proton 100 keV Region(s) which use this couple : PMT_20inch_water_body_region

Start closing geometry. G4GeometryManager::ReportVoxelStats -- Voxel Statistics

Total memory consumed for geometry optimisation:   29993 kByte
Total CPU time elapsed for geometry optimisation: 13 seconds

Voxelisation: top CPU users:
Percent   Total CPU    System CPU       Memory  Volume
-------   ----------   ----------     --------  ----------
  99.77        13.12         0.04        29994k lTarget
   0.00         0.00         0.00            0k PMT_20inch_water
   0.00         0.00         0.00            0k PMT_20inch_water_body_log

Voxelisation: top memory users:
Percent     Memory      Heads    Nodes   Pointers    Total CPU    Volume
-------   --------     ------   ------   --------   ----------    ----------
 100.00      29993k     49902   353427    1269499        13.12    lTarget
   0.00          0k         1        2          4         0.00    PMT_20inch_water
   0.00          0k         1        2          4         0.00    PMT_20inch_water_body_log

LSExpAnalysisManager: Histograms are booked and the run has been started

Run : 0

Start Run processing. Begin of Event --> 0 ========>chenqy: time diff of BeginOfEvent and EndOfEvent is 1 ========>chenqy: clock time diff of BeginOfEvent and EndOfEvent is1240000 Begin of Event --> 1 ========>chenqy: time diff of BeginOfEvent and EndOfEvent is 1 ========>chenqy: clock time diff of BeginOfEvent and EndOfEvent is1250000 Run terminated. Run Summary Number of events processed : 2 User=2.46s Real=2.5s Sys=0.03s UserDetectorConstruction deleted. UserPhysicsList deleted. UserRunAction deleted. UserPrimaryGenerator deleted. G4 kernel has come to Quit state. G4SDManager deleted. EventManager deleted. UImanager deleted. Units table cleared. StateManager deleted. RunManagerKernel is deleted. RunManager is deleting.

chenqy commented 11 years ago

event0 start: 151U: 151u0 mU: oldu0

151gamma: 151g0 mgamma: oldg0

chenqy commented 11 years ago

each event start:

151U: 151ueach mU: oldueach222

151gamma: 151gammaeach mgamma: oldgammaeach

chenqy commented 11 years ago

对于gamma，似乎两个event之间差别不大，但是每个event好像更耗时了。 对于本底事例，每个event耗时看起来差别不大，那么两个event之间程序究竟在做什么？

不对，见下。

chenqy commented 11 years ago

哦，差点忘记了，上面是已经把产生子手动改为从圆柱抽样的，看来的确不是产生子抽样位置导致程序变慢的。 那么接下来怎么做，尝试把不必要的操作都注释掉，找到Geant4在两个event之间都在做些什么？

不对，见下

chenqy commented 11 years ago

@mirguest 看到你qq了，不过我还不确定这样做对不对。

在LSExpAnalysisManager中声明了time_t startEvent; time_t endEvent; clock_t cstartEvent; clock_t cendEvent;和相应的几个函数

void Set_startEvent(time_t startevent) {startEvent = startevent;} void Set_endEvent(time_t endevent) {endEvent = endevent;} void Set_cstartEvent(clock_t cstartevent) {cstartEvent = cstartevent;} void Set_cendEvent(clock_t cendevent) {cendEvent = cendevent;} void Get_difftime(); 里面输出(cendEvent-cstartEvent);

在EventAction里： void LSExpEventAction::BeginOfEventAction(const G4Event* evt) 72 { 73 74 //chenqy 75 start = time(NULL); 76 cstart = clock(); 77 if( evt->GetEventID() == 0 ) 78 { 79 LSExpAnalysisManager::getInstance()->Set_startEvent(start); 80 LSExpAnalysisManager::getInstance()->Set_cstartEvent(cstart); 81 } …… 在EndOfEventAction里 214 ends = time(NULL); 215 cends = clock(); 216 LSExpAnalysisManager::getInstance()->Set_endEvent(ends); 217 LSExpAnalysisManager::getInstance()->Set_cendEvent(cends); 218 LSExpAnalysisManager::getInstance()->Get_difftime();

我还没仔细检查，下午出去帮另一个实验室的看空调去了。。。

mirguest commented 11 years ago

我不知道你怎么推出之前的结论：

对于gamma，似乎两个event之间差别不大，但是每个event好像更耗时了。 对于本底事例，每个event耗时看起来差别不大，那么两个event之间程序究竟在做什么？

chenqy commented 11 years ago

@mirguest 我不确定对不对，如果正确的话：

当从event0设置起始时间，每个event结束时设置结束时间，那每个event输出的时间是相对于event0那个开始的时间。这样的话，上面的四个图，横坐标就是每个事例结束时间与event0开始时间的差值的直方图，理想状态为平均的分布，新旧PMT的横坐标最大值差不多一样。

当注释掉if( evt->GetEventID() == 0 )这个条件，就是每个event开始时设置起始时间，结束时设置结束时间，输出的时间是每个event的耗时。下面的四个图，横坐标就是每个事例耗时的直方图，理想状态为一个高斯分布，平均值为处理一个事例耗时的平均值。 对每个事例的处理时间，直接影响事例结束时间与事件0起始时间差，所以应该像下面那样，按照事例顺序来画，我用excel画的。

得到上面的结论了，我也不知道该怎么找这个问题，就想这么试试。 (这个结论有误，见下)

chenqy commented 11 years ago

把GenSim和PrimaryGenerator替换为旧的版本，几乎没有变化： relace

把asc文件先给split，没用的文字都被删除： 151U_split: 151_u_split_evt0start old U_split: old_u_split_evt0start

chenqy commented 11 years ago

哦，不对，上面的做法有问题，应该看下面的图。

151ueach 151u0 151u0_oldgen

oldueach oldu0

chenqy commented 11 years ago

151U：检查evtID=7的事例。

chenqy commented 11 years ago

除了产生位置不一样，其他貌似都一样：

151U：

692 Begin of Event --> 7 693 /tracking/verbose 4 694 695 ***** 696 * G4Track Information: Particle = alpha, Track ID = 7, Parent ID = 0 697 ***** 698 699 Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 700 0 4.87e+03 -1.01e+04 -1.45e+04 7.84 0 0 0 PMT_20inch_water_body_phys initStep 701 702 >>AlongStepDoIt (process by process): Process Name = Transportation 703 704 ++G4Step Information 705 Address of G4Track : 0x27b4a458 706 Step Length (mm) : 0.0002146901906063213 707 Energy Deposit (MeV) : 0 708 ----------------------------------------------------------------------- 709 StepPoint Information PreStep PostStep 710 ----------------------------------------------------------------------- 711 Position - x (mm) : 4874.775664989639 4874.775674977165 712 Position - y (mm) : -10090.43467487786 -10090.43466985392 713 Position - z (mm) : -14535.93223491119 -14535.93244931009 714 Global Time (ns) : 4248410044989 4248410044989 715 Local Time (ns) : 0 0 716 Proper Time (ns) : 01.103830608385569e-05 717 Momentum Direct - x : 0.04652064562770131 0.04652064562770131 718 Momentum Direct - y : 0.02340091854285882 0.02340091854285882 719 Momentum Direct - z : -0.9986431928079881 -0.9986431928079881 720 Momentum - x (MeV/c): 11.2499999999999 11.2499999999999 721 Momentum - y (MeV/c): 5.658999999999952 5.658999999999952 722 Momentum - z (MeV/c): -241.499999999998 -241.499999999998 723 Total Energy (MeV) : 3735.21552877769 3735.21552877769 724 Kinetic Energy (MeV): 7.836528777690091 7.836528777690091 725 Velocity (mm/ns) : 19.40875404981058 19.40875404981058 726 Volume Name : PMT_20inch_water_body_physPMT_20inch_water_body_phys 727 Safety (mm) : 0 0 728 Polarization - x : 0 0 729 Polarization - y : 0 0 730 Polarization - Z : 0 0 731 Weight : 1 1 732 Step Status : Undefined AlongStep Proc. 733 Process defined Step: Undefined hLowEIoni 734 -----------------------------------------------------------------------

old U: 672 Begin of Event --> 7 673 /tracking/verbose 4 674 675 ***** 676 * G4Track Information: Particle = alpha, Track ID = 7, Parent ID = 0 677 ***** 678 679 Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 680 0 -8.92e+03 -9.38e+03 -1.23e+04 7.84 0 0 0 PMT_20inch_water_body_phys initStep 681 682 >>AlongStepDoIt (process by process): Process Name = Transportation 683 684 ++G4Step Information 685 Address of G4Track : 0x166c01f0 686 Step Length (mm) : 0.0002146901906063213 687 Energy Deposit (MeV) : 0 688 ----------------------------------------------------------------------- 689 StepPoint Information PreStep PostStep 690 ----------------------------------------------------------------------- 691 Position - x (mm) : -8919.726071291645 -8919.726061304118 692 Position - y (mm) : -9376.747222185935 -9376.747217161988 693 Position - z (mm) : -12253.52818396172 -12253.52839836062 694 Global Time (ns) : 4248410044989 4248410044989 695 Local Time (ns) : 0 0 696 Proper Time (ns) : 01.103830608385569e-05 697 Momentum Direct - x : 0.04652064562770131 0.04652064562770131 698 Momentum Direct - y : 0.02340091854285882 0.02340091854285882 699 Momentum Direct - z : -0.9986431928079881 -0.9986431928079881 700 Momentum - x (MeV/c): 11.2499999999999 11.2499999999999 701 Momentum - y (MeV/c): 5.658999999999952 5.658999999999952 702 Momentum - z (MeV/c): -241.499999999998 -241.499999999998 703 Total Energy (MeV) : 3735.21552877769 3735.21552877769 704 Kinetic Energy (MeV): 7.836528777690091 7.836528777690091 705 Velocity (mm/ns) : 19.40875404981058 19.40875404981058 706 Volume Name : PMT_20inch_water_body_physPMT_20inch_water_body_phys 707 Safety (mm) : 0 0 708 Polarization - x : 0 0 709 Polarization - y : 0 0 710 Polarization - Z : 0 0 711 Weight : 1 1 712 Step Status : Undefined AlongStep Proc. 713 Process defined Step: Undefined hLowEIoni 714 -----------------------------------------------------------------------

chenqy commented 11 years ago

track数相差好多。。。 somany_tracks

chenqy commented 11 years ago

dynode @mirguest 加上打拿级效果如何？

chenqy commented 11 years ago

没有打拿级，这个gamma产生的次级粒子出现了差别，右下角的那个e-，产生了很多的光子，直接导致结果差别很大。

下图为verbose设为1时找到的该初级粒子的信息： why2

下面为verbose设为4时找到的那个对应的e-信息 ++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 2314 [Note]Secondaries from AlongStepDoIt included.

@mirguest 所以必须加上打拿级。

mirguest commented 11 years ago

我们尝试加了一个dynode，但似乎本底运行的时间仍然很长。

mirguest commented 11 years ago

我们初步认定，可能还是产生位置代码的问题。确定一个点是否在一个volume中是比较费时的。

chenqy commented 11 years ago

@mirguest 去掉那段代码，有明显的改善么？

chenqy commented 11 years ago

@mirguest 下面是周末与邓老师发的几封邮件内容，我贴到这里，希望能帮你理解我的想法。（从下往上看哈~）

邓老师:

我觉得，新型的PMT肯定会和旧的PMT不一样，就拿赤道面以下的玻璃来说，本底及其次级粒子会有更多的机会往前方走，径迹数会变多，耗时。

我用手机登的邮箱，不方便查MCP-PMT的原理，如果和我之前听说过的微通道的那种原理类似的话，那没办法，是什么结构和材料就只能写什么。除非人为设置某条件下的径迹不被模拟，不然速度肯定和径迹的多少相关；再就是看看并行计算什么的能不能用上，一定程度上改善一下状况。

所以不能一味的追求旧PMT的速度，毕竟结构不一样。

从100个事例来看，很多事例的耗时也不是很长，也就十个左右的拖了后退，但是对于大样本的，也许就是几千个拖后腿，积少成多，只有从每个细节一点一点扣。

哦，差点忘了说:和旧的相比，我认为最最关键的因素还是PMT内外部结构的变化。其次若提前把asc文件拆分，去掉其中不用的信息，从100个事例看能快近1/5。

陈泉佑

---原始邮件--- 在 2013年05月19日 09:46:47 "dengzy"dengzy@ihep.ac.cn 写道：

关键问题是现在PMT上产生本底的模拟速度是原来的n多倍，你说的这些可能只是对模拟速度稍微有点影响的， 哪个才是影响速度的最关键因素呢？ 由于以后的MCP－PMT没有打拿极，玻璃里面的物质材料比传统打拿极PMT要少很多，因此不能象以前那样添加一个大的实心的打拿极。

2013-05-19 dengzy 发件人： 泉 发送时间： 2013-05-1900:01:31 收件人： dengzy 抄送： 主题： 回复： 可能是打拿级的问题

老师:

我觉得没有打拿级肯定会有影响，因为我随便取了几个参数添加了个圆柱的打拿级，发现100个事例的时间的确是变少了。

而且打拿级和光电倍增管玻璃的大小应该也会有影响。想象一下，同样多的本底，根据产生位置和初始动量，如果打拿级比较大，那么后部的本底穿过打拿级最终进入液闪产生的次级粒子可能会减少，模拟时间应该也会变化。

还有产生子提取asc文件的信息时，新的代码好像多了点操作，我换成原来的产生子，会稍微快一点。

另外如果提前把asc文件拆分好，把里面不用的信息都去掉，可以更快。

总之，我觉得光电倍增管的结构必须完善，内部的一些细节最好能和机械组商定。然后把光电倍增管之间的overlap搞定。最后适当精简一下产生子部分的代码，去掉不必要的操作。应该会有效果的。

陈泉佑

---原始邮件--- 在 2013年05月18日 19:12:47 "dengzy"dengzy@ihep.ac.cn 写道：

新PMT没有打拿极，后来林韬加打拿极试了好像也不行。

chenqy commented 11 years ago

@mirguest

上面五个点点图：

横坐标对应的是evtID，纵坐标是clock_t的计数，对应时间； evt0 start反应的是每个事件结束时间和第一个事件开始时间的时间差； each start是每个事件的耗时； 看evt0start的图，对于本底事例有很多台阶，这些台阶就是耗时长的event造成的。

还记得我发给你的excel么，那里面画了gamma的，你可以对比一下。所以这些台阶要尽量少。