simtk.org

Dear all,

I am trying to run several systems in OpenMM 7.0 using the OpenCL platform on a GTX 1080 in ubuntu 16.0.4. The CUDA platform works perfectly well. This workstation has nvidia drivers version 396.54.

After successfully constructing a system and a simulation, the same error is always given by OpenCL when doing anything to the simulation, such as obtaining the system energy, setting the velocities, or minimization.

The error is lead with:

OpenCL internal error: CL_OUT_OF_RESOURCES error executing CL_COMMAND_READ_BUFFER on GeForce GTX 1080 (Device 0).

and ends with:

Exception: Error downloading array interactionCount: clEnqueueReadBuffer (-5)

The systems have two somewhat unique featues:
They use the OpenMM Monte Carlo Barostat
They use a custom force to implement a Force-Switch on nonbonded interactions.

Any ideas about the cause?

Thank you!
George

The first thing I'd suggest is upgrading to OpenMM 7.3. 7.0 is a fairly old version, and this might reflect a problem that has since been fixed.

CL_OUT_OF_RESOURCES indicates the GPU ran out of some resource, most often memory though it can also be other things. Does your system have an unusually large number of atoms? Or are there other things that could be taking a lot of memory, such as a very large PME grid or a large tabulated function?

They use a custom force to implement a Force-Switch on nonbonded interactions.

What kind of custom force is it?

Hi Peter,

For these systems 7.3 works just fine with OpenCL. 7.2.2 also works with OpenCL.

The number of atoms is not apparently a problem (the result is the same both the 418,669-atom system I am trying to run and a 16,724-atom test system), suggesting the memory error is "unnatural". The error occurs both with- and without the MCbarostat and Force-switch custom force. The custom force is a CustomBondForce.

There might be an issue related to CHARMM36? I do not what changes that might have been made in the update to 7.2 that might effect interpreting the CHARMM files, or what may effect the OpenCL platform between 7.0 and 7.3.

Ultimately, here I want to get a large membrane system to run on FAH with the openmm_21 core. I believe it was built on OpenMM 7.0, but internal testing is failing presumably due to this OpenCL issue (after downloading and deserializing XML files). Presumably, the openmm_22 core is available now and was built on OpenMM 7.2.2. I'm going to try to move forward using that instead -- perhaps this memory error is not a roadblock.

Thank you for your generous assistance as always,
George

Ok, good to know the issue has already been fixed. Core 22 is based on 7.2.2, so it should be ok.