I'll add /bin to the path in the next app update. That may work, unless there is some weird sandboxing thing going on. You shouldn't need to tweak your system: just let them fail (they should fail fast, so no CPU loss).

Concerning why some hosts are not receiving WUs, it's baffling me. It's not a matter of hosts already having GPUs because my own machine does and it did not get tasks. It may be related to the "reliable hosts" classification.

@Daniel: can you list one of your hosts which gets QC tasks and one which doesn't?

Thanks

@Daniel: can you list one of your hosts which gets QC tasks and one which doesn't?

Thanks

Hosts which get tasks: 449991, 449992, 391907
Hosts which did not get any: 444456, 452231

---

Many thanks for this: I look forward to the Windows version!

Dears,

we would like to test our new CPU multicore application for quantum chemistry tasks ("QC"). Since it’s the first time we have a CPU app out, I’ll test the behavior of GPUGRID with a relatively large batch that you will see soon. Workunits are named "*QC309big*".

Here’s some features of the app, in short (subject to change):

* Platform: Linux only for now, generic x64.
* Threads: as many as Boinc decides. I guess it depends on your machine, your preferences, and other running tasks in ways which are obscure to me…
* Run time: about 1 CPU hour per WU (so, shorter if multithreading)
* Credit: computed with the default algorithm (tasks are short, don’t expect much). Bonus mechanism for fast turnaround is still on.
* Known bugs: restarts and checkpoints. This should be mitigated with the “keep in memory when suspended” option. Sorry about that, it’s outside of our control.
* Network behavior: the first time you get a WU of this kind it downloads a Python interpreter (miniconda) and then some open-source packages, and installs them in the project directory. The installation is reused whenever possible.
* Disk usage: could go around 1 GB, perhaps more when tasks are running. Resetting the project should remove everything.
* Memory usage: should be around 1 GB when running.

Depending on the results of this test, we’ll start thinking about other platforms.

Thanks and nice crunching!

Toni

---

John

Two of my computers have received tasks and processed them with no trouble.
Both run Fedora (16 and 21), host ids are 192138 and 189186.
My 8 core (16 thread) computer (running Fedora 25) has yet to receive a task.

Host 192138 is a 6 core computer and Host 189186 is a four core computer.

The 6 core has shorter Run times per task and more CPU times than the 4 core.

This is as expected due to core count, however the 4 core computer gets higher credit per task than the 6 core, this does not make sense.

6 core getting around 1,500 sec Run time, 8,600 CPU time and about 66 credits.

4 core getting around 3,200 sec Run time, 6,900 CPU time and about 85+ credits.

A bit odd perhaps?

Conan

Credit assignment logic has historically been problematic (see here) to the point that I am inclined to think that it has no best solution. For the time being the credit algorithm is the old default one from boinc. I think it relies heavily on the self-computed FLOPS and yes that seems paradoxical.

I haven't been able to successfully process a WU on my computer. I've received many, but they've all resulted in "Computation error".

See screenshot: https://imgur.com/z0vLkoh

I haven't been able to successfully process a WU on my computer. I've received many, but they've all resulted in "Computation error".

See screenshot: https://imgur.com/z0vLkoh

You'll have to try one of the suggestions posted by Daniel or [VENETO] sabayonino above. I'm waiting for more WUs to try myself.

we are not aware of fast and free gpu qm applications. if you know one, let us know.

Please do not tweak your system. The current application (QC 3.10) should solve the problem.

we are not aware of fast and free gpu qm applications. if you know one, let us know.

@UF & @UNC developed ANAKIN-ME to create fast, accurate quantum mechanical simulations. See the demo at #SC17 http://nvda.ws/2zyBhKj

https://twitter.com/NVIDIADC

Yes, we have that and it is nice, but limited and not a QM code.

I completed one this morning in Ubuntu.

The new app has 0% failure rate. However, only a handful of hosts are receiving it, for reasons utterly obscure.

This is the only indication i found in the logs:

2017-11-10 20:06:33.9454 [PID=182743] [quota] Overall limits on jobs in progress:
2017-11-10 20:06:33.9454 [PID=182743] [quota] CPU: base 2 scaled 112 njobs 0
2017-11-10 20:06:33.9454 [PID=182743] [quota] GPU: base 2 scaled 0 njobs 0

That "njobs 0" seems to prevent result sending. Any clue hugely appreciated...

The new app has 0% failure rate. However, only a handful of hosts are receiving it, for reasons utterly obscure.

This is the only indication i found in the logs:

2017-11-10 20:06:33.9454 [PID=182743] [quota] Overall limits on jobs in progress:
2017-11-10 20:06:33.9454 [PID=182743] [quota] CPU: base 2 scaled 112 njobs 0
2017-11-10 20:06:33.9454 [PID=182743] [quota] GPU: base 2 scaled 0 njobs 0

That "njobs 0" seems to prevent result sending. Any clue hugely appreciated...

The only reading material I can suggest is http://boinc.berkeley.edu/trac/wiki/ProjectOptions#Joblimits, but I imagine you know that already. Remember to read the following 'Job limits (advanced)' section too.

For those interested in controlling the number of threads used by the multicore app, the following app_config.xml entries seem to work.

  <app>
    <name>QC</name>
      <max_concurrent>1</max_concurrent>
  </app>
   <app_version>
      <app_name>QC</app_name>
      <plan_class>mt</plan_class>
      <avg_ncpus>9</avg_ncpus>
      <cmdline>--nthreads 9</cmdline>
   </app_version>

The <avg_ncpus> entry tells BOINC the number of threads to reserve for the app.

The <cmdline> entry tells the app the number of threads available for processing.

Can anybody comment on the suspend/resume behavior under a variety of conditions (ie. with and without "keep in memory")? I expect the calculation to restart from scratch, but not crash.

Like many others I don't get any WUs on my linux machines.

---

Can anybody comment on the suspend/resume behavior under a variety of conditions (ie. with and without "keep in memory")? I expect the calculation to restart from scratch, but not crash.

When I suspended a task with LAIM on, BOINC manager showed that it was suspended, but the system monitor showed that the task was still busy using all the threads that were allocated to it.

When I suspended a task with LAIM off, BOINC manager showed that the task was suspended and the task disappeared from the system monitor. When the task was resumed, it restarted from 0 and appears to be running normally.

@captainjack - thanks, appreciated.