Dear participants!

The following changes will be transparent, but if you are interested in technical details, then here they are. A new application cmdock-boinc-zcp has been released, including the new CmDock v0.1.3 release with (z)ipped input, (c)heckpoints and enhanced (p)rogress bar. In addition, a new docking experiment will begin under a new protocol.

Thanks to the CmDock team and pschoefer & walli for the release!

Top, nice work!

I'm running the first task with the new application version now. Early observations:

- The segfaults I observed with the previous version seem to be gone. (Edit: Sorry, I looked in the wrong place. They are still there.)
- The progress display looks much more realistic now. However there is a difference between the progress displayed in BOINC Manager and that in the log file. The Manager is several % ahead. Both are going slightly faster than expected.
- There is a little bug in progress file generation. Apparently only the beginning of docking_out.progress is overwritten with a new number and a line feed, occasionally leaving a remnant of the previous number:

root@zaphod:/var/lib/boinc-client/slots/7# xxd docking_out.progress 
00000000: 302e 3235 0a36 3134 0a0a                 0.25.614..
root@zaphod:/var/lib/boinc-client/slots/7# xxd docking_out.progress 
00000000: 302e 3238 3138 0a31 0a0a                 0.2818.1..

The Manager then displays 100% progress until the next step.

- There is a little bug in progress file generation. Apparently only the beginning of docking_out.progress is overwritten with a new number and a line feed, occasionally leaving a remnant of the previous number:

root@zaphod:/var/lib/boinc-client/slots/7# xxd docking_out.progress 
00000000: 302e 3235 0a36 3134 0a0a                 0.25.614..
root@zaphod:/var/lib/boinc-client/slots/7# xxd docking_out.progress 
00000000: 302e 3238 3138 0a31 0a0a                 0.2818.1..

The Manager then displays 100% progress until the next step.

I'm seeing similar for the Windows version.
Sometimes progress jumps to 100%. When that happens, there is a second line in docking_out.progress with an integer on that 2nd line.
I've seen
first line 0.168 second line 3
first line 0.052 second line 9
first line 0.118 second line 2
first line 0.16 second line 89
first line 0.056 second line 99

Edit: Not always an integer on the 2nd line.
Now I've seen:
1st line: 0.19
2nd line: [empty]
3rd line: 5
4th line: [empty]
5th line: [empty]
6th line: [empty]

Hello,

since the update to CurieMarieDock on BOINC + zipped input, checkpoints and progress bar I don´t get any workunits on my 3 linux on arm systems.

Are there no WUs ready to send for this system?

thank you

Umlauf

Check your project preferences . . .

I think, my project preferences are correct.

USE CPU

RxDock on BOINC
CurieMarieDock on BOINC
CurieMarieDock on BOINC + zipped input
CurieMarieDock on BOINC + zipped input, checkpoints and progress bar

and the use of other projects are activated.

i have changed the preferences, now i get new WUs.

Thanks!

Umlauf

The jump to 100% is on slower ARM systems a problem.
I run with work puffer 0/0 but if it goes to 100% boinc get a new WU that is waiting over 2 days to start and will not finish within deadline and i have to cancel it before it starts.

Still seeing PROBLEMS with CHEKPOINTS on the new CurieMarieDock on BOINC + zipped input, checkpoints and progress bar v1.00
windows_x86_64 tasks.

So far this task has run OVER 5 5 hours and it only has check pointed TWICE? ABOUT 3.5 hours ago?

Project SiDock@home
Name exp_eve_corona_Eprot_v1_run_2_nb3di_374413_4_eve_0
Application CurieMarieDock on BOINC + zipped input, checkpoints and progress bar 1.00
Workunit name exp_eve_corona_Eprot_v1_run_2_nb3di_374413_4_eve
State Running
Received 5/30/2021 11:22:47
Report deadline 6/5/2021 11:22:45
Estimated app speed 1.79 GFLOPs/sec
Estimated task size 50,000 GFLOPs
CPU time at last checkpoint 01:59:10
CPU time 05:33:21
Elapsed time 05:38:50
Estimated time remaining 03:22:50
Fraction done 56.375%
Virtual memory size 148.04 MB
Working set size 119.75 MB
Directory slots/0
Process ID 824

Here is contents of the "wrapper_checkpoint.txt" file from the slots folder:
0 7150.103034 6998.000000

---

Still seeing PROBLEMS with CHEKPOINTS on the new CurieMarieDock on BOINC + zipped input, checkpoints and progress bar v1.00
windows_x86_64 tasks.

No problems here with Windows 64.
The only problem is that progress jumping several times during a task to 100% and backwards and the 'write to disk every ... seconds' is ignored.
Checkpointing is after every job out of the 500 during a task.

Are you using BoincTasks for your info. Maybe the task has restarted somewhere in between.
When you look with BOINC Manager, you'll see last checkpoint mostly a few minutes ago.

Strange error on suspended task with a progress of ~13%: exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4 ===> https://www.sidock.si/sidock/result.php?resultid=13391095

SiDock@home 31 May 09:04:50 task exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0 suspended by user
SiDock@home 31 May 09:06:38 [error] Can't rename output file slots/3/docking_out.log to projects/www.sidock.si_sidock/exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0_r1610030515_1: Error 32
SiDock@home 31 May 09:06:43 Computation for task exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0 finished
SiDock@home 31 May 09:06:43 Output file exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0_r1610030515_1 for task exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0 absent
SiDock@home 31 May 09:06:46 Started upload of exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0_r1610030515_0
SiDock@home 31 May 09:06:47 Finished upload of exp_eve_corona_Eprot_v1_run_2_nb3di_388288_4_eve_0_r1610030515_0

We are unable to reproduce the error at our side, but will be aware. Could it be a lack of disc space?

