[Clas12_software] software group membership and minutes

[Mac Mestayer]

Hello direct addressees;

Please join the clas12_software email list serve if
you are not already a member.

---------------------------------------------------------
Minutes of Thurs, Feb.6, 2014 meeting:

1- NEAR PLANS:	Veronique led a discussion of our near-term
software plans:
 	- official release of TRAC; set up a panel to review
the object model and methods; Vardan, Dave Heddle, me, Ken Hicks
 	- easy release of code: decide on Virtual Machine method
 	- interfaces for histogramming, etc.: not decided yet
 	- Event Builder: team to define banks: Veronique, Johann
 	- identify team to work with VZ, JG on algorithms: Stepan
 	- set up a team to define track linking to outer detectors: not 
done yet
 	- geometry service: status review to be done soon; meanwhile
sub-detector groups must write geometry document
 	- improvements to Kalman Filter, e.g. broken-line algorithm;
Dave Heddle will look into this
 	- place-holder for time-based DC tracking: not done yet

ISSUES REGARDING CLARA FRAMEWORK
 	- we had a long discussion of how best to implement ClaRA
 	- from a small, informal poll there was concern that users
perceived ClaRA to be unnecessarily complicated; to set up, to run
 	- there was a long discussion about which parts of the software
would benefit most from ClaRA and which didn't need it; the consensus
seems to be that event reconstruction, geometry, calibration data base
and histogramming services should all be under ClaRA, but not so clear
for simulation and calibration determination services
 	- there was a long discussion about the main customer for
our software: the various "chefs" who must submit many jobs to the
batch farm and must handle complicated book-keeping; it is a
MUST that this be well-defined and straightforward

LANGUAGE CHOICE
 	- The proposal is to write the event reconstruction code in
one language, Java.  This code is tightly-coupled and will be written
by a relatively small group of people.  Also, for performance reasons,
it may be better to have a single language for this part of the code,
because of multi-threading constraints.
The down side is that it restricts the number of people who can write
and/or maintain the code.

EVIO to ROOT
 	- a 'must' for the near-term

-----------------------------------------------------------------------

Note, all or most of these issues can be discussed again.
See you next Thursday.

 				your secretary, Mac

"mestayer at jlab.org", (757)-269-7252