Autodock v4.0.3.2 new version.

I thought I would watch a couple of cycles before I switched it out to an old workunit.

Green line behavior is a little strange. This is workunit 4306146.
The green line dropped a bit to -4.5. It then took about 16 giant steps to the right...off of the black graph and to the edge of the red audodock background box. Nothing changed after that. You usually see the green line advancing slowly, but not this time. It stayed a solid green line ending at the edge.

When the checkpoint completed, the green line went away and the dotted red line graph appeared at the correct location.

A new set at -4.0 did the same thing...the green line took 16 giant steps to the right to the edge of the red box.

That's when I swapped it out and resumed an old v4.0.3.1 workunit.

That was the workunit number on UDMonitor at the time, which is probably a number subset of the file name without UD-.

I've got 30 active devices on that machine, enough work for 5 days. At least I know what machine it was on and the UDMonitor number. I think I can find it again and let it run. I also have control of the time I would send it in, since I usually send 3-4 completed results at once.

I'll try again this evening, and note the device, device number and time this time. Actually, that same workunit is still sitting there waiting, and has only passed the first checkpoint. I swapped it out. The computer is working on other older workunits.

I would have to let it finish and send it in for you to notice the same result you were asking for. Right?

Oops. yes, 4306146 was one of the old version workunits. I and the workunit were both tired.

I have a little better info today, but none of these has yet finished. I downloaded 4439771 on 1/25 at 2356UTC to device PAINTED VULTURE, 186603.

This behavior is reproducible. It showed up on three different workunits, and possibly all.

Look at a new version 4.0.3.2 workunit that is ready to begin. When it starts, go immediately to the docking display and wait. The docking graphic starts at 0 0. When the first docking is ready to go, the graph rescales. These went to something like 0 -7. The green line goes quickly all the way to the edge.

Now for the twist. Either go back to the primary screen or use the down arrow to collapse the program. When you go back in to the docking screen, the graph shows the correct proportion with the creeping green line. The odd display seems to be only when the program first starts. I doubt whether it is affecting the result.

--------------------

Further pattern investigation

4334165 d/l 1/24 1248UTC to device 183579, odd
4330889 d/l 1/23 1410UTC to device 183733, normal
4337311 d/l 1/26 0009UTC to device 183733, odd
4329980 d/l 1/24 0058UTC to device 184077, normal
4326025 d/l 1/23 1253UTC to device 184081, odd
4426619 d/l 1/24 2359UTC to device 184183, normal
4427743 d/l 1/24 2354UTC to device 184188, odd
4425413 d/l 1/25 1257UTC to device 184686, odd

Every workunit with the odd behavior started with the 0 0 best docking graphic, rescaled, and ran the green line to the edge. It reverted to normal when going away and coming back.

The workunits marked normal started immediately with a numbered axis graph with a number less than zero so they did not have to wait for docking completion showing graph 0 0. They must have finished a calculation quickly and were ready to go immediately. This is a fast computer. I do not know whether a slow computer would have docking awaiting completion and graph 0 0 on the "normal" devices or not.
Graph 0 0 are not hard to find. Just grab a different workunit.

I have more devices available, but that may be enough for a start to show what is going on.

I seem to recall that the upper Y axis moved to -2 on one workunit when the green line was starting. Rescaling was taking place. It's just that first the graphics started with the empty 0 0 display before the green line anomaly shows up.

I'll work on a screenshot later, since I should be able to recreate the problem.

Thanks for the screenshot. It helped tremendously. I've identified a bug in the graphics DLL and we'll be releasing an updated DLL soon.

Note that this is strictly a graphics bug and is not a problem at all with the computation and results. The results are fine.

Thanks again for bringing this to our attention.