[Halld-offline] Data Challenge Meeting Minutes, July 16, 2012

[Mark M. Ito]

Richard,

As you point out there are a lot of degrees of freedom in the 
reconstruction, even more when you think about tracking. I think that 
David has a mechanism for reporting nearly everything; he should 
comment. That information should go into a database _and_ into the file, 
on a file-by-file basis, and not event-by-event. Event-by-event is ugly, 
as you said.

   -- Mark

On 07/18/2012 08:59 AM, Richard Jones wrote:
>
>  1. when reading back DBCALShower objects, I will unpack them
>     (agnostic as to how they were made) either as KLOE or default bcal
>     clusters, depending on what the user asks for. This has the
>     "feature" that the person who wrote the REST file might write KLOE
>     clusters and the person who reads it might fetch them as default
>     clusters.  This might be the correct behavior.  If not, there is
>     another way to go: create separate lists in the REST format for
>     each type of each object that one foresees, and have the writer
>     only populate one of them.  The overhead for doing this is
>     negligible, but I think it is ugly.  IMO, there is just one
>     conceptual object known as a DBCALShower, but many ways to make
>     it.  Within the KLOE or default factories there are many internal
>     settings that one might switch around.  Are we going to try to
>     save all of that information in the output file on an
>     event-by-event basis?  Why not put it in the database Mark was
>     talking about, where a single entry can cover many events, event
>     multiple files within a production run.
>
>

-- 
Mark M. Ito
Jefferson Lab (www.jlab.org)
(757)269-5295



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20120718/79fc8c01/attachment-0002.html>