The CHEP 2015 organizers have kindly agreed to include in the Conference planning a HEP Software Foundation meeting early Friday afternoon Apr 17, just after the conclusion of the Conference. Time and details are to be determined, but with very many flights to Tokyo available in the late Friday afternoon and evening we hope that many will be able to include the HSF meeting in their CHEP plans without significant disruption to their travel plans.

The meeting will provide a good opportunity to

• Expose a wider community to the HSF
• Have a further face to face meeting a few months after the SLAC workshop
• Nucleate common projects drawing on the substance of the CHEP Conference – CHEP 2015 will no doubt highlight and expose new and emerging opportunities for common software collaboration.

Further details will be announced later, via the HEP S&C community mailing list. If you have not yet signed up to this list, please do so at

Agenda

Minutes

Introduction and Status

Discussion

• OpenStack Foundation: was seen as not giving enough visibility to the projects hosted by the foundation. Evolving along ideas very close to HSF ones!
• R. Mount: WLCG should become a part of HSF or partner with it…
  • Not a complete agreement, WLCG more than SW development. May encourage SW projects in WLCG to participate to HSF.

Algorithm Forum - M. Elsing

eed to address algorithmic problem in addition to fostering collaboration and common solutions between SW projects

• Requirement for meeting the physics performance needed by HL-LHC
• Tracking is the CPU driver for reconstruction
  • Even worst for triggerless readout adopted by LHCb and ALICE
• Hard to exploit new proc technologies, despite parallelized framework like Gaudi-Hive and CMSSW
  • Tracking intrisincly a sequential problem as it is focusing today on early rejection

Must take into account that there is no possibility to restart from scratch

• Existing frameworks are a huge investments: 100+ M$ per framework
• There was discussion of effort needed to move to a new framework: In the CMS experience CMSSW was started in 2005. By the summer of 2006 CMS was taking cosmic data with it, and the simulation was fully ported. The point is that moving existing algorithmic code to a different “framework module” interface doesn’t require a lot of work. The expensive part is restructuring algorithmic code to adhere to the rules of a new framework, and are what take time. For example moving from a policy of “use global state at will” to “no modification of global state during the event loop” would be hard. However this change would be necessary to support multi-threaded applications no matter what framework was used.

To gain from algorithms in tracking, need to reduce the sequential part to a very small part: Ahmdal law

• Impact a lower early rejection needs to be understood

Towards a common tracking implementation?

• AIDA is aiming at that…
• Must maintain best physics performance: not really a lot of enthusiasm about this idea in large experiments
  • Concentrate on sharing expertise, techniques, best practices
  • Small experiments may benefit from a common framework
• Atlas discussing to make public is tracking/vertexing SW
  • To allow reuse by FCC

Several workshops on tracking and pattern recognition: ACAT…

• WS on pattern recognition last Feb. in Berkeley:: Connecting the Dots
• Need to hear from new approaches/algorithms like deep learning, neuronal networks…
• Mailing list created by the reconstruction/tracking communities
  • In fact work started after the success of the HiggsML challenge
• Another list created under HSF umbrella: is it really useful to have both?
• Also the BOOST workshops
  • Should reconstruction algorithm forum should join them rather than organizing its own workshops

Discussion

• M. Cataneo: should work on designing an Event Data Model adapted to parallelisation and vectorization: no reason to have 1 different for each experiment

Working Groups

TechLab - R. Wartel

An environment to gain experience with different HW to make better use of new platforms/processors

• Also wants to be a useful meeting place: HW/SW, share of expertise
  • Community driven

Some characteristics of TechLab

• Only off-the-shelf HW
• Multiple vendors: no lock-in
• No NDA: everything can be published
• Not a production service: no SLA or guaranteed availability
• Platform run in close collaboration with OpenLab
• SW as close as possible as the one used in production
  • with some variations: Fedora Core, modern kernels

TechLab supports HSF!

• Offer access to its systems
• Would like to collaborate with other HSF partners with similar infrastructures
• Would like to understand how to accommodate HSF needs: agree on a first simple project or use case, set up access to it
  • Access to non CERN users: various possible solutions to be discussed according to the number of people involved: would like to explore alternative to creating a CERN account if possible.

TechLab has 2 egroups, open to subscription to anybody interested

Training - D. Menasce

Broad consensus that there is a broad gap between what is taught at university and the skills required by our community.

• Several good, well established schools but there format (~2 weeks) doesn’t allow a wide participation
  • Need to complement this with web-based tutorials

Open question: join existing platforms (SW Carpentry, WikiFM…) or start our own platform

• Not necessarily the right question for the short term
• Focus on a unified knowledge base referencing “peer reviewed” material
  • Documentation is an essential ingredient
  • Specialized towards scientific computing
  • Online exercices

Discussion

• Why not look at MOOCS platforms?
• Importance of human interactions
• First concentrate on a catalog of existing valuable materials: the Yelp! approach!

SW Packaging - E. Sexton - Kennedy

Build tools are fundational: packaging is an opportunity for improvements.

• Not HEP specific at all

Many skeptics: failed many times in promoting common approaches

• Have a phased approach with clear milestones: decide if and how to proceed after each phase

Phase 1: requirements and specification, define the problem space well

• Collect technical input
• See if defining a common build protocol is doable

Discussion started on GitHub HSF/packaging as issues

• Can be subscribed/unsubscribed on an issue basis: if subscribed, an email sent for every contribution to the issue
• Need broader participation!

Discussion

• Should not put too much effort in choosing a tool: no consensus in the C++ community as in Java, Python… the one chosen will be the wrong one anyway…
• Tools are not specific to HEP, the way to use them may be specific
  • Concentrate on making easy to manage/use dependencies, if possible without rebuilding them

SW Projects - P. Elmer

Several projects across the community looking for funding: none really certain yet

• Not many opportunities for funding new people: process often long

Antoher support that HSF could pursue is funding visits/mobility for collaboration between existing staff

• e.g. DOE/INFN exchange program
• Focus youg people
• HSF could help to make the existing programs know to the SW community
  • Often not SW specific
• Peter volunteers to bootstrap this by collecting the information

Technical Notes - A. McNb

TN: short document aimed at capturing important technical details about an interface or implementation that may be of use to others.

• Not intended to be “HSF Standards”
• Not intended to be research papers or SW documentation
• Modelled after experiment or lab technical reports
  • Or IETF RFC

Potential benefits of a cross-project repository of technical notes: foster cooperation between projects

• Description of an API may trig virtual/real meetings between projects

• Something visible/concrete that HSF can do to foster project collaboration

Avoid complex procedure : only provide a template, spell checks, typos fixing

• Prior approval of scope by submitting a title abstract
• Format : PDF
  • Source LaTeX template will be provided but any tool can be used to produce the PDF
• Andrew identified one potential candidate: to be confirmed soon
• Andrew also has one but would not like to see it the first one
• Also started to check emails and see if some of them can be turned into zeroth draft of a TN

TN immutable, except for the first line that could be changed to reflect the document has been obsoleted

• CERN would be happy to provide support for this with its infrastructure to manage document lifecycle.

Licensing

Broad agreement that HSF should not try to promote its own license: will imply a lot of lawyer work to agree that it is ok to use it.

HSF may recommend a license but must remain flexible about project choices.

• Sometimes choices imposed by a funded project

Big issue is how we can build a product with a permissive license if we need to use viral licenses like GPL.

• Could dual licensing be the solution in these cases?

Discussion

• CERN: impossible to recommend one license, must be a decision workflow with different recommendations for different situations