Early 2021 Validation Actions for r4.2 Release Candidate Using Realistic Configurations - Summary Page

Last edition: Wikinfo(changed_ts)? by Wikinfo(changed_by)?

1. Overview
2. Validation Tickets
3. Tasks

Overview

We plan to deliver an r4.2 'Release Candidate' in May 2021 for thorough downstream assessment in IMMERSE WP6. In order to ensure the downstream testing progresses smoothly, we need deliver a robust, bug-free code. While developments will have passed the standard sette tests, many will not have been tested in full, realistic configurations which could expose unforseen issues. Several of the consortium institutes own highly complex, realistic research/operational configurations which can serve as challenging test cases for the code. The aim is to use these configurations to validate the r4.2 Release Candidate against a known release benchmark to ensure the code functions robustly in realistic operational/research applications.

Roadmap

In the first instance, we will need to ensure we have good coverage across resolutions and components with the configurations currently proposed. Once we have agreed that the configurations chosen give us a good coverage, the priority will be to get the realistic configurations “up-and-running” with the trunk. There are numerous practicalities involved in preparing configurations for the update such as modifications to input files and namelists. Once we have full details of the planned work, we should be able to some common tasks between the various groups, allowing them to share the workload. Once PIs have a working configuration (which may not be trivial!), we can move on to testing specific developments. These are numerous so we will need to list, prioritise and distribute these accordingly among the institutions. In rough chronological order the actions required are as follows:

1. Gather full details of the work planned to ensure good coverage across resolutions and components
2. Identify common tasks between groups where workload can be shared/centralised such as adaptation of input files
3. Run initial configurations and smooth out any issues that occur
4. List, prioritise and distribute developments to be tested
5. Decide on default settings for testing specific r4.2 developments

Communication

For each validation task there should be

• An associated ticket summarizing the status of the action, and appearing in the 2021 work plan page
• An associated wiki page, describing precisely the methodology, the results, the review, including figures

General progress on the work, details of bugs, reports on findings etc, should all be documented in these tickets, and discussions about ideas/solutions to issues should be carried out using in the comments section of these tickets (rather than email) to ensure visibility.

Regular updates on progress will be given at the NEMO ST VC

Summary/general information about the validation work as a whole may be stored on this page. The intention of this page is to store and share information relating to the validation work as a whole to ensure it is comprehensive and well-coordinated. It should not duplicate information stored in individual tickets/wiki pages.

Emailing the NEMO ST list can be used to bring significant issues to the attention of the group but the email itself should ideally point to a trac page (either here or an individual validation ticket) where subsequent communication on the matter can take place.

Validation Tickets

VLD-01_ClaireLevy_ORCA2_ICE_PISCES
VLD-02_Aimie_Moulin_Med_Wave_Coupling
VLD-03_Aimie_Moulin_Wave_Coupling_TestCase
VLD-04_Mueller_Tides
VLD-06_UKMO_GO8
VLD-07_Bricaud_Samson_ORCA4-12-36

Tasks

(Strikethrough when complete)

Phase 1: Gather full details of the work planned to ensure good coverage across resolutions and components

• PIs to create associated ticket and wiki page with full details of the planed validation work and methodology (ASAP)
• PIs to add link to validation ticket list above and enter the VLD number in the table below to allow us to determine whether we have sufficient coverage of components.

Coverage Table

Components

Domain

Features

Config

OCE

ICE

ABL

SAS

???

AGRIF

NF

BDY

qco

xios rst

isf

???

ORCA2

Y

Y

ORCA1

Y

Y

ORCA025

Y

Y (VLD-06)

Y

Y

Y

Y

Y

ORCA12

Y

Y

Y

ORCA36

Y

Y

Y

AMM7

Y

Y (VLD-??)

AMM15

Y

Y (VLD-??)

List of essential aspects not yet covered:

• ???

List of desirable aspects not yet covered:

• ???

Phase 2: Identify common tasks between groups where workload can be shared/centralised such as adaptation of input files

Phase 3: Run initial configurations and smooth out any issues that occur

Phase 4: List, prioritise and distribute developments to be tested

Phase 5: Decide on default settings for testing specific r4.2 developments