We are unable to reproduce the error at our side, but will be aware. Could it be a lack of disc space?

max allowed disk usage: 107.32 GB.
This happened the first time, so no great worry, but strange was, that for BOINC the task was finished and reported, but cmdock.exe was still running locking some files in a slot-folder.

I had errors on that machine a few days ago, because Windows Antimalware Service Executable (MsMpEng.exe) ate all memory when using 1.5 core.
It seems to happen only when cmdock.exe's are running. It makes no differnce when I exclude BOINC's folders or exclude MsMpEng.exe itself.

I don't know if this project is known, but at WUProp (https://wuprop.boinc-af.org/index.php) you can look up which key data certain projects and their applications use for the calculation.
You can choose between the different Boinc projects and their subprojects (e.g. WorldCommunityGrid has FightAids, MappingCancer etc).
For Sidock there are now 3 entries (CurieMarieDock on BOINC, CurieMarieDock on BOINC + zipped input, CurieMarieDock on BOINC + zipped input, checkpoints and progress bar), although (IMO) the project consists of only one application.
I am not familiar with the administration of Boinc projects, but maybe this can be adjusted

In reply to Crystal Pellet's questions:

Are you using BoincTasks for your info.

No. info directly from BOINC.
Same exact info in BOINC Tasks as in BOINC.

Maybe the task has restarted somewhere in between.

Tasks never restarting or paused.

When you look with BOINC Manager, you'll see last checkpoint mostly a few minutes ago.

As said before, Not seeing checkpoints except as previously noted in BOINC.

When I get to my computers and have a task running I'll even post a directoy dump/listing with time stamps showing date/times of slot directory contents along with info from BOINC.

---

I agree that small changes to the code of an application (progress bar, checkpoint) although implementation was not trivial shouldn't call for new applications. I'd much rather see you introduce new versions of the same app as long as you don't change much of the internal code logic. Additionally, very long application names are very confusing and hard to retrace.

Why not simply have CurieMarieDock 1.01 / CurieMarieDock 1.02 etc and CurieMarieDock 2.0 for major updates.

CurieMarieDock on BOINC --> CurieMarieDock on BOINC + zipped input --> CurieMarieDock on BOINC + zipped input, checkpoints and progress bar vs.
CurieMarieDock 1.0 --> CurieMarieDock 1.1 --> CurieMarieDock 2.0

You can always convey the changes within each application version within the application release notes in the news section.

Especially confusing otherwise as you as a project won't roll out WUs from older applications as you mean to fully transition to the latest app. Old/Retired apps will only clutter the applications page.
Furthermore, runtime tracking via WUProp will be distrorted highly if you keep introducing new apps for each "minor" update instead of just iterating the internal development version number of the apps.

And regarding the rollout of new apps. Why not set up a "Beta" app which can then be used as a main test channel before introducing a new app. (Beta CurieMarieDock). Might have caught various glitches beforehand, such as the non-working progress bar in the new app "CurieMarieDock on BOINC + zipped input, checkpoints and progress bar".

Just a few ideas.

OK here is MORE PROOF that checkpoints are NOT working.

FROM BOINC:
Application CurieMarieDock on BOINC + zipped input, checkpoints and progress bar 1.00
Name corona_Eprot_v1_run_2_nb3di_015242_1
State Running
Received 6/5/2021 17:53:30
Report deadline 6/11/2021 17:53:38
Estimated computation size 50,000 GFLOPs
CPU time 12:51:04
CPU time since checkpoint 12:51:04
Elapsed time 13:54:15
Estimated time remaining 08:05:00
Fraction done 44.488%
Virtual memory size 148.32 MB
Working set size 117.65 MB
Directory slots/1
Process ID 4888
Progress rate 3.240% per hour
Executable cmdock-boinc-zcp_wrapper_1.0_windows_x86_64.exe


--------
FROM SLOTS DIRECTORY:
Directory of C:\boincdata\slots\1
06/05/2021 17:55 <DIR> .
06/05/2021 17:55 <DIR> ..
06/05/2021 17:55 0 boinc_lockfile
05/27/2021 06:31 <DIR> build
06/05/2021 17:54 108 cmdock-boinc-zcp_wrapper_1.0_windows_x86_64.exe
05/26/2021 05:30 <DIR> data
06/06/2021 07:47 27,361 docking_log
06/05/2021 17:55 22 docking_out.chk
06/06/2021 07:47 57,754 docking_out.log
06/05/2021 18:03 12 docking_out.progress
06/05/2021 17:55 8 docking_out.sd
05/31/2021 03:11 162 htvs.ptc
06/05/2021 17:54 7,925 init_data.xml
05/31/2021 03:11 651 job.xml
05/27/2021 06:31 <DIR> lib
04/28/2021 19:40 1,611,124 ligands.sdf
06/05/2021 17:55 215 stderr.txt
03/20/2021 16:02 3,260,572 target.as
03/20/2021 16:02 307,542 target.mol2
03/20/2021 16:02 740 target.prm
15 File(s) 5,274,196 bytes

---

06/06/2021 07:47 27,361 docking_log
06/05/2021 17:55 22 docking_out.chk
06/06/2021 07:47 57,754 docking_out.log
06/05/2021 18:03 12 docking_out.progress
06/05/2021 17:55 8 docking_out.sd

docking_out.chk and docking_out.progress are kept open during the run, maybe that prevents the timestamps from being updated. You should check the contents of those files to see if they're really not written to.

I had to shut down one of my computers and the task progress on a few tasks were around 50%.
After restart, these started from 0%.
Checkpoints are not working properly.

I tried again.
Initially, task started from 0%, again.
But after a few minutes, the percentages were, as thay had been before the shutdown.

It is working, but only after a few minutes????????