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

[Paul Mattione]

Here's an updated version of the CMU scheme.  I made some minor changes of my own, and then tried to either incorporate or address all of David's comments.  I left the tagger section alone though, since I think I'm too unfamiliar with it to propose a specific format.  

http://www.jlab.org/Hall-D/software/wiki/images/0/00/Mattione_Compact_MC_Output_V2.pdf

Another thing to think about including is information such as TOF scintillator paddle, in case you want to reject all tracks matched to a certain paddle in your analysis due to low statistics, mis-calibration, etc. 

 - Paul

On Aug 18, 2011, at 10:00 AM, David Lawrence wrote:

> 
> 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
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline