Discussions Around the RICH Event Model

Some first questions from Matt :-

  • MCHit. In the past there was a MCHitBase which is the same as your MCRichHit, MCHit then derived from this. Would it be better to go back to this ?

I don't know. Previously MCRichHit derived from MCHit, but this was dropped as MCHit has an exit point data member, which is of no use to the RICH and just wasted space. Is there really any use for all hits having a common base class ? If such a class was made available and adopting it did not increase the size of the MCRichHits, then I see no problem with adopting it, so the real question is whether it is useful or not. -- ChrisRJones - 22 Aug 2005

Looking at the comments to the silicon detector event model I was wondering if it is conceivable/usefull to move the history bits (6 bits if I understood correctly) in the key of the hit with the goal to save space Are the charged and background bits correlated/ I mean if charged is set to 1 then what is the background value? -- Alessia Sata 22 Aug 2005

Hmm yes. For the MCRichHit we could conceive of storing the bit packed word in the key, to try and save space. It would complicate the class as I would have to write the accessors/setters by hand instead of using divine inspiration (G.O.D.) but it could be done. I would like though to understand how much we actually save in practise. One thing I learnt from being on the rdst taskforce was that root persistency can be doing clever things for you, so it is not always obvious how much you save with such tricks. We should check with the experts. -- ChrisRJones - 22 Aug 2005

  • History code in MCRichDigit. Is this useful ? Would you recommend it to others ? In Boole I guess it is not actually needed. You can link the Digit to the MCRichHit and then use the back pointer to the container.

I think it depends how you MC navigation works. For the RICH we have simple single hop links. The reason we have this field is that in order to follow back from the MCRichDigit to the MCRichHit the sim file containing the MCRichHit must be available, and this could be any of the signal or spillover inputs. This requires the XML catalogue to be in place and this is not created for normal productions. By saving a single bit packed word in the MCRichDigit we can ask a few simple questions without having to navigate to the hits. -- ChrisRJones - 22 Aug 2005

Having this field in the MCRichDigit also solves an additional problem, which is if you attempt to follow a smart reference from an MCRichDigit which is not available (for example it is an MCRichHit that came from a spillover event and thus is not in the data file, and not available in another file via the pool XML catalogues), then Gaudi crashes when accessing this object (at least it used to - I need to double check this with the latest Gaudi version). Having this field allows me to limit when I need to do this. -- ChrisRJones - 25 Aug 2005

Yes, it describes how the track went through each RICH radiator in a form convenient for the RICH reconstruction applications. They describe a trajectory through a RICH volume and not just a simple state in space, and therefore a single State would not be enough. Note also, that these are created from either reconstructed data (online or offline tracks) or MC information, using the "track creators" in the RichRecTools and RichRecMCTools packages. It certainly could be considered, but my first reaction is that little would be gained, it would get complicated and would tie the RICH reconstruction objects too strongly to the track event for my liking. -- ChrisRJones - 22 Aug 2005

  • You have floats in your model : why not double ?

This was done ages ago, in an attempt to space space where precision is not needed. This should probably be reviewed with the new persistency, since with compression etc. it might not be gaining anything. -- ChrisRJones - 22 Aug 2005

  • Who provides the trigger decoding, you or the trigger ?

The RawBuffer decoding (we have no L1 buffers) is done by the RichDAQ package, the output of which is a vector of RichSmartIDs. This is the only decoding of the buffer.

Note also in the RICH reconstruction we have our out framework of tools / base classes which mean all the reconstruction algorithms work only on RichRec* objects - They are blind as to where the data (either the tracks or the RICH hits) came from. In the usual case when they are working from RECO data, the decoding is done for them behind the scenes so the algorithms do not ever directly interact with the decoding tools. See the software manual in RichSoftware for more details. -- ChrisRJones - 25 Aug 2005

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 2005-09-05 - ChristopherRJones
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback