Thank you very much! Ling
On Fri, Jan 15, 2016 at 1:58 PM, Song Gao <[email protected]> wrote: > Yes. > http://www.sciencedirect.com/science/article/pii/S0021999198960764 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sciencedirect.com_science_article_pii_S0021999198960764&d=BQMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=kuHHom1yjd94zUrBWecnYg&m=Z6JmjYd7euHq--9l5maVEB6hJHAkMcMNyc8rnVhgDC8&s=wfmA2PxK68XsQhc1PzBC4HCsxtwNAhBAmxe5VvnLj8Q&e=> > > It's on page 668 equation 4.6. > > Thanks > > 2016-01-15 15:39 GMT-05:00 Zou (Non-US), Ling <[email protected]>: > >> 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. >> >> Best, >> >> Ling >> >> On Fri, Jan 15, 2016 at 1:34 PM, Song Gao <[email protected]> >> wrote: >> >>> Thanks. I'll try to improve "my code" >>> >>> 2016-01-15 14:56 GMT-05:00 Jed Brown <[email protected]>: >>> >>>> Matthew Knepley <[email protected]> writes: >>>> > The way I read this, you are taking about 23 iterates/solve, and most >>>> of >>>> > your work is residual computation which should >>>> > be highly parallelizable/vectorizable. This seems great to me. >>>> >>>> This in the sense that it's up to you to determine whether your >>>> matrix-free residual and preconditioning code is fast. This profile >>>> merely says that almost all of the run-time is in *your code*. If your >>>> code is fast, then this is good performance. If you can use a different >>>> algorithm to converge in fewer iterations, or a different representation >>>> to apply the operator faster, then you could do better. >>>> >>> >>> >> >
