...
| Page Properties | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||
|
| Expand | |||
|---|---|---|---|
| |||
|
Title:
...
MPAS-CICE
Requirements and Design
ACME
...
Ocean-Ice Group
Date:
...
September 25, 2015
Summary
Requirements
Requirement: name-of-requirement-here
Date last modified: // date
Contributors: @ name (add your name to this list if it does not appear)
Each requirement is to be listed under a ”section” heading, as there will be a one-to-one correspondence between requirements, design, proposed imple- mentation and testing. Requirements should not discuss technical software issues, but rather focus on model capability. To the extent possible, require- ments should be relatively independent of each other, thus allowing a clean design solution, implementation and testing plan.
Algorithmic Formulations
Design solution: short-description-of-proposed-solution-here
Date last modified:// date
Contributors: (add your name to this list if it does not appear)
For each requirement, there is a design solution that is intended to meet that requirement. Design solutions can include detailed technical discussions of PDEs, algorithms, solvers and similar, as well as technical discussion of performance issues. In general, this section should steer away from a detailed discussion of low-level software issues such as variable declarations, interfaces and sequencing.
Design and Implementation
Implementation: short-desciption-of-implementation-here
Date last modified: // date
Contributors: (add your name to this list if it does not appear)
This section should detail the plan for implementing the design solution for requirement XXX. In general, this section is software-centric with a focus on software implementation. Pseudo code is appropriate in this section. Links to actual source code are appropriate. Project management items, such as svn branches, timelines and staffing are also appropriate. How do we typeset pseudo code?
Requirements
Requirement: CICE 4.0 column physics
Date last modified:
Contributors: Todd Ringler (Unlicensed), Adrian Turner and Elizabeth Hunke (Unlicensed)
MPAS-CICE is required to utilize column physics that is equivalent or better than CICE 4.0.
Requirement: CICE 4.0 EVP solver
Date last modified:
Contributors: Adrian Turner
MPAS-CICE is required to use a constitutive relation that is equivalent or better than the elastic-viscous-plastic (EVP) solver used in CICE 4.0.
Requirement: CICE 4.0 velocity solver
Date last modified:
Contributors: Adrian Turner
MPAS-CICE is required to use a velocity solver that is equivalent or better than that used in CICE 4.0.
Requirement: CICE 4.0 transport
Date last modified:
Contributors: Adrian Turner
MPAS-CICE is required to use a transport scheme that is equivalent or better than that used in CICE 4.0.
Algorithmic Formulations
Design solution: CICE 4.0 column physics
Date last modified: September 25, 2015
Contributors: Adrian Turner and Elizabeth Hunke (Unlicensed)
CICE 4.0 column physics has been documented outside of ACME. Reference peer-reviewed CICE 4.0 here: reference
Design solution: CICE 4.0 EVP solver
Date last modified: September 25, 2015
Contributors: Adrian Turner
The EVP solver is documented here: reference
Design solution: CICE 4.0 velocity solver
Date last modified: September 25, 2015
Contributors: Adrian Turner
The velocity solver is documented here: reference
Design solution: CICE 4.0 transport
Date last modified: September 25, 2015
Contributors: William Lipscomb (Unlicensed)
CICE 4.0 transport uses incremental remapping. Incremental remapping on a convex polygons is documented here: Lipscomb, W., & Ringler, T. (2005). An incremental remapping transport scheme on a spherical geodesic grid. Monthly Weather Review, 133(8), 2335–2350.
Design and Implementation
Implementation: CICE 4.0 column physics
Date last modified: September 25, 2015
Contributors: Adrian Turner and Elizabeth Hunke (Unlicensed)
Since the column physics is independent of the horizontal grid and discretization, identical source code for the column physics can be used in POP-CICE and MPAS-CICE. The design solution here is to extract the column physics into a "stand-alone" repository and "import" that repository into POP-CICE and MPAS-CICE at build time.
Implementation: CICE 4.0 EVP solver
Date last modified: September 25, 2015
Contributors: Adrian Turner
The EVP solver is independent of horizontal discretization, so its implementation in MPAS-CICE can be identical to its implementation in POP-CICE.
Implementation: CICE 4.0 velocity solver
Date last modified: September 25, 2015
Contributors: Adrian Turner
The velocity solver utilizes a new finite-element discretization for solving the momentum equation including the important divergence of stress tensor term.
Implementation: CICE 4.0 transport
Date last modified: September 25, 2015
Contributors: William Lipscomb (Unlicensed)
The Incremental Remapping (IR) scheme follows closely in concept to that shown in Lipscomb and Ringler (2005) (LR). On notable change is the computation of back-trajectory. In LR, departure areas were obtained by sorting back velocities not the appropriate cell, finding intersections and building areas. Essentially, the LR method was to do all of the "by hand". For this updated implementation of IR, we will use third-party tools to compute departure areas. These tools take any two convex polygons as input and return the area of overlap as output.
Planned Verification and Unit Testing
Verification and Unit Testing: short-desciption-of-testing-here
Date last modified:
Contributors:
(add your name to this list if it does not appear)Adrian Turner
How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?We will configure MPAS-CICE using both quadrilaterals (POP) and convex polygons (MPAS). Both of these configurations will be using "real world" grids of the ocean / sea-ice domain. Since the v1 MPAS-CICE uses most of the same physics/dynamics/parameterizations as POP-CICE, we will verify the code by comparing MPAS-CICE with quads to POP-CICE. Once this level of verification is complete, we will compare MPAS-CICE with convex polygons to MPAS-CICE with quads.
In addition to verifying the full system in the many, each of the components (column physics, EVP, velocity solver and incremental remapping) are verified individually.
Planned Validation Testing
Validation Testing: short-desciption-of-testing-here
Date last modified:
Contributors:
(add your name to this list if it does not appearAdrian Turner and Elizabeth Hunke (Unlicensed)
How will XXX be tested? What observational or other dataset will be used? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?Validation of MPAS-CICE will occur through analysis of coupled ocean / sea-ice simulations with CORE II forcing. These simulations will be carried out on each of the meshes target for the ACME coupled simulations and /wiki/spaces/OCNICE/pages/1867925.
Planned Performance Testing
Performance Testing: short-desciption-of-testing-here
Date last modified:
Contributors:
(add your name to this list if it does not appear)How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?
Patrick Worley (Unlicensed), Philip Jones, Adrian Turner
Performance evaluation will be carried out concurrently with the validation testing, i.e. using coupled ocean / sea-ice simulations with CORE II forcing.