Summary:

This was a meeting to kick start the development of a UKNR Collaborative Computing Community, which will hopefully transition to a Collaborative Computing Project at the end of our two year grant. Collaborative Computing Projects aim to develop scientific code as infrastructure, supported by the Computational Science Centre for Research Communities (CoSeC). This work will build our connections both within the community and with CoSeC. The meeting was also attended by the director of CoSeC, Stephen Longshaw, who provided the community with a short overview of the organisation and also answered many of our questions. The meeting involved a lot of lively discussion – the goal was to start to identify some of the questions we need to address and the goals we want to set, and to have CoSeC confirm we were roughly on the right track, which they did! We believe that we have a lot more clarity moving on from here.

Issues discussed:

• Our proposal had identified 6 areas of work: strategic planning, code development, code exploitation, community building, training, and outreach. Discussions today touched on all areas but focussed mainly on the first 3 areas.

• For strategic planning, key questions involved how much we wanted our codes to rely on other software infrastructure, whether we should diversify or consolidate, whether we should develop new methods or rely on existing solutions. Considerations involve the conflict between time spent on code versus science,  the ability to do something quickly that is “good enough” versus using new and potentially better methods in the longer term. A key question was to what extent we wanted to tie the community to AMReX who have uncertain funding going forward. Realistically we don’t have the capacity to develop an alternative, and given that the software is already mature, we may just have to accept these risks, with new tools/bugfixes developed by us if AMReX stops being actively supported (although this seems unlikely). Nevertheless, it was pointed out making such choices is not only a matter of convenience and expediency, but does entail picking a technology path (in this case, Berger-Rigoutsos type block-structured AMR), which might not be optimal for some applications, thus providing support for alternative methodologies is important.

• On code development, we thought about what we would do if we had infinite RSE support (which we don’t!). Some “wishlist” items included making it easier for students to get started with codes on new systems, potentially developing and supporting package management tools, getting RSEs more involved with the research, benchmarking codes for comparison and documenting codes and tools. One suggestion was to initiate some formalised way to exchange information and expertise, perhaps via ECR exchanges between groups. Whilst it is good to avoid all following the same dogma when tackling NR problems, such exchange has the potential to spark novel ideas and spread best practise. There was agreement that developing some level of shared tools, particularly for post processing, was desirable for the community, which may involve agreeing some standards for data outputs that groups could commit to using, or “upstreaming” tools to AMReX.

• On code exploitation, the open question is to what extent we want to provide support for our open sourced codes beyond the immediate UKNR community. Do we want to provide a “helpdesk” function or online tutorials? There is a significant skills/knowledge gap in GR/HPC and numerical methods for many new PhDs, and this creates a steep learning curve when they start research.  Could this be addressed by specific training, e.g. a UKNR summer school? Again, better documentation could help here, but it was recognised that people need hands-on support. Community support and peer-to-peer mentoring by ECRs usually works well and should be encouraged. We also discussed how to increase the number of underrepresented groups in the community, e.g. by targeted outreach programmes for undergraduates, to maintain a welcoming community for everyone and maximise talent and ability in UKNR.

Next steps:

• One of the main goals for the next phase is to write a report for cosec, who will provide us with a template in due course. The report needs to highlight what we need to do to benchmark/assess the status of our codes, and identify where we could get support from CoSeC. The report could lead to a “position paper” being published, that documents the status of the UK community and its decisions/strategy.

• Input wanted! We will be happy to receive suggestions or comments from the community, and will suggest some specific ways to do this shortly.