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

Prototype reaction method in Python #4617

Open
RudolfWeeber opened this issue Nov 27, 2022 · 0 comments · May be fixed by #4765
Open

Prototype reaction method in Python #4617

RudolfWeeber opened this issue Nov 27, 2022 · 0 comments · May be fixed by #4765
Assignees

Comments

@RudolfWeeber
Copy link
Contributor

  • MC methods in Python would be much easier to develop\
  • MC methods probably do not benefit form parallelization, as the sytem is only locally modified most of the time
  • However, as we are remoming mpi callbacks, it would have to be parallelized if remainign in the core.
  • this is non-trivial.
  • Time consuming tasks like energy calculaiton will still be done by the core
  • The current C++ implementaion is not parallelized and essentially calls the same core funcitons, the Python script would use.

To assess the performance cost, a reaction ensemble simulation of a polymer with dissociating ions (HA -> H+ +A- and back reaction) should be written in Python.

Notes

  • energy calculation should be done via the core (system.analysis.energy(), in a later stage, this can be made mor specific, e.g., to omit kinetic energy.

  • the methods needs a list of ids for each particle type. For the prototype, this shuold be constructed once and updated on the fly. Later an effiient implementaiton in the core can be added.

    all_types = np.unique(system.part.all().type())
    ids_by_type = {t: system.part.select(type=t).id.shape) for t in all_types} # maybe shape[0]
  • Exclusion radius checking can be done with system.analysis.nbhood() We need to make usre, the O(1) implementaiton is used.

  • If this is significantly slower than the current core implementaiton, bottlenecks can be identified with a line-by-line profiling: https://stackoverflow.com/questions/3927628/how-can-i-profile-python-code-line-by-line

kodiakhq bot added a commit that referenced this issue Feb 3, 2023
Fixes #4616 

Description of changes:
- replace most of the particle property setters MPI callbacks by fully MPI-parallel code
   - a few MPI callbacks remain for properties that are relevant to reaction methods (position, velocity, type, charge), but these will be removed in the near future by #4617
   - some code duplication was introduced in `particle_node.cpp` and will be removed in the future, when the particle management will become more parallel (i.e. no more particle cache, id tracking and type tracking)
- remove 300 lines of C++ code
- deprecate `system.auto_exclusions(n)` in favor of `system.part.auto_exclusions(distance=n)`
kodiakhq bot added a commit that referenced this issue Feb 24, 2023
Partial fix for #4614
Partial fix for #4617
Follow-up to #4637

Description of changes:
- reaction methods are now fully parallel and no longer rely on MpiCallbacks
- reaction methods are no longer entangled with the particle management code
- the Monte Carlo acceptance probability is now implemented in Python
- API changes:
   - it is no longer possible to change the reaction constant of an existing reaction with `gamma <= 0`
   - `ReactionAlgorithm.reaction()` now takes `steps` instead of `reaction_steps` as argument
   - when setting up a MC method with two or more reactions, a runtime error is raised if a reaction accidentally overwrites the default charge of a specific type with a different value
- under-the-hood changes:
   - the `particle_data.cpp` source file was removed
   - the `EspressoSystemStandAlone` class no longer relies on MpiCallbacks
   - frequency of cell system invalidation during Monte Carlo trial moves has been significantly reduced
   - the new Python interface of reaction methods is around 40% slower than the original C++ implementation
@jngrad jngrad linked a pull request Oct 24, 2023 that will close this issue
@RudolfWeeber RudolfWeeber added this to the ESPResSo 4.3.0 milestone Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants