Exchanging Best Practices in Supporting Computational and Data-Intensive Research

Posted on by Aaron Turner

Who are the people that do this?

  • Research software engineers,
  • Research facilitators
  • Experts
  • (compute platform providers?)

Panel: USA centric, so it will be interesting to see how this is different to the position in the UK in terms of the panel’s views.

Panel Presentations

Bob Sinkovits, XSEDE

Mission statement includes: Optimisation. Visualisation. Workflows. Using accelerators. Training.

Scope is broad which can be problematic.

Best practices:

  • Workplans
    • [This is being done, for example, with Lougbhborough’s RSE.]
  • True collaborations
  • Reporting
  • Exit interviews at the end of projects
    • [That is interesting and I am not sure is being done.]
  • Build critical mass of consultants in XSEDE.
    • [This can be tricky due to funding models.]

Synergy

  • Best practices into a central repository
    • [This is one of thing things vexing HPC-SIG – it requires effort to collect, check. collate, and ensure continued relevance of this].

Ian Cosden, Princeton

RSE group, three years old, moving from 1 to 8 people in that time.

Embedded with researchers, not just consultants. 

Months to years for projects.

US-RSE is the equivalent of the UK body.

Proximity to peers is best to support RSEs. Frequent communication with researchers is critical. The multi-step approach to project intake is much as it is at Loughborough, for example: discussion, review, plan.

Share success stories, foster role change and career growth.

OSC

Small team with 4 members total.

Deploy ‘the science stack’

Face-to-face meetings important. Establish a baseline for codes. Good testing procedures. Automation (ReFrame – need to look at this), wide test systems. Use available tools.

Issues: in-depth sharing of expertise is difficult.

Notre Dame University

Incubators mentioned, as well as workforce development (e.g. internships).

Working towards creating an institute.

urssi.us

Gateways catalog – would be interesting to look at this and see what the useful ones are and how sustainable they are and what might help our researchers.

Rutgers

RADICAL-Cybertools experience. Middleware for workflow. This is really important and useful but insufficiently supported and used.

Tools required for developers of workflows.

About 250 workflow tools at present!!!

(Such tools include, from the UK, Taverna, which is now an Apache incubator project, so perhaps worth another look, but lacks the workbench which is 2.5 or earlier only so might limit the usefulness).

Need to be able to allow delivery of science quickly and then improve. Agile development? But need a governance structure for the software (not so Agile, perhaps).

Pic of Matteo Turilli who was at OeRC, not sporting an impressive beard.

Discussion from the floor

  • Distributed support models? It’s hard to make this cohesive.  How can it be done?
    • Work with faculty?
    • Start slowly, show successes.
    • Universities vary.
  • Use of different tools, etc? What level of standardisation makes sense?
    • Academics want to use what they use so standardisation makes little sense.
    • Standards useful for simplification, inter-operability. But the defacto standard might not be sufficient to support standards.
    • Develop best practices – researchers may ask what the best approach is.
    • Nudge researchers to best options, easiest to support options.
  • Comment: Code needs to work for a long time, hence standards are useful. Can steer researchers towards useful tools. 
    • Gradware/abandonware
  • Not possible to learn all libraries, software, tools, etc., to help researchers.
    • Offer support on some things not all, i.e. not where the skills don’t exist.
    • Divide the problem into something the RSE can work on that isn’t the physics, chemistry, etc.
  • Comment: combined many IT groups. Ten system admins, and then RSEs and other staff, storage, data analytics. Charge to grants etc. Cf. Model at Loughborough which doesn’t have the same scale but is similar.
  • There was more support for the nudge model, perhaps through the finance model. Fixed-cost, fixed-scope projects means that you can define the cost based on what the skills are, so if a researcher wants to use something unusual, the project will take longer and thus the charge will be higher, and the project would need to be divided into more phases due to risk.