Or just set max_concurrent to 1 and avoid the issue entirely until the applications and software for the problem gets resolved.

Until the BM queue fills up with just QC tasks and all other cores go idle. Better to just avoid the entire application in the 1st place. If it's not worth the admins time to fix known issues that cause errors 100% of the time in known situations then its not worth the time for donors to run.

Every donor is different. I don't have GPUGrid as my sole project so the crunchers never go idle, there is always work being done for someone.

As with most projects, there is always a shortage of manpower, money or time for keeping applications current and working.

I'll be watching for updates, but for now I'm also turning off CPU tasks.

Scheduler is telling batches to activate all at once. Rows of errors. I acknowledge that user fixes have been recommended but I don't want to program a solution that's beyond my capacity to correct once circumstances change.

Hope to be back soon!

I set up the quantum chem app on a second computer. I started with the following app_config.xml file:

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

Once the Work Units downloaded and 1 WU started w/4 threads, I edited the app_config.xml to change <max_concurrent>1</max_concurrent> to <max_concurrent>2</max_concurrent>. Then I restarted the boinc client and now I have 2 work units running simultaneously with 4 threads each. So far so good.

But there is still the issue that whenever your QC tasks finish and more than 2 tasks are downloaded, that your system can try to start both tasks at the same time and then both will fail. There is no guaranteed method to stagger starting of multiple QC tasks in an unattended system on auto.

The only way to get around this situation is to do exactly what you posted. But requires your intervention at each new task startup.

Or just set max_concurrent to 1 and be done with it.

I am not seeing this situation at all.
My AMD Linux Fedora systems download more than one at a time but only ever try to run one at a time.
Even on my 8 core (+ 8 HT) only one starts and other projects keep running.

I am also running other applications but on a 4 core computer when GPU Grid starts it is the only thing that runs and only one at a time.

Not trying to control how things are run.

So I don't know what could be causing problems on your computers.

BOINC versions are 7.4.25 and 7.6.22

Conan

Quick update: I checked my logs and this thread again to see if I could resume tasks. To my surprise, tasks were resumed while I had still opted out.

ACEMD short runs (2-3 hours on fastest card): yes
ACEMD long runs (8-12 hours on fastest GPU): yes
ACEMD Beta: yes
Quantum Chemistry (Linux, CPU): no
Python Runtime : yes

I don't know what's broken but it's not cool.

I am not seeing this situation at all.
My AMD Linux Fedora systems download more than one at a time but only ever try to run one at a time.
Even on my 8 core (+ 8 HT) only one starts and other projects keep running.

I am also running other applications but on a 4 core computer when GPU Grid starts it is the only thing that runs and only one at a time.

Not trying to control how things are run.

So I don't know what could be causing problems on your computers.

BOINC versions are 7.4.25 and 7.6.22

Conan

Several posters have reported the problem of starting two QC tasks at the same time or within 5 seconds of each other causes the first task to error out.

See Message 48589

Dayle Diamond said:

Quick update: I checked my logs and this thread again to see if I could resume tasks. To my surprise, tasks were resumed while I had still opted out.

Dayle, do you perchance have the preference box checked for

If no work for selected applications is available, accept work from other applications?

If one has more than 4 cores and running max concurrent = 1, there is still the chance that boinc manager will flood your queue with all QC tasks and nothing from the other project. Esp when just starting up that setup before BM gets a better handle of the resource share it is a long term resource share.

I've personally had this happen using max concurrent on another project. 4 threads working, 28 idle. It's far from a perfect solution.

Dayle, do you perchance have the preference box checked for
If no work for selected applications is available, accept work from other applications?

Oops. Thank you ><.

Happy Crunching, I'll be back with these tasks once things have stabilized.

I set up the quantum chem app on a second computer. I started with the following app_config.xml file:

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

Once the Work Units downloaded and 1 WU started w/4 threads, I edited the app_config.xml to change <max_concurrent>1</max_concurrent> to <max_concurrent>2</max_concurrent>. Then I restarted the boinc client and now I have 2 work units running simultaneously with 4 threads each. So far so good.

This approach, although a bit cumbersome, works. I've completed 189 Work Units with no errors.

I think special badges for Quantum Chemistry contribution would be a draw for more users.

So, forgive me if this has been answered.

Is this planned to be fixed at some point?

No it hasn't been answered. Or even addressed by the developer as far as I can tell. Seems the resources lately have been in deploying and debugging the WSL QC app.