Gaudi Developers Meeting

Wednesday 14 Oct 2015, 17:00 → 18:05 Europe/Zurich

32/1-A24 (CERN)

Benedikt Hegner (CERN), Charles Leggett (Lawrence Berkeley National Lab. (US)), Marco Clemencic (CERN)

News

• Gaudi v26r4 released (mainly for LHCb)
  • changed the way release notes are prepared
    • general notes from JIRA
    • package notes git messages (usually from merge requests)

Benedikt reported a problem with the access rights to JIRA tickets.

Discussion on Gaudi Design (part 2)

No comments on the minutes of previous meeting.

Point 3: Lazy creation of objects

Marco expressed agreement with the proposal in the slides

Charles pointed out that there are different use cases, for example

• reading from disc
• conversion from old types

We agreed that using optional “sub-graphs” (groups of algorithms) can address all use cases.

Point 4: the role and use case for tools

Gerhard pointed out that AlgTools are often used because there are no alternative to implement components more apt for a given task. If the framework can be extended with new component managers, some of the AlgTools can be re-implemented in different ways.

Marco summarizes what the framework should provide:

• custom components
• private tools
• services

Public tools should be replaced by services, mainly to make it clear that they can be accessed by different algorithms at the same time, so they must be implemented accordingly.

For private tools we need to consider only the possibility that the tools are accessed only by one algorithm.

Paolo remind that we need that tools can access the Transient Store. We should ensure that read and write handles/tokens are propagated to the parent algorithm explicitly (via the framework), instead of being based on spying on what the tool initialization is doing (as currently implemented in the hive branch of Gaudi).

Gerhard reminded that we should not forget the special case of tools updating containers (pattern currently used in LHCb).

Charles proposes a migration path based on public tools read only so that developers are forced to migrate their code to services if they want to be able to change internal states. Marco fears that they will just use mutables, so he proposes to provide a base class to fill the gap between current public tools and services (in this way the switch could be done changing the base class of the component).

17:00 → 18:00 Continuation of Design Discussion

Speaker: Benedikt Hegner (CERN)