<div dir="ltr">Hi Song, I wonder if you have a reference paper on the preconditioning algorithm you are working on, i.e., using the 1st order flux for preconditioning purpose when your 'true' fluxes are evaluated using the 2nd order AUSM scheme.<div><br></div><div>Best,</div><div><br></div><div>Ling</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 1:34 PM, Song Gao <span dir="ltr"><<a href="mailto:song.gao2@mail.mcgill.ca" target="_blank">song.gao2@mail.mcgill.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks. I'll try to improve "my code" <br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-15 14:56 GMT-05:00 Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
> The way I read this, you are taking about 23 iterates/solve, and most of<br>
> your work is residual computation which should<br>
> be highly parallelizable/vectorizable. This seems great to me.<br>
<br>
</span>This in the sense that it's up to you to determine whether your<br>
matrix-free residual and preconditioning code is fast.  This profile<br>
merely says that almost all of the run-time is in *your code*.  If your<br>
code is fast, then this is good performance.  If you can use a different<br>
algorithm to converge in fewer iterations, or a different representation<br>
to apply the operator faster, then you could do better.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>