Re: Minutes of the June 17, 2009 GlueX Offline Meeting

[Matthew Shepherd <mashephe@indiana.edu>]

Hi Mark,

Sorry to miss the mtg. -- we were getting our radiation safety  
training so we can nuke lead glass blocks at IUCF.

On Jun 19, 2009, at 9:41 AM, Mark M. Ito wrote:

>   We  spent  some  time  discussing Matt's suggestion (from two  
> meetings
>   ago,  actually) of having all random-number related processes,  
> such as
>   smearing,  occur  in  a  stage  before  reconstruction  and having  
> the
>   results of that stage written to disk. David pointed out that  
> there is
>   already  a program, mcsmear that takes the hdgeant output and  
> produces
>   smeared  hits in HDDM format, suitable for the reconstruction  
> program.
>   Right  now only tracking is smeared but it would be  
> straightforward to
>   do smearing of the calorimeters as well.

My suggestion pertains specifically to how we choose to model detector  
response in the MC.  To try to give a concrete example:  suppose that  
using data we measure the efficiency for every straw in the CDC (e.g.,  
by finding tracks that go through the straw and then asking whether or  
not the straw saw a hit).  We can load this info into the database for  
various run number regions and then for any given run we can get the  
actual straw tube efficiency.  We then want to be sure that our Monte  
Carlo models this efficiency properly so at generation time we pull  
the info from the database for the run we are measuring and throw  
random numbers to determine which straw hits get suppressed.  In order  
to do this, we need to be able to use the database API.  As far as I  
know, it is not foreseen to have this available in HDGeant.  The  
natural place to put it (in my opinion) is in some factory that sits  
between HDGeant and the tracking code since there is a database API  
there.  The goal should be to make the output of this factory  
identical to what comes in from the raw detector data stream.  Right  
now, I don't know how to do this and save the intermediate output.   
What this means is that every time I run my code, hits in the CDC  
could appear and disappear which could potentially change which tracks  
are found in an event, their momenta, etc.

There are going to be aspects of the simulation like this that we want  
to tune in a run dependent way.  In E852 we saw clear evidence for  
time dependent deadening of the chambers around the forward beam  
hole.  Environmental conditions in the hall (beam related backgrounds,  
RF noise, etc.) can often be time dependent.  Think of not only having  
a "calibration database" but also a "MC tuning constants" database.   
The problem is that unlike calibration, sometimes MC tuning is not a  
deterministic process.

I haven't looked at David's mcsmear -- it may fit the bill exactly,  
and we just need to have it read from the existing response factories  
that have been developed for the calorimeter.  I'm also happy to help  
with development, but having some consensus as to whether this is a  
significant issue and how we want to handle it would be good.

-Matt