The way I view changing sizes inside a (non)linear solver is that one does an 
approximate (non)linear solver, decides to adapt the mesh, then does another 
approximate (non)linear solver etc. So even though formally they may not be 
stopping the SNESSolve() and restarting one can think of it that way. Of course 
inside a Krylov linear solver this is nonsense because the inner produces 
cannot be done between old and new but with plain old linear multigrid it is ok.

   Barry

On Feb 21, 2013, at 7: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?
> 
> 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);
> 
> 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.)

Reply via email to