Home » PANDA » PandaRoot » Bugs, Fixes, Releases » update stable branch...
|
Re: update stable branch... [message #10032 is a reply to message #10014] |
Sat, 23 January 2010 13:18 |
Johan Messchendorp
Messages: 693 Registered: April 2007 Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Dear all,
Below I summarise the remaining problems which I noticed by looking at the dashboard and talking to some people. For the next production release, we should try to fix these items and incorporate them in the stable branch. Some of the problems only show up on 32-bit machines or somewhat older compilers. Nevertheless, our ambition is to keep compatibility with as many platforms and compilers as much as possible as part of the quality assurance and service to the collaboration. So, please take a regular look at the dashboard. In this respect, it might be good to have various virtual machines available and accessible for all the developers. Something we could discuss on the next meeting.
- Tutorial macros: there seem to be crashes related to the PndEventReader and the Jul09 and Jan10 fairsoft ROOT releases. Klaus told me he will take a look at it.
- On 32-bit machines, the fast simulation QA macro crashes with a floating point exception, for example http://fairroot.gsi.de/CDash/testDetails.php?test=35414&build=15381 . I believe the problem is related to the track smearing function, which - sometimes - smears values to very large values causing a floating point error. Klaus, could you take a look at this as well?
- qa_dch_macro2: on 32-bit machines this macro crashes as well with a floating point exception: http://fairroot.gsi.de/CDash/testDetails.php?test=35403&build=15381 . There are also warnings of the type "caution: wrong drift time". Ola W., Arek or Garzia, would one of you still have some time to take a look at this? That would be really great! [UPDATE: noticed that the start momentum for the fitting is sometimes zero, which causes a floating point error in evaluating Q/P. Added a check whether the start momentum is zero, before proceeding with the fit (line 252 in PndDchPreFitterTR.cxx , rev7537). I am not sure whether these situation should occur at all?!?]
- qa_lhe_macro : on all machines it gives a segmentation fault and points to a problem in the PndMvdStripClusterTask. My guess is that this is related to the restructuring of the MVD code. Ralf, is there any hope on the short time for this, or shall we use for the stable release the "old" MVD structure?
- qa_mvd_macro2 and qa_mvd_macroana: similar to the previous crash (I guess?).
- qa_stt_macro3: on some machines it returns the statement "negative muon ptot resolution wrong" and "negative muon kalman ptot resolution wrong": http://fairroot.gsi.de/CDash/testSummary.php?project=2&name=qa_stt_m acro3&date=2010-01-23 . Lia/Susanna, do you have any idea what goes wrong here? Unfortunately, it doesn't happen on all machines. I attached as pdf the corresponding histograms which came out of the macro and which were used to perform the check.
- reco_complete_stt/tpc: also related to the MVD (see above)... sorry, Ralf
Best wishes,
Johan.
-
Attachment: his_stt.pdf
(Size: 20.17KB, Downloaded 241 times)
[Updated on: Sat, 23 January 2010 22:55] Report message to a moderator
|
|
|
|
|
Re: update stable branch... [message #10048 is a reply to message #10042] |
Tue, 26 January 2010 12:16 |
Lia Lavezzi
Messages: 291 Registered: May 2007 Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Johan,
thank you for giving me the print outs
Among the two limits in the resolution test, the upper limit is the really important one. The lower limit was just put there to check if too big statistical fluctuations were present (which might be related to some bugs), but it is also possible that while improving the code and fixing the bugs, the resolution gets better and so it turns out to be better than expected...
In this case I think it could be just a matter of statistics. The limits were tuned on 100 events, but I have seen that the number of events in macro 1 (which are then reconstructed in macro 2 and histogrammed in macro 3) has been turned from 100 to 50 some time ago by Mohammad.
Just to understand what to do, what was the reason for this? Are 100 events (with 6 track each, 3 mu+ and 3 mu-) too many for a qa macro? If so, no problem , I will change the limits for the tests to test only 50 events (I will enlarge them a little to account for bigger fluctuations from my values). If on the contrary it is possible to go back to 100 events, I would like to do it, just to lower the statistical fluctuations and see if everything runs fine. Mohammad, what do you think about this?
In any case, it seems to me that there is nothing we have to worry about for the code itself, it is just the macro that has to be fixed (in one of the two ways), since from the numbers: 0.0248863 is just like 0.025 and 0.0176549 is like 0.018
Please let me know about the number of events to use and I will fix the macro accordingly.
Cheers,
Lia.
|
|
|
|
|
|
Re: update stable branch... [message #10061 is a reply to message #10057] |
Fri, 29 January 2010 10:33 |
StefanoSpataro
Messages: 2736 Registered: June 2005 Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Yesterday I have checked the qa macros, just to understand what is going good and what is wrong.
Here the list of wrong things:
a) DCH and forward EMC are overlapping. I don't know who is in the correct place, for sure I know that both DCH anf FEMC geometries are obsolete. Maybe we could comment out the shashlick.
b) inside dipole geometry there are three overlaps
c) in my pc, sim_complete_tpc.C is stuck at event #6, and sometime it takes 300 seconds. Maybe the time there should be enlarged
d) Why in the reco_complete_tpc.C there are all the STT reconstruction tasks However they do not affect at all the reconstruction. I will correct it.
e) In several machines reco_complete_tpc.C fails, with the following error
Toggle Spoiler
### Empty Track. No hits/digis inside
-I- PndMvdPixelClusterTask: 25 Mvd Clusters and 25 Hits calculated.
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1208527168 (LWP 17466)]
0x03fb484c in PndGemTrackFinderOnHits::RemoveCloneTracks (this=0xa9a6b00, nofRecoTracks=1) at /home/spataro/dart/trunk/gem/PndGemTrackFinderOnHits.cxx:433
433 if ( meanPhi[itr]/nofTS[itr] < 5. && iterTS.trackPhi > 355. ) { iterTS.trackPhi -= 360.; }
Current language: auto; currently c++
(gdb) bt
#0 0x03fb484c in PndGemTrackFinderOnHits::RemoveCloneTracks (this=0xa9a6b00, nofRecoTracks=1)
at /home/spataro/dart/trunk/gem/PndGemTrackFinderOnHits.cxx:433
#1 0x03fb3a9c in PndGemTrackFinderOnHits::DoFind (this=0xa9a6b00, hitArray=0xb32a370, trackArray=0xb47bb18)
at /home/spataro/dart/trunk/gem/PndGemTrackFinderOnHits.cxx:288
#2 0x03fbc00f in PndGemFindTracks::Exec (this=0xa9a3bf0, opt=0x72558e8 "") at /home/spataro/dart/trunk/gem/PndGemFindTracks.cxx:145
I think this is due to a not protected division by zero. But why that number is zero...
f) fsim is crashing due to a "wrong" smearing of the vertex for neutral particles. I have sent a mail to Klaus.
Now words to the "experts"...
|
|
|
Goto Forum:
Current Time: Mon Dec 02 14:42:50 CET 2024
Total time taken to generate the page: 0.00666 seconds
|