Skip to content
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

Refactoring of Ewald summation policies and Energy class #247

Merged
merged 6 commits into from
Feb 11, 2020

Conversation

mlund
Copy link
Owner

@mlund mlund commented Feb 8, 2020

This refactors Ewald policies and Energy::Ewald with separate policy objects for PBC, IPBC with and without Eigen optimisations. The policy is changed from static to dynamic and unittests and an ewald example is provided. Effectively this means that all Ewald code has moved from headers to cpp.

  • Class policies for PBC, IPBC with and without Eigen optimisation
  • Documentation
  • JSON schema
  • Unittests
  • Ewald/water example (@bjornstenqvist)
    • add test values; should not run for more than a minute
  • Static condition for spherical_sum
  • Detailed code comments from @bjornstenqvist
  • Nanobench benchmarks
    • all policies; OMP

@mlund mlund added the code quality ⚙️ Code refactoring / restructuring label Feb 8, 2020
@mlund mlund added this to the Version 2.4.0 milestone Feb 8, 2020
@mlund mlund requested a review from rc83 February 8, 2020 18:34
Copy link
Collaborator

@rc83 rc83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice refactorization. Pairing strategy will fit there nicely in the future. Short summary follows:

  1. I am a proponent of a factory method, if enumeration is used to select and create a particular polymorphic instance.
  2. It should be possible to use automatic string-to-enum mapping in JSON.
  3. Can a group support g.at(i) and g[i] instead of awkward (g.begin() + i) syntax?
  4. A lot of work should be done to comply with our naming standard. I picked only that cases that annoyed me most. ;-)

double kappa2 = 0; //!< Squared inverse Debye screening length
double alpha = 0;
double const_inf = 0;
double check_k2_zero = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use a more descriptive name. It is difficult to guess what this variable of type double actually contains.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will talk more to @bjornstenqvist

private:
EwaldData data;
Policy policy;
std::shared_ptr<EwaldPolicyBase> policy; //!< Policy for updating k-space
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a matter of taste. I am used to call it “strategy” when using composition in pure object-oriented programming style, and “policy” if generic programming (i.e., templates) is involved.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many options, "method", "scheme", "policy", "strategy", "plan". Let's talk about this.

Copy link
Collaborator

@rc83 rc83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A candidate for a squash commit with a hand-improved commit message. ;-)

@mlund mlund merged commit 8e98fef into master Feb 11, 2020
@mlund mlund deleted the ewald-refactor branch February 11, 2020 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code quality ⚙️ Code refactoring / restructuring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants