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 7 Next »

The Design Document page provides a description of the algorithms, implementation and planned testing including unit, verification, validation and performance testing. 

Design Document

Overview table for the owner and an approver of this feature

1.Name

2.OwnerGautam Bisht
3.Created
4.Equ(error)
5.Ver(error)
6.Perf(error)
7.Val(error)
8.Approver
9.Approved Date
 Click here for Table of Contents ...

Table of Contents

 

Title: Variably Saturated Flow Model (VSFM): A Unified treatment of hydrologic processes in the unsaturated-saturated zone

Requirements and Design

ACME Land Group

Date:  

Summary

Groundwater, which accounts for 30% of freshwater reserves globally, is a vital source for human water supply. Climate change is expected to impact the quality and quantity of groundwater in the future. Numerous studies have shown a positive soil moisture-rainfall feedback through observational data, as well as, numerical simulations. Despite the obvious need to accurately represent soil moisture dynamics, the version-0 of the ACME Land Model (ALM) employs a non-unified treatment of hydrologic processes in the subsurface. Presently, ALM simulates transport of water in the subsurface via a theta-based Richards equation that is loosely coupled to an unconfined aquifer model to account of groundwater–soil water interaction. This ad hoc treatment of vadose–phreatic zone interaction at times results in unphysical model prediction of unsaturated soil layers below predicted water table.

A variably saturated flow model (VSFM) will overcome above-mentioned shortcoming by using pressure-based Richards equation that is valid in unsaturated and saturated zone. The VSFM solver will use finite volume spatial discretization and backward Euler time integration. The nonlinear equations resulting from spatial and temporal discretization will be solved using the Portable, Extensible Toolkit for Scientific Computation (PETSc).

Requirements

Requirement: name-of-requirement-here

Date last modified:  
Contributors:  (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: 10/20/2015
Contributors: Gautam Bisht

 

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.

 

  • The governing PDE for flow in porous media is given as:

d/dt (rho * phi * sat) = - Div (rho * q) + Q  ... (1)

where 

rho = density of water, which is a function of pressure and temperature,

phi = porosity,

sat = liquid saturation

q = darcy flux

Q = source/sink of water (e.g. infiltration, evapotranspiration, bare soil evaporation)

Div = divergence operator

 

  • The Darcy flux is given by q = - k kr / mu * Del (P)   ... (2)

where 

k = permeability,

kr = relative permeability.

mu = viscosity,

P = liquid pressure

 

  • Following discretization schemes are used to numerically solve Eq (2):
    • Spatial discretization: Finite volume,
    • Temporal discretization: Backward Euler scheme 

 

  • The discretized equations form a system of nonlinear equations.

 


Design and Implementation

Implementation: short-desciption-of-implementation-here

Date last modified: 10/20/2015
Contributors: Gautam Bisht

 

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?
  • Initial prototype of the VSFM model will be developed in MATLAB.
  • The VSFM implementation in ACME would use PETSc.
    • SNES solver of PETSc will be used to solve the system of nonlinear equations that is obtained after applying spatial and temporal discretization
    • The future goal of ACME is to solve tightly coupled transport of water in the soil with other relevant physics (e.g. transport of water in roots [ACME V2]). Thus, the current VSFM will use DMComposite feature of PETSc. DMComposite allows an application to brea

 

Planned Verification and Unit Testing 

Verification and Unit Testing: short-desciption-of-testing-here

Date last modified: 10/20/2015 

Contributors: Gautam Bisht

 

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: 10/20/2015 

Contributors: Gautam Bisht

 

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?

  • The VSFM will be tested against previously benchmark problems published.
  • Additionally, VSFM will be tested against PFLOTRAN for certain benchmark problems.

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