Ok, just a heads up...on initial inspection, these look good.

The science does a calculation against different size ligands. Depending on the size of the ligand determines the runtime per job. We are still working to estimate this properly but as for these workunits they were not estimated. Some of the smaller ligands in the quick runs checkpointed every 40 seconds. Which would come out to be about 6-7 minutes with these workunits. There are however ligands that ran for 10 minutes on the quicker workunits, which would cause them to check point every 1.5 hours. As you can see there is a large difference in speed based on the ligand.

In your stderr, you should see pdbqt = # # asdfasdfadf

These two numbers represent the size of the ligand. the first number varies so far between 10 and 38. The second number between 0 and 15. the smaller the combination between the two the shorter the job.

Thanks,
-Uplinger

Copycat-Digital,

I am not sure about what you are encountering. It could be memory related but I am not sure.

Thanks,
-Uplinger

OK, on Linux, [not looking uninterrupted] somewhere at the 4th or 5th checkpoint the progress reset from about 50% to 7.5%, suggesting a new docking was started, and checkpoints count went back to 0. The CPU time is very close to the Elapsed time and still the holding at each checkpoint. 7.5% does not fit well with a multiplier into 100%. How many dockings in a job... 13-14?

I've switched LAIM off and will suspend them after a checkpoint, so they unload and then resume them to see how they restart. Only allowed 2 of 4 to start ahead of the queue, so it's not to big a juggle to time it right.

--//--

I have 4 running, spread over 3 different Linux boxes. I'll try to keep an eye on incrementing percentages complete.

@ uplinger, where do I find stderr details?