Feature #598
Define tracker data structure
100%
Description
We define the data structure for the spill in
${MAUS_ROOT_DIR}/src/common_py/SpillSchema.py
Could you please add the tracker data structure here (presumably) up to reconstructed tracks. Will probably need some discussion with Tunnell as it surely effects detector integration.
Requested by Matt Robinson for visualisation code, but also will be used for generating documentation and some testing.
Files
Updated by Santos, Edward over 12 years ago
- File tracker_schema.pdf added
Have a look at the pdf attached. Followed the scheme of the pdf included in today's new release (doc/run_control/spill.pdf).
Updated by Rogers, Chris over 12 years ago
Did you use the automated tool?
http://micewww.pp.rl.ac.uk/projects/maus/repository/changes/doc/doc_tools/parse_json_schema.py
Updated by Santos, Edward over 12 years ago
- File viewer.png viewer.png added
- File alltracker.png alltracker.png added
BUT... I'm not sure if this will help Matt. I'm not sure how the visualization for the tracker is going to be done. The fundamental parameters when visualizing a tracker event are the channel numbers of the fibres excited. See the figure attached, it's from a crude visualization tool I made for the current tracker cosmic run. Channel numbers are not included in the current tracker spill schema. I can add them to the space-point branch, if you like. Each space-point could carry the channel numbers of the fibres it corresponds to.
ES
Updated by Santos, Edward over 12 years ago
Rogers, Chris wrote:
Did you use the automated tool?
http://micewww.pp.rl.ac.uk/projects/maus/repository/changes/doc/doc_tools/parse_json_schema.py
No... I wrote it myself.
Updated by Robinson, Matthew over 12 years ago
Will/does this put us in a position to generate a fuller sample data file? The one I have just has a muon track in it and a few secondaries.
What I really need to complete the event viewer is a sample data file containing 2 or more spills which includes the various pieces of information the event viewer should display.
Updated by Rogers, Chris over 12 years ago
It tells you what the data structure should look like (like an xml schema). So either you or I can use it to make a sample data file.
Updated by Rogers, Chris over 12 years ago
The idea is to make the schema and then use that to generate documentation. So if we change the data structure, the documentation follows. Reduces maintenance overhead, which is important.
Updated by Santos, Edward over 12 years ago
Rogers, Chris wrote:
It tells you what the data structure should look like (like an xml schema). So either you or I can use it to make a sample data file.
I can also run a couple of spills and send you the output. Matt, do you want to see channel numbers associated to each space point? (so that you can highlight them... if that's the plan.)
Updated by Robinson, Matthew over 12 years ago
That would be most helpful.
I planned to consult on what information should be displayed and what should be highlighted etc. I shall start by reading in the data and then think about how to display it. If the "real" data will have channel numbers etc than it makes sense that the event viewer should display them in one way or another.
Updated by Rogers, Chris over 12 years ago
- Assignee changed from Santos, Edward to Tunnell, Christopher
Chris Tunnell, can you look through the pdf doc and just say if it's okay? Want to know if you have any "global" view on the track, space point interface for the various detectors.
Updated by Santos, Edward over 12 years ago
- File tracker_schema.pdf tracker_schema.pdf added
Updated: included channel and plane numbers for each space-point (useful for visualisation).
Updated by Santos, Edward over 12 years ago
- File simulation.out simulation.out added
Matt, I attached 3 spills with "mc", "digits" and tracker "spacepoints".
Updated by Tunnell, Christopher over 12 years ago
It looks fine. All the comments are minor: just things like number of pe should be linearly related to the ADC counts (ie. ADC counts is 'fit' pulseheight in ADC counts. And we may want to store pedestals etc.).
I had a request from Jean Sebastien to rename 'channel ID' and 'HW ID' to 'sensor ID' and 'active volume ID'? Not sure if it's worth it.
This seems to be about adding to SpillSchema.py at the moment...
Updated by Rogers, Chris over 12 years ago
Yes. I would also like someone to define what the tracks look like. As far as I am aware, Morteza is no longer taking an active role in software project, so I think it is up to you Edward.
Updated by Tunnell, Christopher over 12 years ago
Edward drafted it. I'll draft a version (essentially the same). We'll then converge.
Updated by Tunnell, Christopher over 12 years ago
- Assignee changed from Tunnell, Christopher to Santos, Edward
This shouldn't be assigned to me anymore, right? I commented and it looks fine.
If Edward puts it all into SpillSchema then this is essentially done.
Updated by Tunnell, Christopher over 12 years ago
Also Chris: what do you mean merge with trunk? It's just a PDF at the moment?
Updated by Rogers, Chris over 12 years ago
Right - I meant "is it in python, clear and correct so I can merge with trunk"
Updated by Rogers, Chris about 12 years ago
- File 11-DATA-structure-r1.pdf 11-DATA-structure-r1.pdf added
Email from Ken Long
OK, the _DATA_ data structure for the tracker we propose is in the attached. Not yet posted on the WWW owing to Edward's overload. _MC_ data structure will be next, then calibration and geometry. My question is that Edward proposes adding the event number to the tracker hit table. I would imagine there is a set of event tables with all sorts of information (times, triggers perhaps ...). The tracker hit should "point into" that rather than duplicate it.
Reply by Chris Rogers:
Event table stuff is a question for Tunnell - detector integration is his responsibility... What's the difference between a SciFiTrk and a SciFiPRTrk? Presumably t is time; npe is number of photoelectrons and you store sum of npe for all hits in the cluster and all clusters in the space point; what's v and c in the track? v is (x,y,t,px,py,pz) and C is covariance error matrix?
Updated by Rogers, Chris about 12 years ago
So I understand by pattern recognition you mean some helix fit; by SciFiTrk you mean some Kalman/whatever fancy thing fit
- Why do the PR tracks know about the hits that generated them but the fitted tracks don't?
- What happens to the PR tracks that don't make it downstream? We want to know about these to do transmission studies.
Updated by Rogers, Chris about 12 years ago
- Assignee changed from Santos, Edward to Dobbs, Adam
Changed assignee to Dobbs, which I think is correct.
Can you add to the data structure in src/common_py/SpillSchema.py so I can close this issue? Note I use this to auto-generate documentation also.
Updated by Dobbs, Adam almost 10 years ago
Is this still relevant, or can I close it? I notice the tracker data structure has not yet been added to main MAUS data structure diagram.
Updated by Hunt, Christopher almost 9 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Seems this is an old one. On the grounds that src/common_py/SpillSchema.py doesn't seem to exist anymore, and for the sake of cleaning up the issue tracker, I thought I would close this one. Any objections let me know and I'll try to get it sorted.