<br><br><div class="gmail_quote">On Mon, Feb 6, 2012 at 1:30 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On Feb 6, 2012, at 1:27 PM, Matthew Knepley wrote:<br>
<br>
> On Mon, Feb 6, 2012 at 1:23 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Feb 6, 2012, at 1:14 PM, Matthew Knepley wrote:<br>
><br>
> > On Mon, Feb 6, 2012 at 1:11 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > On Feb 6, 2012, at 12:47 PM, Jed Brown wrote:<br>
> ><br>
> > > On Mon, Feb 6, 2012 at 21:42, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> > > I don't like this because it would mean calling VecSetUp() all over the place. Couldn't the ghosting flag be on the same<br>
> > > level as the sizes?<br>
> > ><br>
> > > Maybe VecSetUp() is wrong because that would imply collective. This memory allocation is simple and need not be collective.<br>
> > ><br>
> > > Ghosting information is an array, so placing it in VecSetSizes() would seem unnatural to me. I wouldn't really want VecSetGhosts(Vec,PetscInt,const PetscInt*) to be order-dependent with respect to VecSetType(), but maybe the VecSetUp() would be too messy.<br>


> ><br>
> > � Only some vectors support ghosting, so the usual PETSc way (like with KSPGMRESRestart()) is to calling the specific setting routines ONLY AFTER the type has been set. �Otherwise all kinds of oddball type specific stuff needs to be cached in the object and then pulled out later; possible but is that desirable? Who decides what can be set before the type and what can be set after? Having a single rule, anything appropriate for a subset of the types must be set after the type is set is a nice simple model.<br>


> ><br>
> > � On the other hand you could argue that ALL vector types should support ghosting as a natural thing (with sequential vectors just have 0 length ghosts conceptually) then it would be desirable to allow setting the ghost information in any ordering.<br>


> ><br>
> > I will argue this.<br>
><br>
> � Ok, then just like VecSetSizes() we stash this information if given before the type is set and use it when the type is set. �However if it is set after the type is set (and after the sizes are set) then we need to destroy the old datastructure and build a new one which means messier code. � By instead actually allocating the data structure at VecSetUp() the code is cleaner because we never need to take down and rebuild a data structure and yet order doesn't matter. �Users WILL need to call VecSetUp() before VecSetValues() and possibly a few other things like they do with Mat now.<br>


><br>
> We just disallow setting it after the type, just like sizes. I don't see the argument against this.<br>
<br>
</div> � We allow setting the sizes after the type.<br></blockquote><div><br></div><div>Since we are on a related subject: should then all type-specific processing of sizes be moved out of MatSetSizes()</div><div>into MatSetUp? �By this I mean this code:</div>

<div>�if (A->ops->setsizes) {</div><div>� � /* Since this will not be set until the type has been set, this will NOT be called on the initial</div><div>� � � �call of MatSetSizes() (which must be called BEFORE MatSetType() */</div>

<div>� � ierr = (*A->ops->setsizes)(A,m,n,M,N);CHKERRQ(ierr);</div><div>� } else {</div><div><br></div><div>This eliminates the need to check for the presence of various type-specific setup methods �-- they will all be called in MatSetUp after the type is guaranteed to have been set. �This would also make MatSetSizes not collective. �I imagine that Vec could be organized the same way. �I actually would prefer VecSetUp to explicitly delineate the end of the "factory" phase.</div>

<div><br></div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> � �Matt<br>
><br>
><br>
> � Barry<br>
><br>
> ><br>
> > � Sadly we now pretty much require MatSetUp() or a MatXXXSetPreallocation() to be called so why not always have VecSetUp() always called?<br>
> ><br>
> > Because I don't think we need it and it is snother layer of complication for the user and us. I think<br>
> > we could make it work where it was called automatically when necessary, but that adds another<br>
> > headache for maintenance and extension.<br>
> ><br>
> > � � Matt<br>
> ><br>
> > � We have not converged yet,<br>
> ><br>
> > � �Barry<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> > -- Norbert Wiener<br>
><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br>