OpenMM 6.3 slowing down parmed netcdf reporter

[George Pantelopulos]

Hi all,

I've been running simulations on a new setup with a Titan X with OpenMM 6.3 and it seems that all simulations I am running are experiencing a gradual dropoff in performance in a variety of different simulation setups.

nsday_step.pdf

ns/day over steps

(13.41 KiB) Downloaded 40 times

Has anyone encountered something such as this before? I've attached the script used to produce the particular run here in case it might have some helpful info.

[George Pantelopulos]

It appears that this is somehow related to parmed's netcdf reporter. Running with openmm's dcdreporter avoids this issue.

I'm using the netcdf reporter because I want to save the velocities. I've tried to obtain velocities by appending them as numpy arrays (after removing the units from velocities) to pytables, which appears to cause the same performance loss. Writing the velocities to numpy arrays with this same writing frequency appears to avoid this performance loss, though this is obviously a very ugly solution.

[Jason Swails]

This is a consequence of scipy's NetCDF class slowing down as the NetCDF file grows in size. The reader is the fastest Python option, but the writer is slower than the one from NetCDF 4 and slows down over time.

I could probably work around this issue by supporting NetCDF writing through the netCDF4 package. How severe is the slowdown? how long does it take to be significant? (Say about a 5% performance hit or more?)

[George Pantelopulos]

Hi Jason,

Thanks for the reply! There is a pdf I had attached in the original post that shows the slowdown, particularly a huge shift in performance around 0.9e7 steps, before which there is a small performance loss. The system has 15720 particles.