The longest currently running job of OPN on my device is 2 hours and has written 13 checkpoints or 1 every.9.2 minutes. My setting is....'at most., every 600 seconds, so ballpark that's close to what I want it to be. A second one has 90 minutes CPU time with 12 checkpoints done and at 7.5 minutes each that's not abiding by the preference. Concur, something is not right.

This is probably related to the reason for the recent outage.

An example of OPN disk activity over the last several days
Pi 3A+ running OPN - change in SSD read/writes readily apparent



(It survived some monster WUs without error using 2G of swap)

We've been complaining about this since OPN1 was in beta!

At best, it's a known issue.

On why there's lots of I/O, and whether a reduction is possible - a programmer's viewpoint...

If you look at the slots directory for a running OPN1 (or OPNG) task you'll find a lot of files with names of the form wcg_checkpoint_??.ckp. Unsurprisingly, those files are the key to the amount of disk I/O that happens.

The majority of those files start life as copies of the receptor.??.map files generated by AutoGrid. One of the files (usually wcg_checkpoint_13.dat) appears to be an accumulation of the individual AutoDock job dialog files. The correspondence between files can be found in wcg_checkpoint.dat.

The size of the results file(s) depends on the sizes of the ligands, the size of the flexres part of the receptor and the number of jobs in a work unit. The dominant part is, of course, the number of jobs! Hopefully, the accumulated dialogs file and the results file(s) are grown by write-append rather than copy-append!

As for the copied .map files: it appears that these files get copied each time a checkpoint is taken, so that can be quite a lot of I/O activity. The sizes of the larger .map files will be about 6 to 8 times the grid size, so for the current receptor that's 1.0 to 1.4MB per file. I am not sure, but I don't think AutoDock actually alters any of those files; if that is indeed the case and the code doing the copying could be persuaded to hook up the actual .map files instead (using links or whatever...) that would considerably reduce the amount of I/O per job (and hence, per task).

Of course, even if those files are only used as input, the changes would probably require coding that doesn't follow normal BOINC practice (which might explain why it hasn't happened already if it would mitigate the problem!) And the likelihood of a fix would also depend on whether the relevant code is in the wrapper or embedded in the actual science code.

Cheers - Al.

P.S. I'd love to have access to the wrapper code for OPN1/OPNG to see how it actually works -- I used to "tune" software as a part of my work, and this sort of puzzle was within my remit...