Project

General

Profile

Feature #598

Define tracker data structure

Added by Rogers, Chris over 12 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Dobbs, Adam
Category:
Tracker
Target version:
Future MAUS release
Start date:
22 July 2011
Due date:
% Done:

100%

Estimated time:
Workflow:

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

viewer.png (6.8 KB) viewer.png Santos, Edward, 05 August 2011 15:10
alltracker.png (17.5 KB) alltracker.png Santos, Edward, 05 August 2011 15:10
tracker_schema.pdf (58.5 KB) tracker_schema.pdf Santos, Edward, 06 August 2011 11:10
simulation.out (118 KB) simulation.out Santos, Edward, 06 August 2011 11:13
11-DATA-structure-r1.pdf (297 KB) 11-DATA-structure-r1.pdf Rogers, Chris, 27 September 2011 10:45
#1

Updated by Santos, Edward over 12 years ago

  • Assignee set to Santos, Edward
#2

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).

#4

Updated by Santos, Edward over 12 years ago

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

#5

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.

#6

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.

#7

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.

#8

Updated by Rogers, Chris over 12 years ago

Santos, Edward:

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.

#9

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.)

#10

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.

#11

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.

#12

Updated by Santos, Edward over 12 years ago

  • File deleted (tracker_schema.pdf)
#13

Updated by Santos, Edward over 12 years ago

Updated: included channel and plane numbers for each space-point (useful for visualisation).

#14

Updated by Santos, Edward over 12 years ago

Matt, I attached 3 spills with "mc", "digits" and tracker "spacepoints".

#15

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...

#16

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.

#17

Updated by Tunnell, Christopher over 12 years ago

Edward drafted it. I'll draft a version (essentially the same). We'll then converge.

#18

Updated by Rogers, Chris over 12 years ago

How's this going? Can I merge with trunk?

#19

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.

#20

Updated by Rogers, Chris over 12 years ago

Agreed...

#21

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?

#22

Updated by Rogers, Chris over 12 years ago

Right - I meant "is it in python, clear and correct so I can merge with trunk"

#23

Updated by Rogers, Chris about 12 years ago

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?

#24

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.
#25

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.

#26

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.

#27

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.

Also available in: Atom PDF