Home » PANDA » PandaRoot » Meetings » PandaRoot meeting, Tuesday 7th of October, 10:00, EVO
| PandaRoot meeting, Tuesday 7th of October, 10:00, EVO [message #7379] |
Sun, 05 October 2008 10:56  |
Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Dear all,
On Tuesday we will have our regular PandaRoot meeting: useall place and time (see subject line).
Tentative agenda points:
1) General announcements:
-> new subgroup coordinators
-> upcoming workshops
-> new group members
-> ....
2) Updating "Pandaroot contacts"
-> http://panda-wiki.gsi.de/cgi-bin/viewauth/Computing/PandaRootContact
3) Towards PandaRoot V3
-> status&planning
4) Tracking discussions:
-> urgent questions related to detector design (see "reply" message)
-> how to "join tracks from all detectors" : action plan!
5) AOB:
-> bugs, problems, etc.
If you have any point yourself which we need to discuss, please contact me asap.
Hear you on Tuesday!!!!
j.
[Updated on: Mon, 06 October 2008 16:25] Report message to a moderator |
|
|
|
| Re: PandaRoot meeting, Tuesday 7th of October, 10:00, EVO [message #7382 is a reply to message #7379] |
Mon, 06 October 2008 16:23  |
Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen
|
first-grade participant |
From: *KVI.nl
|
|
Dear all,
Another point for the agenda: an "urgent" request for simulations related to the tracking detectors (see message from Lars below). I would like to ask those involved in the tracking part of PandaRoot to participate on the 7th of October, so that we can settle on a date and timeline for a further discussion.
Kind wishes,
Johan
---------------------------------------------------------
Dear colleagues,
I would like to call for an EVO meeting on the simulation of tracking
in the target spectrometer.
The most urgent topics to discuss are:
- Length of Central Tracker
- Rates at Forward GEM positions
- Rough layout of forward GEMs
These topics are so urgent that we should not wait until December to
decide how to attack them but maybe rather have first results by then.
Further simulation topics not only concerning tracking detectors will be
discussed during the next collaboration meeting.
As latest date I propose the week of Nov 3rd. Earlier dates are Oct 20
(afternoon) or 21 (any time), Oct 27 (10-12) or 28 (10-12). This will be
discussed also during the PANDAroot EVO meeting tomorrow. Others
not present there should Email me and Johan their availability.
Yours,
Lars
|
|
|
|
 Re: PandaRoot meeting, Tuesday 7th of October, 10:00, EVO [message #7394 is a reply to message #7379] |
Thu, 09 October 2008 15:16 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi all,
I have a doubt concerning the discussion during the last EVO meeting about not copying informations from one root file to another: I understand this is a problem, but I would ask for some clarification on one point.
Let me explain shortly the situation. In the STT we have three kinds of points:
1) PndSttPoint, which contains the MC info and is filled during Geant simulation
2) PndSttHit, which contains the single straw tube response and is filled during the digitization
3) PndSttHelixHit (not definitive, might change), which contains additional information to the PndSttHit ones and is filled after the reconstruction.
Let' s forget about PndSttHelixHit for a while: this needs to be changed and I will do it as soon as possible.
I see a problem, however, when talking of the transfer from PndSttPoint to PndSttHit (let' s call them for simplicity point and hit).
As I told during the meeting, the reason why we copy the info from the point to the hit is to keep a separation between the simulation and the digitization output, in the sense that the PndSttHit must be self sufficient and contain the whole information needed in the reconstruction, without the need to refer to PndSttPoint (exept for the cases when a comparison with the MC is needed). Our main concern is to keep the format of the data input to the reconstruction macro identical between real (future) data and (present) MC data.
This is done to be able to reconstruct also real data with the same code, when only hits will be available, and nomore points. I mean, suppose we have to reconstruct real data. Then we need the wiredirection of the firing wire (for example): if we don' t have all the needed information within the hit, but we should refer to the point to get it, how could we retrieve that info?
Note that in the hit we copy only the information which will come from the tube response (i.e. no MC position is copied, only the center of the tube for example, which can be accessed in real data).
But maybe I' m missing something, this is why I' m writing this in more detail, to better understand: is it correct that we want the code to be able to reconstruct both MC and real data, with the same kind of reconstruction? How do other detectors handle this?
On the other hand it is necessary to keep the root files as small as possible. We are thinking about finding a way to reduce the geometry related info written on file: for example saving only one number, which identifies the tube, and writing a lookup table with the correspondences between tube identfying number and geometrical information of the tube itself. We are still discussing. This would prevent the root file from increasing too much in size: the price to pay in this scheme is the duplication of the identifying number in the simulation and digitization output files. What do you think about this solution?
Sorry, maybe I should have asked during the meeting  but I needed some little time to re-think about this and to discuss this also with Gianluigi and Susanna.
Thank you very much,
Lia
|
|
|
|
| Re: PandaRoot meeting, Tuesday 7th of October, 10:00, EVO [message #7399 is a reply to message #7394] |
Thu, 09 October 2008 17:56 |
Tobias Stockmanns
Messages: 489
Registered: May 2007
|
first-grade participant |
From: *ikp.kfa-juelich.de
|
|
Dear Lia,
thank you for your response to the discussion I brought up during the EVO meeting. I am sorry that this caused some confusion and I am glad that you wrote the explanation of the situation for the STT.
Please let me clarify my point a bit.
When I look at the STTPoint I see the following information stored in it:
- fx, fy, fz coordinates at wire center
- fx_in_local, ... local coordinates at entrance of act. volume
- fx_out_local, ... see above
- fx_wire_dir probably direction of wire (not explained in .h file)
- fxtot, fytot, fztot absolute coordinate of hit (to be deleted if I understand da cancellare correctly
 )
What I think you need in this file are the entrance and exit point in the global coordinate system of your detector and a unique identifier for your fired wire which allows you to extract the position of the wire out of the geoManager.
With these informations you can calculate all the rest.
So for me the most important information is fxtot, fytot, fztot which allows you to directly compare the result of your reconstruction with the MC information.
STTHit contains:
- fx, fy, fz coordinates at wire center
- fIsochrone radial distance from wire
- fRadial position along the circle in xy-plane (I assume that this is the position on the isochrone)
- fWireDirection (no explanation but it looks like fx_wire_dir from STTPoint)
- fRsim ???
- fRtrue ???
- fXint, fYint, fZint position of interaction
The information of fx, fy, fz and fWireDirection is available in both files, so this data can be reduced.
What I am missing is a STTDigi class. A digi file should contain all the information which you would get from your detector like the fired wire, the time, information of the pulse shape and the deposited charge and so on. All what your real detector would give you. On this data you would base your reconstruction on without accessing the MC data. This simulated data can later on be easily replaced by your real detector data and you can use the same reconstruction code on simulation and real experiment. In your code digi data (like the isochrone) and reconstructed data (like fRadial and fXint,...) is mixed up which means that you always have to do the digitization and reconstruction in one task or your STTHit is partially empty.
In the MVD code we tried to avoid this to be able to test different reconstruction methods on the same digi data without doing the digitization again.
I hope this answer makes my point a bit more clear.
Ciao,
Tobias
|
|
|
|
| Re: PandaRoot meeting, Tuesday 7th of October, 10:00, EVO [message #7400 is a reply to message #7399] |
Fri, 10 October 2008 12:13 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Tobias,
thank you for your reply!
I write here some more explanations on the different STT classes, just to clarify some points.
Concerning the STTPoint all you say is correct (including the translation of "da cancellare", very good!  ). Since the geometrical information can be accessed via the geoManager, this part can be changed (we will do it as soon as possible).
Concerning the STTHit, just a question about nomenclature: is it correct that for you Digi comes from the digitization and Hit comes from the reconstruction? I ask this because for me Hit comes from the digitization and HelixHit from the reconstruction. In fact, as far as I understand from your description of the "STTDigi", the STTHit is our STTDigi, I mean it contains the info coming from the single straw tube simulation, i.e. the tube response: all the info are filled during digitization.
There is just a point to think about, but I will talk about it later.
First, about the list of variables, here are some remarks:
3. fRadial: this is only the radial position of the tube center (this is a heritage of the old stt2 code... now we don' t use this info, maybe this could be deleted)
5. fRsim: simulated drift radius
6. fRtrue: true drift radius, the geometrical distance of closest approach of the particle to the firing wire (this must be removed because the real data won' t have it, but up to now it was present in order to easily compare the simulated drift radius to the real one)
7. fXint, fYint, fZint: actually this is a variable which is filled with the center of the tube position (at the digitization stage) and is updated during the reconstruction procedure, with the intersection (that' s what the "int" stands for) point found in the Intersection Finder... let' s say that it is the point on the drift circle where the particle most likely really passed, i.e. the one later written in the HelixHit. Ok, this might be a point to think about...
So, the main "problem" could be that actually here there is a mixing between the digitization and thevery first part of reconstruction: i.e. we get the drift time from the detector and the transformation to the drift radius can be considered part of the reconstruction instead of the digitization... I agree that this could be handled in a different way, but I should think about it before changing it, just not to mess up the whole code 
So, if I understand correctly, a part from what concerns the difference between the Hit and the Digi, I think we agree on three main points:
1) to get rid of the geometrical info both in the PndSttPoint and PndSttHit;
2) to substitute it with the identifiyng number of the tube;
3) to delete all other unused info.
Please feel free to correct me if I' m saying something wrong.
Ciao,
Lia.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Mon Apr 29 06:27:19 CEST 2024
Total time taken to generate the page: 0.00909 seconds
|
GSI Forum
Search
Help
Members
Login
Home
