Experts asked for information / comments

1. Experts asked for information / comments • Following Tim’s request at the Collaboration meeting, SH contacted experts from both the • US and Europe to find out about current capabilities of frameworks and envisaged development • from the US asked John Jaros, Norman Graf, Tim Barklow and Aurelio Juste • from Europe contacted Ties Behnke, Frank Gaede and on one specific issue Alexei Raspereza • Questions asked to gather information on: • Interoperability, in particular if SiD tracking is / will be available in European framework • Current level of usage of LCFI code in the community and projection of future usage • Best approach to make high-profile contributions to LoIs in the WP1 area • The European experts replied within 2 hours of receiving the questions. • From the US, there has not been any response yet.

2. Interoperability of software frameworks Q: What is the timescale for a working geometry interface LCGO common to both frameworks? Ties Behnke: This depends very much on the available manpower. Progress has been slow on both sides. Frank Gaede: The timescale for a working geometry interface LCGO is rather unclear. Currently I am investigating technical issues that might turn out to be possible show stoppers for our original plans. These have to do with performance in the gcj compiled java code called from C++. There are possible alternatives based on existing tools in the C++ world, however none of these options have yet been discussed with our US colleagues. (And some of them would require a rather large change in their software strategy.).

3. Interoperability of software frameworks Q: What is your best realistic estimate of the timescale on which the software frameworks will be fully interoperable? Ties Behnke: This depends on your definition of fully interoperable. It already is at the level of LCIO - that is, we can already for LCIO compliant software run different pieces of software together. If you are looking for a seamless integration, this will be more difficult. There is no time estimate for this. Frank Gaede: Giving a realistic estimate of the timescale on which the software frameworks will be fully interoperable is even harder if not impossible. As this not only depends on the technical problems that need to be solved but also on the commitment of all involved groups in terms of manpower and willingness to cooperate (supported by higher management!).

4. Interoperability of software frameworks Q: Is interoperability of software frameworks planned to be ensured in both directions? Do plans exist to make ALCPG/SiD tracking available / usable from within the European software framework, and if so, on what timescale? (mentioned that this Q was motivated by idea of using European software framework in conjunction with SiD detector and tracking code) Ties Behnke: At some level this can be done already, if LCIO is used as the interface. Whether SiD tracking e.g. will become a module in MARLIN depends on whether anyone does the implementation. Frank Gaede: If we eventually have an LCGO system that is fully incorporated in both frameworks then in principle one can mix and match modules from both worlds, provided that the interfaces are pure LCIO, i.e. no additional 'proprietary' information is used in any of the modules. This will at least be possible on the level of splitting the software chain into more standalone applications, eg. Mokka simulation, Marlin Digitization, SID-Tracking and Marlin-PFA. A full integration into one application is currently not planed (however possible in principle).

5. Interoperability of software frameworks Frank Gaede made the following general comment: So at this point in time I would not suggest to base any strategic decisions on the expected full interoperablity of the two frameworks. It might very well turn out that we will not achieve this in the near future given the small manpower that is available for the development together with the somewhat unclear political situation. However pressure from the user community such as a strong request from groups like LCFI and possibly others might change the situation. Frank Gaede added the following suggestion: But even right now without full interoperability one can do a lot of what you are proposing on the LCIO level. I.e. you could take a file simulated with SLIC for the SiD detector and reconstruct this with Marlin tools (Alexei has written tracking code that also works for the SiD tracker) and then run your LCFIVertex code on that... All you need is a Gear file that describes the Sid detector and that should be rather easy to create from their simple geometry xml file.

6. Interoperability of software frameworks Q to Alexei: Is this separate / partly separate code (e.g. one new module for the SiD main tracker) or the package that we have already been using? Have you or has anyone else studied performance of this code with the SiD detector and do there exist performance comparisons of your code run with the SiD detector and ALCPG tracking code run with the SiD detector? If so, how do they compare? Alexei Raspereza: … Unfortunately, that version was based on a simple helix fit. No sophisticated Kalman filter was implemented. Although this simple fitting was sufficient for the PFA-related applications of the SiD-Tracking code, such an approach, which doesn't provide reliable estimate for the cov matrix, can not be extended to heavy-flavour tagging. I haven't touched this code since two years and I guess it would take me quite a while to refresh in my memory all its features. At the moment I don't regard further development of the SiD tracking software as a task of high priority in my ILC-related activities. But I don't exclude the possibility that one day I'll come back to this business. Honestly speaking, I'm not aware of any study comparing my code with official ALCPG software. As two years ago I was PFA guy, my primary interest focused on the combined performance of PFA and the tracking code rather than on tracking-specific performance in terms of impact parameter and momentum resolutions, track finding efficiency and fake track rate.

7. Level of usage of LCFI code • Q: What is your estimate for the number of analyses performed using the European software • that will be using the LCFI Vertex Package? If different, what´s this number for the LDC concept? • Ties Behnke: Hard to say - I would guess that at the moment at least 10 analyese are being • done. But this number is really a guess. It is also increasing, as more groups start to look at • real analyses. • Q: What approach would be more likely to result in an increase in this number: • Further work by LCFI on extending the scope of our code to make it more realistic & flexible? • Ties Behnke: This clearly would help, and be a strong help for people who worry about analyses • which have vertexing as part of their physics requirements. • LCFI performing benchmark studies within the European software framework? • Ties Behnke: Of course the more groups are using the MARLIN framework, the more tools • will be available for work within this framework, and the easier it will be for new groups to join • and make a contribution.

8. Contributions to LoIs • Q: What is likely to have a higher profile within the LoIs? • Results from benchmark physics processes performed by our group? • Contributions to code development (extension of Vertex Package)? • Ties Behnke: The current thinking is that the LoI's will have a strong part on realistic physics • analyses. Exactly what this means is still under discussion. • Visibility will come from both aspects: analyses and code development. • It is hard to say whether one will be stronger than the other - probably not.

9. Recent developments in Edinburgh / Glasgow • Meeting of the Edinburgh / Glasgow group (“SUPA-ILC”) Mon 25th June: • No decision, which LoI to sign yet; decision will likely be based on detector concept • (e.g. preference for all silicon vs TPC) or on design of the vertex detector • Victoria: as for the software, in the short term I think I'd be happy to work in either framework, • especially if we could contribute to making the two frameworks interoperable: so we could • study both detector concepts. • A half-day meeting to take a decision which LoI Edinburgh/Glasgow are going to sign is • planned later in the summer

10. Joint CALICE / LCFI physics effort • following consultation with Tim G, SH contacted Mark Thomson, to explore possibilities for • joint work of CALICE and LCFI on benchmark studies • suggestion welcomed by Mark Thomson: CALICE is looking for a strong connection with • LCFI in the physics area • this would be mutually beneficial, given that the two groups have expertise in different areas, • and that when performing physics studies detailed knowledge of both these areas is required • could share the load of learning to use parts of the software frameworks developed outside • the UK in sufficient detail to perform physics studies • in the short term agreed to startjoint CALICE-LCFI physics meetings, in a few weeks’ time • in the longer term (probably ~ a year from now), Mark thinks CALICE would be interested to • preparejoint bid for funding for EDR-work • Mark also mentioned concerns in the GLDC concept of loosing expertise, if LCFI were to spend • a large fraction of its physics effort on SiD studies and emphasised the need for a balanced plan