DFTK.jl
DFTK.jl copied to clipboard
Fix sternheimer tol in ForwardDiff and add paper references
So this is probably where the tradeoff in using an external solver vs rolling our own changes. Cg (unlike, say, gmres, anderson, arnoldi etc), is trivial to code, there's nothing one implementation could do better than the other, and our custom requirement is not trivial to factor out to IterativeSolvers. So let's just do our own? It'll lead to less code in the end.
In fact we might want to start thinking about using our own custom solvers more. For instance, nlsolve has probably resulted in more trouble than it's worth (I'm the one that coded anderson in nlsolve in the first place, we have our custom anderson anyway, we do very strange dances to conform to nlsolve, and I'm pretty sure nlsolve is the number 1 reason our latency is so bad). There's not a lot of activity that goes into improving the julia packages for solvers, so we don't miss out on much. Anyway, just a random thought, I'm not suggesting we do anything about nlsolve now.
Yes ! I suggest we keep this branch pending then, I create a new one with only the doc update with the paper and we talk about the cg at the meeting this afternoon.
@antoine-levitt NLSolve I agree, but about the CG let's discuss.
@gkemlin Minor remark: That's the reason why it's usually a good idea to keep to one PR per feature :smile:.
Ok, so I close this PR and create a new one for the CG.