[petsc-dev] Jed will not be happy

[Jed Brown]

On Sat, Aug 13, 2011 at 23:03, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> > Dave showed some cases where the old code was producing incorrect
> results, and then wrote a bunch of new code to get second-order accurate
> interpolants.
>
>     It is possible the old code was producing incorrect results; but it is
> actually suppose to be doing pretty much the same as the new code in its
> design and logic (though not as clear) so I am not sure why it would
> generate
> different answers except for bugs. Any examples showing a difference?
>

Dave?


>
> > I thought the old code was also messy, so I didn't carefully audit the
> new code that came in passing the existing tests and adding new ones. I
> asked Dave about the code duplication and he wrote the following just before
> I fell off the internet for a couple days and then forgot to follow up. :-/
> >
> > 1) We never wanted to support non-uniform grids.
>
>     I'm totally confused. So it is only suppose to do uniform grids with
> uniform grid refinement? Ok but that is what the old code did. So is the new
> code just a "fix" for the old code (plus broken periodic) and should it have
> just replaced the old code? Why does the test code create a nonuniform
> coordinate vector then if it isn't used. Are all the tests done as tests on
> interpolating coordinates? Not on interpolating some function on the grid
> (yes I know coordinates are a particular case of functions on the grid, but
> no one I care about :-)).
>

Some people (us included) solve problems where the coordinates are part of
the solution, so having them live in bonified function spaces is useful. The
code runs on non-uniform grids (it would be much simpler otherwise), but it
assumes uniform refinement. You could also imagine a deformed grid that was
not precisely nested within its parent. In that case, you would need point
location and a bit more code complexity to handle ghost layer thickness. DA
refinement and coarsening is currently all regular, even though the starting
meshes may not be. Actually, an exception to this may be if you start with a
coarse mesh that is graded for a boundary layer. This case could still be
nicely nested, but must need to actually use coordinates, in which case the
current code must be incorrect.

Dave, was this something you originally intended to support?


>     That wasn't my plan. If I do a DARefine (say by 2) but then set in the
> coordinates on the finer mesh some scale coordinates is the
> DAGetInterpolation suppose to ignore the scaled coordinates?  Looks like it.
>

Are you going to maintain strict nesting such that corner nodes don't move
at all and edge/face nodes stay on the original coarse face/edge? I think
going the other direction (coarsening from a graded mesh) is more
meaningful, but both produce the same situation (described above) where we
really should be using coordinates.

  I don't understand this AT ALL. Currently the code completely ignores all
> coordinate information for non-periodic boundary conditions (assuming I
> guess uniform everything?) but you get all hot and bothered by the fact that
> you don't have coordinate values to do the interpolation for periodic case
> so you have to skip it. This seems completely contradictory to me?  I can
> use the periodic interpolation generated (with the old code) to do multigrid
> on a periodic domain just fine.  The "new" code could likely be very easily
> fixed to do the periodic case by using the same business with the unit
> element on the "extra" elements along the edge (like is done in the old
> code). Is all your rejection of the "periodic case" because you cannot
> interpolate "coordinates" in the periodic region? Big hairy deal
>

Haha, good point. So if we fix the interpolants to actually use coordinates
in the interior elements, do we silently assume the wrap element is regular
or somehow check if the mesh is regular nearby and error if it's not?


>   No I tried make runex36 per the standard naming convention and it said no
> such test. I didn't bother looking further than that figuring no one would
> break the standard naming convention.
>

Do you not have bash-completion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110813/5a6b97ca/attachment.html>