Some answers to Chevron.cc questions

[Scott Haney]

Here are some answers to Jeffrey's questions from Chevron.cc.

/** QUESTIONS **/

// o. If several different fields are created using the same mesh
//    object, is the mesh object shared?

We used to have a mesh abstraction, but I removed this while writing 
fieldEngine for reasons that escape me right now. :-) This should 
probably be restored, which would (1) enable the sensible sharing of 
meshes that you describe and (2) allow for a generic implementation of 
fieldEngine.

// o. Can meshes be queried without going through an associated field?

Once the mesh abstraction is restored, yes.

// 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

// 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.

// 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.

// 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.

/** UNFINISHED WORK **/

// o ConstField = a Field with values that do not change

We used to have a ConstField, but we don't any more. We used to have 
ConstArray as well. These were removed to simplify expressions. Putting 
these back isn't, I think, something we want to do since they caused 
more problems than what they solved.

// o nearestNeighbors(inputCentering, outputCentering)
// o replicate(field, std::vector<FieldOffsetList>)

Nice! But is "replicate" the right word?

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

// o field.mesh()

We should be able to do this.

// o field.mesh().normals()

OK. I'm not sure we will do this as a member function, as above, or as 
an external function

normals(field.mesh())

// o field.mesh().normals().signedMagnitude()

Is this just

mesh.faceAreas() * dot(mesh.normals(), mesh.positiveNormals()) ?

Anyway, this isn't a question for the normals, but we can certainly do 
this.

// o sum(field, FieldOffsetList)

Sweeetttt. :-)