-
Notifications
You must be signed in to change notification settings - Fork 189
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
Rewrite long-range actors #4506
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
786d0c2
to
9ea50b2
Compare
if isinstance(actor, script_interface.ScriptInterfaceHelper): | ||
actor._activate() | ||
|
||
self.active_actors.append(actor) | ||
|
||
if not isinstance(actor, script_interface.ScriptInterfaceHelper): | ||
actor._activate() |
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.
where does it come from, that for ScriptInterfaceHelper
-objects we need to call _activate()
before appending it to the list?
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.
Here is the intended workflow:
_activate()
calls the C++ actor registration code that adds the actor in the global optional variant- the now active actor in the core runs the sanity checks and tuning algorithm (if the method supports tuning)
- if checks or tuning fail, a C++ exception is thrown, which is handled in the registration code
- the actor is safely removed from the core global
- the exception is re-thrown
- on MPI rank 0, the C++ exception becomes a Python exception
- line 54 in actors.py throws
- the python object is never added to the list of active actors
Since removing an actor from the actor list will trigger sanity checks in the core, we cannot remove a python actor if it is not also in the core. We also cannot keep an invalid actor in the core. LB and EK actors still rely on the old workflow.
tune(charges, positions); | ||
auto const size = static_cast<int>(n_part); | ||
handle_error(fcs_run(m_handle, size, positions.data(), charges.data(), | ||
fields.data(), potentials.data())); |
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.
Does anyone remember why in the original implementation, we need to re-tune ScaFaCoS before each integration step? Maybe it has to do with side effects when the node_grid
or number of particles changes, or when we reload from a checkpoint (tuned parameters cannot be checkpointed). Commenting out line 84 doesn't affect the testsuite, but the edge case it's supposedly guarding against is not documented in the original implementation.
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.
LGTM
Create more fine-grained events for long-range actors to react to changes in the cell structure and box geometry. Convert Cython code to Python code with the ScriptInterface framework and remove global variables of CPU methods. Fix regressions in the energy and pressure analysis module. Split electrostatic and magnetostatic methods.
Description of changes: - Update documentation to reflect that P3MGPU is in fact able to execute the CPU energy and pressure kernels using parameters tuned for the GPU force kernel since #4506.
Fixes #4454
Description of changes:
coulomb.cpp
)coulomb.hpp
in 30 unrelated files in the corenode_grid
incompatible with a long-range actor is no longer possible (the oldnode_grid
is restored)DipolarP3M
energy correction is now invalidated when the box length changesScriptInterface
frameworkELC
andDLC
are no longer extensions, instead they take another actor as argumentP3MGPU
is now able to execute the CPU energy and pressure kernels using parameters tuned for the GPU force kernelP3MGPU
is now supported byELC
actor.charge_neutrality_tolerance
; this is mostly relevant to actors coupled toICC
, whose induced charges can have value spanning several orders of magnitudeMpiCallbacks
frameworkcoulomb.hpp