prckent
commented
2 years ago Thanks for opening the issue Josh. To echo some of our earlier conversations here: Since we need this urgently for science and we don't know if (say) improvements to the optimization algorithm will also be needed, it is important that we don't get caught up in unnecessary refactoring at this point. We should keep a note of where design improvements are needed though. e.g. While definitely not something to tackle in the OrbOpt work , there is quite a bit of repeated and non-specialized code in the Spline* classes that really should be designed away... at some point (@PDoakORNL , @ye-luo ). For now I think getting SplineR2R working will be very informative and tell us what the path for full feature coverage is. For example, while I don't like repeated code, if the implementation is trivial perhaps it is the pragmatic preferred route.
It's time to get orbopt working in solids. Taking the LCAO orbopt implementation as a guide, it looks like we'll have to implement a few methods for the following classes:
These three classes each derive from BsplineSet, which in turn derives from SPOSet. Implementing orbopt on these three classes means providing (at least) these two methods:
So far as I can tell, this is the bare minimum. But it's possible that I missed a helper function or two.
Discussions with Ye and others seem to indicate that SplineR2R is the first priority. This would mean that we would first implement orbopt for spline wavefunctions at gamma only. I.e. zero twist angle.
But one salient difference is that LCAOrbitalSet is a SPOSet, while SplineR2R is a BsplineSet which is a SPOSet. So there is an added layer in the class hierarchy for the splines. Should the plan be to specialize everything for each spline? That'd mean more code, at least at first.
Input, comments, suggestions, guidance, & etc. welcome.