DFTK.jl icon indicating copy to clipboard operation
DFTK.jl copied to clipboard

Fix sternheimer tol in ForwardDiff and add paper references

Open gkemlin opened this issue 3 years ago • 3 comments

gkemlin avatar Oct 12 '22 08:10 gkemlin

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.

antoine-levitt avatar Oct 12 '22 18:10 antoine-levitt

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.

gkemlin avatar Oct 13 '22 06:10 gkemlin

@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:.

mfherbst avatar Oct 13 '22 06:10 mfherbst

Ok, so I close this PR and create a new one for the CG.

gkemlin avatar Oct 13 '22 12:10 gkemlin