Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Design Document page provides a description of the algorithms, implementation and planned testing including unit, verification, validation and performance testing. Please read  Step 1.3 Performance Expectations that explains feature documentation requirements from the performance group point of view. 

Design Document

 Click here for instructions to fill up the table below ......

The first table in Design Document gives overview of this document, from this info the Design Documents Overview page is automatically created.

In the overview table below 4.Equ means Equations and Algorithms, 5.Ver means Verification, 6.Perf - Performance, 7. Val - Validation

  • Equations: Document the equations that are being solved and describe algorithms
  • Verification Plans: Define tests that will be run to show that implementation is correct and robust. Involve unit tests to cover range of inputs as well as benchmarks.
  • Performance expectations: Explain the expected performance impact from this development
  • Validation Plans: Document what process-based, stand-alone component, and coupled model runs will be performed, and with what metrics will be used to assess validity

Use the symbols below (copy and paste) to indicate if the section is in progress or done or not started.

In the table below 4.Equ means Equations and Algorithms, 5.Ver means Verification, 6.Perf - Performance, 7. Val - Validation,   (tick) - competed, (warning) - in progress, (error) - not done


Overview table for the owner and an approver of this feature

1.Description

This is a descriptive long title
2.Owner
3.Created
4.Equ(error)
5.Ver(error)
6.Perf(error)
7.Val(error)
8.Approver
9.Approved Date
V1.0
 Click here for Table of Contents ...

Table of Contents




Title: NH Dycore with SL Transport

Requirements and Design

E3SM Water Cycle Group

Date:  

Summary

The purpose of this section is to summarize what capability is to be added to the ACME Ocean and Ice system through this design process. It should be clear what new code will do that the current code does not. Summarizing the primary challenges with respect to software design and implementation is also appropriate for this section. Finally, this statement should contain general statement with regard to what is “success.”


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

Date last modified:   
Contributors: Peter Bosler, Andrew Bradley, Oksana Guba , Mark Taylor, Andrew Steyer (Unlicensed), Paul Ullrich

The formulation of the nonhydrostatic equations is documented in a journal paper to be submitted to JAMES:  https://www.overleaf.com/read/bqycjpqjthnc

The SL transport algorithm is documented in two recently accepted CISC papers:   


Design and Implementation

Date last modified:   
Contributors: 


The code has been implemented in the HOMME dynamical core as a non-default compile time option:   https://github.com/E3SM-Project/E3SM/tree/master/components/homme
The NH dycore is build by specifying the "theta-l" target, as opposed to the default "preqx" target.   The "theta-l" model reuses much of the existing E3SM code, with all new code specific to "theta-l" placed in the  https://github.com/E3SM-Project/E3SM/tree/master/components/homme/src/theta-l directory.  
The SL transport algorithm is turned on via  The SL transport algorithm is turned on via namelist options.  COMPSETS will be created that use the recommended options with the PR submitted with this design document.  


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)


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?

Planned Validation Testing 

Validation 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? 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?

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?



  • No labels