FAB Project Board Agenda Minutes August 2020

7th August 2020

Attendees:

• Glenn Greed (Met Office) - Project Exec
• Richard Gilham (Met Office) - Project Manager
• Steven Wardle (Met Office) - Tech Lead
• Steve Mullerworth (Met Office) - LFRic stakeholder
• Douglas Boyd (Met Office) - UM Partnerships stakeholder
• Giorgia Line (Met Office) - Secretary

Matthew Shin (fcm-make stakeholder) and Keir Bovis (NGMS stakeholder) sent their apologies.

Actions From Last Project Board

ACTION 1- RG to rewrite deliverables to be more explicitly in LFRic language (do XYZ, add examples). Carried Over from last PB.

• SW wants us to tick off the requirements of LFRic. This is currently being monitored, GG suggests plans going forward should have clear alignment to LFRic requirements. Action Closed.

ACTION 2- ALL to add to stakeholder document along with outline details Document needs full review. Carried Over from last PB.

• Stakeholder document needs review. GG suggests discussing a comms plan to make sure everyone is kept informed as things mature

ACTION 3- RG to invite DB from partnerships in preparation for engagement in the future. Carried Over from last PB.

• DB present at meeting, action closed.

ACTION 4- Stakeholder review

• See A2.

Highlight Report

Phase 3 highlight report

(Includes staff welfare)

Progress Against Deliverables

• SW has been talking to other teams about their GitHub workflows, to get a better idea of what working practices might work best as we begin introducing partners. Future action suggested that we engage with Stuart and Victoria in their GitHub analysis.
• The extraction tool is sufficient at this stage in the project. Enhancing this has been left as low hanging fruit for introducing for external collaboration.
• Changing the Fab infrastructure support C code turned out to be more involved than expected but came at an early enough stage not to be unmanageable. GG asked about adding C++ support in the future, SW thinks the changes being made now will make the project flexible enough to add this later on.
• Configuration file and parser - Done
• 2nd Fortran Compiler - Stretch goal not fully achieved but work towards C code support introduced the flexibility needed to allow it in the future. SW suggests supporting an open source compiler so it can be used in continuous integration testing.
• Objectives are driving developments rather than stalling it.
• RG would like more time to keep an eye on things but due to the additional challenges of 2020 this has been a problem. There aren't enough people to go around for all the work the team has going on. For the first one to two thirds of a phase GL and SW get tied up with the UM release, meaning Matthew Hambley ends up doing a disproportionate amount of work.
• There will be a pause in August while SW’s is on leave.
• SW introduced a risk associated with the testing platform on GitHub; testing is opaque, making it hard to track down the root cause when something goes wrong in the environment. To mitigate this, SW has been looking into using a VirtualBox with ubuntu to test more interactively to avoid time wastage. However, VirtualBox is not working at the moment. RG suggests SW takes an action to report back, with this recorded as a risk or debt for now.
• DB asked whether Fab will have JEDI builds in scope. The answer is that it will not at the moment, though it would be nice to add this in the future. It is suggested we reach out to ECMWF, to see if Fab is more accessible than ECBuild, which is what JEDI is currently using. Related to the earlier discussion of C++ support, JEDI is also written in C++. There is a possible long term goal of having one build system for the whole office. DB also suggests utilising the ATLAS build expertise on his team.
• Staff Welfare concerns due to the reduced and redirected resources, along with 2020 pressures. GG says issues should be raised as early as possible to mitigate this and help prioritise work as necessary. It is also suggested that Fab’s development phases be moved out of sync with the UM and LFRic development cycles to avoid the disproportionate time problem.

Main Agenda

Pathway to Green

At the last NGMS programme board, Fab reported only Issues at Amber. As mentioned in the highlight report, these issues have since been reduced to risks. This will likely result in the amber swapping to risks, meaning we now need to reduce risks to green. Given the widespread shortage of SSE resource, this is a risk we will probably have to put up with long term. RG suggests considering when major UM development will wind down to free up resources.

Keir recently carried out a project audit, which generally went well, giving Fab an amber rating on stakeholders but green or better for everything else. The project is currently blue on risks as they are regularly reviewed and assessed. It was decided the project review report should be put on the NGMS program pages, not on the Fab project pages. The actions arising were:

