On Tue, 20 Jan 2009, Roy Stogner wrote:
> On Tue, 20 Jan 2009, Tim Kroeger wrote:
>> Well, there is a problem. That is, it doesn't work. The attached test
>> application hangs up in the second refinement step. (It runs perfectly if
>> the edge_level_mismatch_limit() line is removed.)
> I've just committed a fix to SVN if you want to give it a try.
Works great now, thank you very much.
> Speaking of broken code, though, could you try ex20 with your
> PetscVector patch?
I just tried to do that right now, but I thought I'd just do "svn
update" before, and this turned out to fix my bug, because you have
already checked in my patch and your bugfix of it. Hence it works
> It seems to be breaking for me on the from-Vec
> constructor, which appears to assume that all parallel vectors have
> ghost mappings.
Well, I thought for a parallel vector without ghost dofs,
Vec::mapping->n would be equal to the result of VecGetLocalSize(),
hence my code would work as expected. If the truth is that in that
case Vec::mapping is a NULL pointer, then of course my code would
> While that's the eventual goal for all parallel petsc
> vectors created by the library, I'd like to keep the current
> less-efficient vectors working too, to support user-created vectors
> using the old API and to make testing easier as we switch to the new
Of course that's right.
> I can fix the copy constructor easily enough, but if there's
> any other places you might have made the same assumption (or if you
> can't replicate the problem or if you think I've misdiagnosed it), let
> me know.
There is no other place I made the assumption mentioned above. Hence,
everything might be fine now.
Dr. Tim Kroeger
tim.kroeger@... Phone +49-421-218-7710
tim.kroeger@... Fax +49-421-218-4236
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany