Bad Seeds?

[Julie Mitchell]

Sometimes I get this error when running using the reference platform, and sometimes everything works fine. I've traced it to the Shake algorithm within the reference platform files, but I have no idea what is going on. Sometimes everything works fine, and sometimes I get an error for every bond in the system. I am guessing the randomization is giving a seed that produces the error, then eventually one gets a seed that doesn't cause it.

Anyway, probably something to fix eventually ...

Thanks,
Julie

...
126 1208 1207 Error: sign of rrpr < 0?
126 1208 1220 Error: sign of rrpr < 0?
126 1209 1208 Error: sign of rrpr < 0?
126 1220 1232 Error: sign of rrpr < 0?
126 1220 1221 Error: sign of rrpr < 0?
127 1208 1207 Error: sign of rrpr < 0?
127 1208 1220 Error: sign of rrpr < 0?
127 1209 1208 Error: sign of rrpr < 0?
127 1220 1232 Error: sign of rrpr < 0?
127 1220 1221 Error: sign of rrpr < 0?
...

[Peter Eastman]

That means the shake algorithm failed to converge. There are several common reasons that might happen:

1. You're taking too large time steps.

2. The initial conformation isn't energy minimized, so there are very large forces.

3. The initial conformation doesn't satisfy the constraints.

4. You have inconsistent or overdetermined constraints.

If it sometimes works fine, #4 probably isn't the problem. When it does happen, does the error occur immediately, or not for a while? If the former, then #2 or #3 is probably the problem. Otherwise, #1 is most likely.

Peter

[Julie Mitchell]

The error occurs immediately, but only some of the time. There are no constraints, so it cannot be #3. Perhaps #2 is the issue, except that I'm trying to run the minimization rather than dynamics. Clearly, expecting minimized input into a minimizer is problematic

It also only happens on the reference platform. Every time I've run this under CUDA or OpenCL, it converges just fine, always to the same answer. The reference platform also gives an identical answer when it converges, but half the time this error pops up.

[Peter Eastman]

> There are no constraints, so it cannot be #3.

I'm pretty sure there are constraints. That message is produced by the constraint handling code, and only gets called if your system has constraints!

Peter

[Julie Mitchell]

I checked, and I define bond forces but not constraints. There are also nonbonded, angle and torsion forces defined.

I can run the same set of examples, and half the time it gives the error, and the other half the time it runs. It also only seems to be occurring on one machine and only some of the time, which is a bit confounding.

I am happy to show you the code next week if you like, since I will be at your workshop.

[Julie Mitchell]

Hmm ... so, now I ran the problem with constraints and can produce the error consistently. I will check on the other machine tomorrow to see if I somehow gave it the flag for constraints, and maybe I can sort it out next week at Stanford.

[Julie Mitchell]

Hi Peter,

I finally sorted this out. I wasn't calling my code with the flag for constraints, but there was a preference variable controlling the introduction of constraints that wasn't being initialized, hence the wonky behavior. Oddly, it never showed up until I was running using the reference version on a machine without GPUs, so I think the variable was getting initialized to zero on the other machines, but not that one.

Anyway, thanks for your help in sorting this out. The good news is that the problem is simple and not reflective of any problem in OpenMM (which is, incidentally, awesome

-Julie

[Peter Eastman]

Glad you figured it out! Uninitialized variables are definitely a pain to debug. They often are machine specific, since different platforms tend to initialize memory in different ways. Valgrind is your friend.

See you next week.

Peter