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

[David Lawrence <davidl@jlab.org>]

Hi Matt,

    This all sounds reasonable and not at all orthogonal to the 
discussion at the software meeting earlier this week. A couple of 
technical details though:

- hdgeant does currently have access to our calibrations DB. (This was 
actually done back in July 2007 so we could access the magnetic field 
map and Lorentz deflections tables etc.)

- mcsmear is a pure HDDM program and does not currently include JANA and 
so doesn't have access to the calibrations DB. This functionality can be 
added fairly easily, but bringing in the MCResponse factory code will 
require either pulling the relevant parts out of the factory or 
reworking mcsmear.

I think we're all in agreement as to the basic principles. I would 
strongly recommend that we use the mcsmear mechanism though since the 
only persistency model we have right now is HDDM and it would take 
considerably more effort to implement this in some other format (e.g. 
ROOT or CODA).

    So now we just need to find a volunteer to put this bell on the cat. 
I can do it,  but I'll give other folks a chance to volunteer before I 
hog all of the fun jobs.

Regards,
-David

Matthew Shepherd wrote:
>
> 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

-- 

------------------------------------------------------------------------
 David Lawrence Ph.D.
 Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
 Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
 http://www.jlab.org/~davidl     davidl@jlab.org         [[[  [[ [[ [[[
------------------------------------------------------------------------