Skip to content

CU-86ad1nbm0 Fix instability in multi-worker Wepy setups by replacing omm.State with custom State class - #2

Open
edeustua wants to merge 5 commits into
masterfrom
emiliano/multi-gpu
Open

CU-86ad1nbm0 Fix instability in multi-worker Wepy setups by replacing omm.State with custom State class#2
edeustua wants to merge 5 commits into
masterfrom
emiliano/multi-gpu

Conversation

@edeustua

Copy link
Copy Markdown
Member

Previously, both TaskMapper and WorkerMapper relied on omm.State objects from OpenMM to manage simulation state. This caused issues when spawning multiple processes, each initializing its own omm.Context, leading to conflicts and unstable behavior in multi-worker Wepy runs.

To address this, a custom State class has been implemented. This new class reproduces the functionality of omm.State—tracking positions, velocities, energies, and other simulation data—without depending on the underlying C++ object that is tightly coupled to a single OpenMM context.

@edeustua edeustua changed the title Fix instability in multi-worker Wepy setups by replacing omm.State with custom State class CU-86ad1nbm0 Fix instability in multi-worker Wepy setups by replacing omm.State with custom State class Nov 5, 2025
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 this pull request may close these issues.

1 participant