Re: [pooma-dev] Some answers to Chevron.cc questions

[Jeffrey Oldham]

On Fri, Jul 27, 2001 at 08:57:06AM -0600, Scott Haney wrote:
> 
> // o. According to my understanding, the Chevron algorithm should be
> //    imbedded inside a loop of some type that repeatedly updates the
> //    coordinates.
> 
> I don't think this is right. I thought this was an eulerian calculation. 
> It is, after all, just a liquid flowing through dirt. What part of the 
> paper

Is not a loop necessary for a finite difference method?

> // o. I omitted a separate coordinates field, presumably updated each
> //    iteration, in favor of using the mesh.  Since I do not know how
> //    the coordinates are updated, I omitted updating the mesh.
> 
> OK.
> 
> // o. Is it important to flesh out the linear algebra solution?  We
> //    might learn something about field syntax, but it will also take
> //    time for me to determine the correct operands.
> 
> Yes, I think we should do this. This will be an interesting use of 
> neighbor operations in scalar code. Recall that we're simply solving for 
> the pressure gradient values that give continuity of the pressure at the 
> face centers and continuity of the fluxes at the spokes.

OK.  I will look into this.

> // o. The eight spoke-centered flux values are discontinuous, right?
> 
> Not really. Once we correctly solve for the pressure gradients, the flux 
> should be continuous.

I do not understand this.  By "flux value" I mean q in your algorithm
explanation.  These values are set using only values within a cell so
how can they be shared by adjacent cells?

> // o. Creating non-canonical edge and face centerings requires
> //    dimension-dependent code.  Is this acceptable?
> 
> No, it isn't acceptable. The good news is that I don't believe it 
> requires dimension dependent code. Figuring out how to do this will 
> teach us something about facilities we need to provide.

I'm deferring this until later.

> /** UNFINISHED WORK **/
> 
> // o replicate(field, std::vector<FieldOffsetList>)
> 
> Nice! But is "replicate" the right word?

This is an unnecessary function.  If each output field value equals
exactly one input field value, this function makes the copy without
the overhead of a loop.  Is the name OK?

> // o meshLayout.unitCoordinateNormals()
> 
> This isn't something a layout should do. Is this just the N coordinate 
> normals, e.g.,  {(0,1),(1,0)}? If so, why a field? If not, what is this 
> exactly?

No, these are unit-length normals perpendicular to the mesh faces but
pointing in positive directions.

> // o field.mesh().normals().signedMagnitude()
> 
> Is this just
> 
> mesh.faceAreas() * dot(mesh.normals(), mesh.positiveNormals()) ?

Yes.

Thanks,
Jeffrey D. Oldham
address@hidden