CEP5

Status	Active
Author	David Ketcheson <dketch@gmail.com>
Created	Nov. 4, 2014
Updated	March 19, 2015
Discussion	Riemann #88
Implementation

Motivation

Sometimes Riemann solvers need more information than is currently available inside the routine without resorting to common blocks or module variables which inevitably are not thread safe. Similarly in higher dimensions some sort of module that contained functions for computing geometry related quantities would be less memory intensive than storing these quantities in the aux array which is now the standard (in 3D there are 13 fields that must be stored).

Specification

The proposed solution to this problem is to encapsulate geometry data into a defined geometry derived type defined (for 1D):

type geometry_type
    real(kind=8) :: x, dx, t, dt
end type geometry_type

An example Riemann solver module this new type would be defined as follows:

module rp1_advection
    
     implicit none

contains

subroutine rp1_ptwise(num_eqn, num_waves, geometry, q_l, q_r, aux_l, aux_r, wave, s, amdq, apdq)

    use geometry_module, only: geometry_type

    implicit none

    ...
    type(geometry_type), intent(in) :: geometry
    ...
end subroutine rp1_ptwise

end module rp1_advection

Backwards Compatibility Issues

This will clearly break backwards compatibility as the calling sequence will drastically change.

Notes

• See also the long discussion: https://groups.google.com/forum/?hl=en#!topic/claw-dev/7G67NxwzxsE.
• This proposal depends on accepting and implementing #89 first.
• Note also that this proposal is similar to #92.