On Feb 21, 2013, at 8:44 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Thu, Feb 21, 2013 at 7:28 PM, Boyce Griffith <griffith at cims.nyu.edu> > wrote: > > I would very happily use an "undefined" vector size. (I will also happily > change the bogus local sizes from 0 to 1, and the global sizes accordingly. > :-) > > The PETSc solvers that we use in the code should be oblivious to the size of > the vector. I've actually never been all that happy with size "0", but it > was in some inherited code, and at least so far, it has never caused any > problems over the 10+ years it has been in use. (If ever did start causing > problems, I certainly would not come complaining to petsc-users or petsc-dev. > It isn't like I do not realize that "0" is a potentially problematic value > here.) > > I actually have always hoped that setting size to "0" would help smoke out > any places where something actually did use the vector size. > > Okay, let's move the design discussion to petsc-dev. > > I want to understand the extent to your adaptivity and how your Vecs > "behave". In which places do you (mathematically) change the dimension of a > vector? These applications are mainly transient solvers in which regridding happens "between" time steps. > If I start with Vecs X and Y and I write > > VecCopy(X,Y); > YourSolver(X); /* solve F(X) = 0 with adaptivity */ > > can I then compare the result like this? > > VecAXPY(Y,-1.,X); Absolutely. > Do vector-space properties of Y (e.g., norm) change when I call > YourSolver(X). (Some codes keep a global view of all vectors, and when they > adapt, they regrid all vectors. But regridding doesn't preserve things like > norms, so you end up with tangled semantics.) At present all solvers operate only on fixed grid configurations. I do not expect this to change any time soon. -- Boyce -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130221/ec9220a7/attachment.html>
