[petsc-dev] Jed will not be happy

[Barry Smith]

   Ok, I have removed the horrible branch on if (coords) from the interpolation code but left both the old and new versions there. You control the old or new version by defining NEWVERSION at the top of the file. Both versions pass all the ex36_ tests (does that mean that they are both good?).  Once we have some tests where old version breaks I can continue work on them. I have left by default to use the old version since that handles periodic  properly.

  Barry



On Aug 13, 2011, at 11:23 PM, Jed Brown wrote:

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