Great. I'll make sure that gets fixed in the next release.

Peter

It looks like a new version of the APP SDK is incompatible with the OpenCL C++ bindings we're using. :( Try editing cl.hpp (found in platforms/opencl/src), and comment out lines 2039 through 2055. That's the section defining the setPrintfCallback() function. Does that make the error go away? Peter

I did some profiling to see why it's taking so long. It turns out parsing the expression isn't the problem - that takes a fraction of a second. The expensive part is differentiating it with respect to all the different variables, and optimizing all those derivative expressions.

Peter

Hi Aron, The code I quoted was taken from customCompoundBond.cl. The easiest way to do an if/else in an expression is by using a step() function. Compute the angle using both methods and store them in angle1 and angle2. Then you can specify something like "angle = select*angle1 + (1-select)*angle2; ...

Hi Aron, Computing angles in cases like this is a bit tricky. For example, here's the code that CustomCompoundBondForce uses to evaluate a dihedral term: /** * Compute the angle between two vectors. The w component of each vector should contain the squared magnitude. */ real ccb_computeAngle(real4 v...

Hi Matteo, Two hours for one ns means 12 ns/day, which seems a little slow. For comparison, we get 60 ns/day simulating DHFR (almost exactly half the size of your system) on a GTX 680 (slightly faster than your 580, but not enormously). I assume you're using OpenMM 5.1? It's a lot faster than earlie...

Hi Spela, I don't think numerical roundoff is the issue. The spacing used in the original version is actually an accurate value for liquid water, and would be entirely reasonable if it were starting from an equilibrated configuration. The problem is that it just arranges the water molecules in a uni...

Hi Spela, It looks like HelloWaterBox needs to be cleaned up. The real problem is that it's creating water molecules that are very tightly packed together in a very high energy configuration, and the simulation is blowing up. Line 244 reads const double WaterSizeInNm = 0.3107; // edge of cube contai...

Hi Siddharth, This problem was fixed a long time ago. Upgrade to a newer version of OpenMM and it should be fine. The fix was to specify only the particular device being used when creating a cl::Context. Here's the relevant code from the current version of OpenCLContext.cpp: vector<cl::Device> conte...

Thanks! I've just fixed it.

Peter