[Halld-offline] [GlueX] proposed contents of reconstructed MC dst

[David Lawrence]

Hi All,

     This is a great start and an important discussion. One that I'm 
sure will continue at the Offline meeting next week, but that will also, 
no doubt, benefit GREATLY from this initial e-mail discussion. I would 
really encourage everyone to seriously look at and consider the 
proposals that have been presented so far PRIOR to the meeting next week 
so we can maintain a focused discussion.

     I have a few comments/questions so far. Some are directed towards 
the UConn proposal, and some towards the CMU one. I've tried to prefix 
these where appropriate.

Generated Particle Info
--------------------
- (UConn) In HDDM we keep a "type" and "pdgtype" allowing the 
information about which particles hdgeant does NOT track to be 
identified by type==0. This information appears to not explicitly be 
kept in the DST, but perhaps is implied by something like "no other 
particle identifies me as a parent". This is important information if 
one is trying to match reconstructed particles to generated ones since 
they would want to avoid accidentally matching to an intermediate 
particle that hdgeant didn't even track.

- (CMU) Vertex information is kept independently for each generated 
particle. This, according to the notes, is to allow for detached 
vertexes. However, most of these events will be multi-particle so 
keeping a list of vertexes and then an id for each particle indicating 
the vertex to which it is associated will save space. (Unless every 
particle has a different vertex).

- (CMU) The particle type was reduced to a short which is OK for GEANT 
particle id's. If, however we want to record the intermediate states 
pythia produces we'll need a 4 byte id. These can have very large id 
values since they follow the PDG numbering scheme which can have up to 7 
digits.

-(UConn) There is no id value for the vertex. Does this mean that 
"decayVertex" indicates the vertex location within the array of 
generated vertexes? This would work, but would seem inconsistent with 
other places where we explicitly assign id values to objects and 
reference the id in other objects.


Tagger
----------
- Tagger hits have a multiplicity of 1 in both proposals. We would 
expect this (on average) for a 100ns window and 10^7 running. This would 
be 10 times as much if simulating 10^8 running.

- There is no time associated with the tagger hit. Even for 10^7 
running, there will often be more than 1 tagger hit in the event. The 
timing of these may be important for data analysis an so should be added.

- There is no error for the reconstructed tagger energy. Is this 
expected to be a well-known constant or just so small that it never 
contributes? I can imagine hits in adjacent counters which may get 
reconstructed as a single hit rather than multiple ones, but with a 
larger uncertainty.


Neutrals
---------------
- (UConn) How do we get 7 floats error matrix? For a symmetric matrix I 
can get 6, 10, or 15, depending on the number of correlated values (3,4, 
or 5).

- (CMU) The correlations are kept only for the x/y/z coordinates, but 
the energy may well be correlated with the position as well

- The coordinate system for the error matrix would seem to be different 
for the cylindrical geometry  of the BCAL vs. the Cartesian geometry of 
the FCAL and CompCAL. Should we have some type of flag indicating this, 
or should we try and force everything into a Cartesian coordinate 
system? (I could be convinced of either way.)

- One distinct difference between the CMU and UConn proposals is that 
the CMU proposal keeps track of matches between charged tracks and 
neutral showers. It's not clear if the UConn proposal expects this to be 
repeated whenever the DST is read in, or if the showers that were 
matched to charged tracks are dropped before writing to the DST. The 
latter is complicated by the fact that one mass hypothesis could match 
while another does not for the same track.

-(CMU) Same comment regarding vertex as in Generated Particle Info section


Charged Tracks
----------------
- (UConn) Charge and energy are kept as a short and float respectively. 
By storing only a particle id (as is done in the CMU proposal), one 
saves a float.

- Both proposals keep position info ("Position" in CMU and "orgin" in 
UConn). I believe this is corresponding to the vertex and a similar 
vertex id scheme as is suggested for the generated particles should be 
used. We may want a number to indicate the quality of matching to the 
vertex, but that can be discussed.

- It is not clear to me that the tof(UConn) and Flight Time(CMU) and 
Path Length(CMU) are needed. The CMU proposal has a "Projected Time" 
which could mean projected to the vertex, or projected to the 
time-of-flight detector (whatever that may be). I think the time at the 
vertex is the most important quantity here. This would also need 
uncertainty in the vertex time due to the time-of-flight and the 
tracking. It would be a quantity that could then be directly compared to 
other particles.


That is probably enough for now. I haven't thought much about other 
things missing altogether (pair spectrometer, start counter, ...?)

Regards,
-David

On 8/17/11 4:34 PM, Paul Mattione wrote:
> I like it for the most part, but I'd like to propose some minor modifications to it.  Here's a link to my proposal, which is slightly larger (by about 150 bytes):
>
> http://www.jlab.org/Hall-D/software/wiki/images/0/05/Mattione_Compact_MC_Output.pdf
>
>   - Paul
>
> On Aug 17, 2011, at 1:29 PM, Richard Jones wrote:
>
>> Dear colleagues,
>>
>> As promised at the last Physics Working Group meeting, we have come up with a minimal list of information that must be saved in a DST from the full set of reconstructed objects for an event.  Please see the abstract attached to document 1799 on docdb, and download the Excel spreadsheet to play with the sizes of the different components.
>>
>> -Richard J.
>>
>> _______________________________________________
>> GlueX mailing list
>> GlueX at dustbunny.physics.indiana.edu
>> http://dustbunny.physics.indiana.edu/mailman/listinfo/gluex
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline