-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: more control of averaging potentials #1970
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, I think this PR is valuable as a proof of concept study that the averaging of potentials makes a positive difference, but we shouldn't merge it in in it's current form, simply because if we did we would immediately have to fix it up in a patch release anyway.
I think the best route forward is to introduce a PotentialSet
class (distinct from a PartialSet
and a PotentialMap
, and living somewhere in the middle - we might consider renaming the latter to make the separation clear, since the new PotentialSet
class would be based around a std::map
) into which we can implement the necessary de/serialisation and +=
/ /=
operators necessary for the Averaging
functions to work.
Co-authored-by: Adam Washington <adam.washington@stfc.ac.uk>
0e0b8e9
to
25a1d2f
Compare
Co-authored-by: Adam Washington <adam.washington@stfc.ac.uk>
3082f25
to
7f6629e
Compare
7f6629e
to
e919449
Compare
…lve into epsr-averaging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry - few things to consider. Almost there but not quite!
Added in capability to average over a specified number of iterations instead of each time. The hope is that this will fix an issue of spikes in r-factor when running the averaging of potentials currently.