(superseded by the Foundation page)


White Paper Analysis and Proposed Startup Plan

The startup team has produced a document analyzing the white papers and proposing a startup plan. A version 1.0 draft was released on Nov 11 2014. It is available here. Please send your comments on the document to the HSF open forum (see the Organization page of this website). It is a working draft and will evolve based on feedback, so please comment.

Startup team progress: Nov 5 2014

See the slides for the Nov 5 IFB meeting for a progress report on HSF startup from the startup team.

First steps for the startup team, from Torre/Pere's Oct 1 presentation to the IFB

  • Establish an inclusive, representative startup team
  • Make a plan for meetings, communication, engagement
  • Move quickly to an agreed initial work plan
  • Begin consultations, synthesizing inputs, community engagement
  • Define and initiate the first services and activities, including a system for facilitating information exchange
  • Work with early guinea pigs to get a functioning HSF V0 off the ground
  • Begin to build a HSF membership of active participants
  • Meet at a workshop in early 2015 to report, assess and plan, somewhere other than CERN, with support for remote participation

Priority contacts

The HEP communities we will focus on initially:

  • LHC
  • High intensity, neutrino
  • Belle II, b physics
  • Linear Collider
  • Theory
  • Astrophysics and Astroparticle
  • ...

The software domains we will focus on initially:

Make ‘scientific software’ an early focus

  • Software to process the data coming from the detectors up to the publication of physics results
  • Simulation; MC generators; reconstruction, calibration, alignment algorithms; analysis tools; statistical tools; etc.
  • Many/most new architecture/concurrency challenges are in this domain

Include software addressing data-intensive challenges early as well? It’s a challenge up there with new architectures/concurrency.

For other areas, rely on community engagement & initiatives, or leave for later

  • Distributed software, middleware
  • DAQ/online

Identify key people and organize meetings with them to address

  • Their level and areas of interest, what they can bring, their priorities
  • What could HSF provide that they don’t already have and that could bring a real benefit to them

Important inputs to this process are the already written White Papers. We are producing a synthesis document that will be provided as background to the discussions.

Software packages

It is important to establish initial ‘guinea pig’ packages to include in the foundation. The meaning of 'include' can be different depending on the package, their needs and interest, as determined from the consultations and input provided by developers, integrators and final users.

Packages to be addressed early will include those we target as initial priorities, and packages whose developers are actively interested in being early adopters and active contributors

We must handle packages at different stages

  • Existing, well established packages not requiring significant change, e.g. Pythia6
  • Packages in active development as common software, e.g. by developers strongly interested in being early adopters and active contributors
  • Established packages in need of re-engineering, adaptation to the new computing landscape such as vectorization, parallelization, e.g. ROOT, Geant4, ...
  • New packages and R&D initiatives that are good candidates to make use of the foundation from the beginning, e.g. USolids/VecGeom​