<div dir="ltr">On Thu, Oct 24, 2013 at 1:15 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
> I would argue that Saad's implementation suggestions (like incremental<br>
> QR) are much better than the GCR and justify an independent citation.<br>
<br>
</div>The real difference is that GCR keeps two sets of vectors.  It does not<br>
have any "brute-force QR".  But GCR allows nonlinear preconditioners and<br>
provides the true residual at each iteration at no extra cost.  These<br>
weaknesses were not pointed out in the 1986 GMRES paper.  The 1993<br>
FGMRES paper did not cite the GCR paper, though it has pretty much the<br>
same attributes, minus GCR's ability to produce the true residual.</blockquote><div><br></div><div>I consider this level of dissection overkill.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
>>   "In practical implementation it is usually more suitable to replace<br>
>>   the Gram-Schmidt algorithm of step 2 by the modified Gram-Schmidt<br>
>>   algorithm"<br>
>><br>
>> If someone uses LGMRES, would we produce a citation only to Baker et al,<br>
>><br>
><br>
> Only to Baker. This should be easy since SS would be associated with GMRES.<br>
<br>
</div>What about CG with the single reduction or with Bill's trick?  Does that<br>
tweak mean that Hestenes and Stiefel don't get cited, where as they<br>
would be otherwise?<br></blockquote><div><br></div><div>I would cite H&S.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Who gets cited for PCFIELDSPLIT?</blockquote><div><br></div><div>I think no one. Breaking stuff into pieces is simply too elementary. If we can attach options</div><div>to citations, we could possible cite things.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>> or also to Saad & Schultz?  What about the BiCG family, containing many<br>
>> more variants that are slight variations on existing methods?  Or<br>
>><br>
><br>
> We need to build in support for selection with options I think.<br>
<br>
</div>Okay, to do this, we need to extend the interface to include one or more<br>
classification labels.  Should those labels be extensible (dynamically<br>
registered) or static (enum)?<br>
</blockquote></div><div class="gmail_extra"><br></div>Do you have to ask?<br><br>   Matt<br clear="all"><div><br></div>-- <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
</div></div>