[Halld-offline] Minutes, Offline Software Meeting, February 22, 2012

[Mark M. Ito]

Find the minutes at 
https://halldweb1.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_February_22,_2012#Minutes 
and as text below.
_____

GlueX Offline Meeting, February 22, 2012
Minutes

Present:
* CMU: Will Levine, Curtis Meyer
* FSU: Nathan Sparks
* IU: Ryan Mitchell, Kei Moriya, Matt Shepherd
* JLab: Mark Ito (chair), Simon Taylor, Beni Zihlmann

Announcements

Simon and Mark reported that single-charged-track diagnostic jobs are
now running nightly on an ifarm machine at JLab. The success
probability is still a bit low (due to Computer Center controls of
multiple jobs) and adjustments will have to be made, but some results
can be seen at the [27]top-level web page.

Review of minutes from the last meeting

We reviewed the [28]minutes from the previous meeting, from before the
collaboration meeting, without significant comment.

Reconstruction sub-group reports

Calorimeters

Will gave a summary of his work thus far characterizing photon
reconstruction in b[1]π events. See [29]his wiki page for details and
plots. He studied the BCAL and FCAL separately. In the BCAL he sees
about a factor of three more photons reconstructed than thrown but a
simple timing cut eliminates most of the spurious reconstructed
photons, leaving the right number and a reasonable energy spectrum. In
the FCAL there is a similar multiplication in photons from generated to
reconstructed, but timing only removes half of the total (a larger
factor is desired). Will is investigating these issues further.

Tracking

Simon told us about [30]his recent change to the tracking code. Simple
version [oversimple?]: FDC hits are no longer used by the CDC track
factory.

Reconstruction Output Format

We talked about the UConn DST format. Mark (echoing Matt's comment at
the last meeting) proposed that we support it as a collaboration and
use it as a starting point for a reconstruction output format. It
exists, it has been reviewed at some level by the collaboration, and
had been designed with compactness in mind.

Matt reiterated his concept that analysis should take place with
high-level objects in JANA. As such the DST should contain the minimum
amount of information needed to recreate all the necessary objects.
Some computation may be required to do this. It is therefore not
necessary for there to be a one-to-one correspondence between elements
in the DST event structure and the structure of the high-level analysis
objects, although that is not excluded where appropriate.

Mark wondered whether the current DST could support this vision as it
was not designed with this role in mind. Matt did not see any evidence
that it could not. He thought we should focus our design effort on the
structure of the analysis objects. If necessary, the DST and the
lower-level objects could be reworked to support them; some tweaking
and iteration will be necessary.

We agreed to proceed this way along these lines and adopt the UConn DST
as an initial serialization format.

We talked briefly about making utilities to make say ROOT trees from
DST's. Matt thought rather that it would be better to create the root
trees from analysis objects, using the DST's to provide data to create
said objects.

EventStore

We talked about the [31]EventStore system and its possible use by
GlueX.

Matt declined to describe the EventStore system, stating that
everything that needed to be said was in the [32]email he sent out to
the offline group. As such we dove directly into discussion.

The EventStore has some features that were remarked upon:
* Creating skims without duplication of events themselves by storing
only "pointers" to events
* Hooks for specifying the version of the code used to reconstruct
events
* Hooks for skimming events based on various database-resident
criteria
* Possibility for using alternate reconstruction code to over-ride
that used on previously reconstructed data

Matt knows the developers well. It has been tested used heavily by
CLEO-c for many years, with success.

The overarching question is whether this is something we want to pursue
and if so, at what priority. Other more detailed questions include:
* How portable is the code base?
* How easy is it to add new (our) event formats to the system?
* How do we implement the random access scheme for our data?
* How much disk space is required to for GlueX to use it effectively?
(CLEO-c required ten's of terabytes.)
* When do we need this functionality?

The functionality provided by such a system is closely related to the
issues raised in our previous discussion of DST's and analysis objects.

Matt thought that an effort could start as a low-level activity since
there is no immediate need for it.

We agreed that further exploration was needed and should be pursued.

Retrieved from
"https://halldweb1.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_February_22,_2012"

References

27. https://halldweb1.jlab.org/single_track/
28. 
https://halldweb1.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_February_8,_2012#Minutes
29. 
https://halldweb1.jlab.org/wiki/index.php/Photon_Reconstruction_in_b1pi_events_02/10/2012
30. 
https://mailman.jlab.org/pipermail/halld-offline/2012-February/000871.html
31. 
https://mailman.jlab.org/pipermail/halld-offline/2012-February/000859.html
32. 
https://mailman.jlab.org/pipermail/halld-offline/2012-February/000859.html

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