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

reaction_methods: new optional keyword exclusion_radius_per_type #4469

Merged
merged 1 commit into from
Mar 17, 2022

Conversation

pm-blanco
Copy link
Contributor

@pm-blanco pm-blanco commented Mar 9, 2022

Fixes #4437

Description of changes:

  • The keyword exclusion_radius has been renamed to exclusion_range.
  • If the keyword exclusion_radius is provided, a keyerror warns the user that exclusion_radius is obsolete and the current equivalent keyword is exclusion_range
  • The reaction methods now take exclusion_radius_per_type as an optional argument.
  • The exclusion range between two particles is calculated as their sum of their radii in exclusion_radius_per_type, following the Lorentz-Berthelot combining rule.
  • If the exclusion radius of one particle type is not defined, the value of the parameter provided in exclusion_range is used by default.
  • If the value in exclusion_radius_per_type is equal to 0, then the exclusion range of that particle type with any other particle is 0.
  • A new section have been added in doc/sphinx/advanced_methods.rst to explain how to couple the reaction methods to molecular dynamics, including the new features of this PR.
  • New unit tests have been included in src/core/reaction_methods/tests/ReactionAlgorithm_test.cpp to check the behavior of exclusion_radius_per_type
  • The loop over all particles in ReactionAlgorithm::check_exclusion_range now breaks if one particle is found within the exclusion range of the inserted particle.
  • All benchmarks, samples, tests and tutorials have been changed accordingly.

I checked the computational efficiency using the benchmark in maintainer/benchmarks/mc_acid_base_reservoir.py and this PR improves the MC computational by a 15% compared to the current python branch (MC timing: 1.268e-04 vs 1.395e-04, this PR vs current python, respectively). Probably the gain could be even higher for dense systems.

@review-notebook-app
Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@jonaslandsgesell
Copy link
Member

jonaslandsgesell commented Mar 10, 2022

May I suggest to make the exclusion radius a required keyword, forcing the user to explicitly consider what parameter makes sense. Ideal reactions are rarely executed in Espresso which is why I would not use a default value which will only work for ideal systems, when not only MC moves are performed (but also MD moves).

@pm-blanco
Copy link
Contributor Author

pm-blanco commented Mar 10, 2022

May I suggest to make the exclusion radius a required keyword, forcing the user to explicitly consider what parameter makes sense. Ideal reactions are rarely executed in Espresso which is why I would not use a default value which will only work for ideal systems.

@jonaslandsgesell the exclusion radius is still a required keyword. An ideal system system is only assumed if the user provides exclusion_radius={}.

If the user does not provide an exclusion radius for a particle type, such particles are assumed to have an exclusion radius equal to 0, which I agree that could be potentially dangerous. Since in principle the user can create new particle types after the reaction methods have been initialized, the only alternative way that I can think of is to check it during the particle insertion and throw an error if a particle type without an exclusion radius is found. In practice, this would force the users to define an exclusion radius for all particle types that exist within their simulations. However, such change would force us to make the exclusion radius a required keyword for the widom insertion too, which would be annoying since it is not actually necessary.

@pm-blanco pm-blanco marked this pull request as ready for review March 11, 2022 12:33
@pm-blanco
Copy link
Contributor Author

@jonaslandsgesell I have figured out a way of checking that all the existing particle types have a defined excluded radius without having to force the user to define an exclusion radius when using the widom insertion method. I belive that the issue is now solved.

@jonaslandsgesell
Copy link
Member

jonaslandsgesell commented Mar 11, 2022

@pm-blanco thanks for having a look.

Short disclaimer: I did not have a deeper look at your changes due to time :) maybe you already have a great solution but here are some things which popped up in my mind when thinking about the exclusion radii.

  • Would it make sense to require the user to supply a dictionary contains at least one numeric exclusion radius (either 0 or something else) so that he had to consider which number(s) make sense here? This would explicitly disallow an empty dictionary.

  • Would it make sense to provideexclusion radii for pairs of particle types? Something like Exclusion_radius[1,1]=0.9, exclusion_radius[1,2]=2 etc, due to the various different combination rules of the LJ potential? https://en.m.wikipedia.org/wiki/Combining_rules

@pm-blanco
Copy link
Contributor Author

pm-blanco commented Mar 11, 2022

  • Would it make sense to require the user to supply a dictionary contains at least one numeric exclusion radius (either 0 or something else) so that he had to consider which number(s) make sense here? This would explicitly disallow an empty dictionary.

I can add a check during the initialization of the reaction methods to prevent the user to provide an empty dict. It feels a little bit redundant to me since the code already checks that the user has defined an exclusion_radius for all existing particle types during the particle insertion, effectively dealing with this issue. It could however be a nice way to make the user aware in a early stage that he/she should define one exclusion radius per particle type.

  • Would it make sense to provideexclusion radii for pairs of particle types? Something like Exclusion_radius[1,1]=0.9, exclusion_radius[1,2]=2 etc, due to the various different combination rules of the LJ potential? https://en.m.wikipedia.org/wiki/Combining_rules

In my opinion, using that pair definition of the exclusion radius can complicate its setting up unnecessarily. Since there are only a few established combination rules, I believe that it would be rather more convenient to define an optional keyword e.g. combination_rule="Lorentz-Berthelot" and deal with it internally. By default could be the Lorentz-Berthelot combing rule since (up to my knowledge) is the more commonly used one.

@jngrad jngrad added this to the Espresso 4.2 milestone Mar 14, 2022
@pm-blanco pm-blanco force-pushed the exclusion_radius_dict branch from 743b1f6 to 547098e Compare March 16, 2022 18:49
@pm-blanco pm-blanco changed the title reaction_methods: exclusion_radius now is a dict that takes one value per particle type reaction_methods: new optional keyword exclusion_radius_per_type Mar 16, 2022
Copy link
Member

@jngrad jngrad left a comment

Choose a reason for hiding this comment

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

Thanks for this work! Please find a few suggestions below.

src/core/reaction_methods/ReactionAlgorithm.cpp Outdated Show resolved Hide resolved
src/core/reaction_methods/ReactionAlgorithm.hpp Outdated Show resolved Hide resolved
doc/sphinx/advanced_methods.rst Outdated Show resolved Hide resolved
doc/sphinx/advanced_methods.rst Outdated Show resolved Hide resolved
src/core/reaction_methods/tests/ReactionEnsemble_test.cpp Outdated Show resolved Hide resolved
src/script_interface/reaction_methods/ReactionEnsemble.hpp Outdated Show resolved Hide resolved
testsuite/python/reaction_methods.py Outdated Show resolved Hide resolved
@pm-blanco pm-blanco force-pushed the exclusion_radius_dict branch from 547098e to 4d2d8b1 Compare March 17, 2022 13:59
@kodiakhq kodiakhq bot merged commit 92e1df6 into espressomd:python Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reaction methods should take an exclusion radius per particle type
3 participants