Re: [pooma-dev] Chevron Flow Scenario

[James Crotinger]

on 4/11/01 4:25 PM, Jeffrey Oldham at address@hidden wrote:

> I enjoyed reading your Chevron code description, which is much
> more understandable than the original paper.
> 
> As you noted, the Chevron flow (Lee et al.) algorithm is very
> similar to the Carmana et al. hydrodynamics code.  To ease programming
> the latter, I have previously proposed adding interpolation and
> restriction operators to convert between coarser and finer-grain
> fields.  To program the Lee et al. algorithm, the only additional
> necessary Pooma tool is these operators although this algorithm points
> to the need for these operators to work on face-centered fields.

Lee's algorithm also requires a linear solve in the neighborhood of every
vertex, unless further approximation is made. This can be done in parallel
by making iterates on each patch that then go through and run the solver on
each neighborhood in the patch. This sounds pretty slow to me, for a variety
of reasons. Lee's paper discusses lagging the off-diagonal terms to avoid
the solve. Doing this would be much more amenable to parallelization, I
think, but it makes the code fairly ugly.

> To implement the algorithm, first we would need to solve for
> the pressure gradients \grad(P), which are cell-centered on the
> finer-granularity field.  To compute the face-centered fluxes q on the
> more refined field, use a C++ statement like
> 
> q = dot( dot( replicate<2>(K), \grad(P)), replicate<2>(normals));

One problem with this representation is that calculating \grad(P) on the
fine mesh in the manner of their paper requires twice as much storage as
there is information content. The reason is that the neighboring \grad(P)'s
are related. 

I think that what one would want to do is to have the vertex-neighborhood
solve result directly in the evaluation of the q's. I look at this as a
mapping, basically, of the four cell-centered P's in the neighborhood of a
vertex into four q's on the half-face/edge neighborhood of the vertex.
\grad(P) is calculated at the centers of the sub-mesh in the process, but
this is 8 values (two at each sub-cell-center), so there is obviously some
duplicate information.

This is not meant to take anything away from the expressiveness of the
interpolation/restriction stuff. At first glance the syntax looks good. I
think a more general mapping within a neighborhood would be nice to develop
as well (as per above).

  Jim