• A1: Include a high-level statement describing the overall scope for the FAB project in project requirements.

  RG has taken this as an action, to add a high-level statement of the project’s scope and circulate it for review to GG and DB.

• A2: Undertake a mapping of the FAB requirements to planned delivery in project phases and identify those that form the critical path activities

  This has been discussed and will be factored into phase 4 onwards by cross-referencing between the requirements, phase plan and relevant issues.

• A3: Ensure the FAB UML diagram is updated as the scope of the project evolves and bring options for alternative design to the project board where appropriate for agreement

  Ongoing, with regular Project Manager review. SW has taken an action to forward the latest UML diagram to Richard Hattersley for review as he is the 'customer', and as it needs to be a standard for C4. It is also suggested that the requirement be checked because currently these are just class diagrams.

• A4: Project Manager to consider the scheduling project board within the next 3 months.

  Project Board meeting scheduled; action closed.

• A5: Ensure the needs of stakeholders are discussed regularly at Project Board meetings.

  See below.

Stakeholder discussion

Stakeholder Analysis Page

• GG questions our use of the term stakeholder on the stakeholder page, as many of those listed are interfaces to stakeholders rather than stakeholders themselves. To be considered in future.
• SW suggests inviting JEDI to get involved, though GG suggests this should wait until Fab works for LFRic, to avoid overextending project goals before key deliverables are met
• While there has been significant contribution from Mat Shin, he has not yet been involved in technical presentations. The Fab team has taken an action to involve Mat Shin in technical discussions from now on to learn from his experience.
• Overall the Project Board is happy with the current list of stakeholders, though it may be added to as we start involving collaborators.
• SW suggests engagement with coupled code experts, e.g. ocean code.
• RG suggests looking into a list of current FCM make users as they will be affected. However, it is worth being mindful that, depending on timescales, these coupled projects may have moved to JEDI by the time they become relevant to Fab and so may be brought in the long way around.
• GG suggests thinking about when and how we are going to pass out information and talk to partners. RG suggests catching this in the phase 4 plan.
• The current Coms Channels are:
  • Teams Chat - Private, internal
  • Teams Channel - Not currently in use
  • Email - Used for contacting the broader board and stakeholders
  • GitHub – Used for static communications
  • Further ad hoc coms

Plan for Phase 4

September – November 2020 Aims:

• Cyclone support
• Fortran - C interoperability
• Annotate the Requirements page with complete and outstanding items
• Demonstrate building JULES or a suitable alternative. JULES is suggested for its use as real world example without too many complications (no need to build various libraries, etc.) that is used in both the UM and LFRic.
• Seek expression of interest from partners via the partner development group, TING, and through reaching out to individuals. Possibly have them enhance the extraction tool.
• DB suggests possibly discussing partnership work with Cyclone experts at the NEWA, as they seemed very enthusiastic about getting involved with build systems, though this could also introduce a risk as it's on the critical path.

Phase 4 will noy include:

• Branch merging in extract tool yet
• Building libraries
• Inc Builds until we can do regular builds. SM raised a point that Inc builds test the system’s dependency analysis, however SW says the team are keeping these in mind during development and reviews are but not focussing on making them work completely yet, until more basic builds have been demonstrated.

By Phase 5 we hope to be involving partners more fully, and aim to be able to build LFRic, while Phase 6 will be ironing out the details.

AOB

DB questioned why the project had been housed on GitHub? The answer was that there was no reason for it to be housed on a closed system, and this way it can be used by others in the future without needing to be UM partners, as It is released under a BSD3 licence.

Next Meeting

Date TBC, aiming for early December.

Actions for next Project Board

A1 – Fab team to engage with Stuart and Victoria in their GITHUB analysis.

A2 – SW to report back on progress with using a VirtualBox with ubuntu to perform more interactive testing.

A3 – RG to add a high-level statement of the project’s scope and circulate it for review to GG and DB.

A4 – SW to forward the latest UML diagram to Richard Hattersley for review, and check whether class diagrams meet the requirements.

A5 –RG to discuss with DB how best to communicate with partners to seek expressions of interest for collaboration.