Do you want to make them more appealing to crunch?? Take the QMML tasks OFF the Boinc CreditNew credit award mechanism and assign them fixed values like you do for the gpu tasks.

Sure, I can help.

This forum news post was syndicated to your Twitter account, however, the link is broken.

Relevant post: https://twitter.com/gpugrid/status/960604705171808256

The link resolves to https://www.gpugrid.net/extra_arg_utm_source.html

I have reposted your call to the BOINC subreddit

Do you want to make them more appealing to crunch?? Take the QMML tasks OFF the Boinc CreditNew credit award mechanism and assign them fixed values like you do for the gpu tasks.

Unfortunately, I gave up on Linux and run Win 10.

Hi, we need more CPUs on Linux to run QM simulations. Anybody can help?

I've had good luck with the Linux apps up until the recent gpu application errors that started this month. The cpu tasks ran fine.

I and others have voiced our displeasure with the credit awarded for the flops used for the QM tasks in this thread.
New Student and QMML Project

* CPU threads are limited to 4 (you should still be able to crunch multiple WUs at once, please check)

Let us know.

Hi, we need more CPUs on Linux to run QM simulations. Anybody can help?

I don't see that you have made an announcement on the BOINC forum yet. The Projects section would probably be best.
http://boinc.berkeley.edu/dev/forum_forum.php?id=11

I have an Intel 2600K with 8 logical cores. I wanted to reserved 2 cores for feeding 2 GPUs that are running Folding@home. I set the computing preference in boinc to use, at most, 80% of processors (6 cores).

Data on 19 WUs before GPUGrid changes (processor usage varied but 5-6 cores on average I think)

Average run time (sec): 3,129.23
Average CPU time (sec): 16,122.19
Average credit per WU: 228.7
Average WU per day: 27.6
PPD: 6314.8

Data on 15 WUs after GPUGrid changes. Processor usage was 4 cores even though set at 6)

Average run time (sec): 3,566.32
Average CPU time (sec): 14,114.28
Average credit per WU: 819.284
Average WU per day: 24.2
PPD: 19848.5

Summary: Processor usage seems to be maxed out at 4. Run time has increased, CPU time has decreased, WU completed per day has decreased and PPD has increased significantly.

Hi, we need more CPUs on Linux to run QM simulations. Anybody can help?

I have three machines on it, but I can run only one work unit at a time on average. That is because when any more start up at once, they error out, as has been discussed before. And I run two cores per work unit for efficiency. But if you could solve the start-up problem, I could run more.

Are you sure that you are using an "older" credit mechanism? From the response in the "New Student and QMML" thread from Richard Haselgrove who corrected me in my assumption you might be using an "older" mechanism.

Be careful of your terms. 'CreditNew' has been the default BOINC mechanism since 2010. I suspect this is what GPUGrid is using for these tasks: the support mechanisms for 'even older credit' have been removed from the codebase.

Hmmm ... I just ran a new QC task with the supposed new credit. Not seeing any difference.

Run time 3,292.22
CPU time 12,925.47
Validate state Valid
Credit 110.63

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Since just after mid day yesterday (UTC) I have noticed an increase in credit awarded for the QC WU's. Doing some quick calcs, it appears the increase is about 4.5x of what we were getting. It also appears they are more fixed in value proportional to the size of the WU. My faster machines are getting over 500 credits/hr (4 cores) compute time whereas the slower machines are getting proportionately less/hr and still getting equivalent credit but over a longer period of time than the faster ones.

Well, at least my avg credit per day will not be taking as much of a hit per day as it has been without Linux GPU WU's :).

So far, I have 5 machines with 4 cores each running the QC project and will add one more when I install the memory upgrade on one of the headless systems.

I'm not sure the higher credit is not due to the larger molecule size in the latest tasks that Dominik explained to me here.

No higher credits for the tasks I've crunched yesterday and today.

I stop and will try to understand what is happening.

I've also been having trouble with work units erroring out in this way. I have over 150 cpu cores spread out across a variety of machines, all under linux. Just a few moments ago I attempted to attach to GPUGRID only to have computational error after computational error. I hope this is fixed shortly as I would love to have GPUGRID as one of my default projects.

Yes, credit is doing something very strange. I got 111 credits for 3292 seconds of cpu time.

klepel got 1362 credits for the same time.

Run time 3,262.28
CPU time 12,834.34
Validate state Valid
Credit 1,361.79

Task 13118994

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

CreditNew is CreditNew.

You cannot compare one project's credit to another.

I used 4 cores to generate 110 credits for 54 minutes of compute time.

I can use one core to generate 108 credits for 60 minutes of compute time for SETI CPU tasks.

No reason to run these tasks still for me.

Are you seriously comparing SETI to GPUGRID?!

CreditNew is CreditNew.

You cannot compare one project's credit to another.

Thus my comment about CreditNew. CPU projects that have higher or lower then typical RAC are most likely using something else besides CreditNew like a fixed credit or another algorithm.

Yes I understood your post and sentiment. My post was directed at the other poster's incredulous comment.

This project itself utilize both mechanisms. CreditNew for cpu tasks and fixed credit awards for gpu tasks.

As far as I have been able to find, that is unique among projects. Usually it is either/or not both.

Yes I understood your post and sentiment. My post was directed at the other poster's incredulous comment.

This project itself utilize both mechanisms. CreditNew for cpu tasks and fixed credit awards for gpu tasks.

As far as I have been able to find, that is unique among projects. Usually it is either/or not both.

Would you please list the QC project progress on the server status page as well:

http://www.gpugrid.net/server_status.php

Thanks.

Another issue is that your app does not dynamically allocate CPU cores according to the BOINC settings. Instead it claims all physically present cores. That is a major problem when trying to run computations on the GPU as well because to do so, the GPU project automatically (or I manually) reserve(s) one CPU core per GPU task.
Example: When the BOINC manager is set to use 7 of the 8 cores to do CPU computations, your CPU client grabs all 8 cores (or since recently 2x 4 cores).
That is not acceptable.
Please fix this to attract more people to donate CPU cycles to your project.

Michael.
____________
President of Rechenkraft.net - Germany's first and largest distributed computing organization.

Another issue is that your app does not dynamically allocate CPU cores according to the BOINC settings. Instead it claims all physically present cores.

QC is the proper app name. This is how I limit QC to 2 threads per task.

An error on a wu (task 17040682):

<core_client_version>7.8.3</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
ConnectionError(MaxRetryError("HTTPSConnectionPool(host='repo.continuum.io', port=443): Max retries exceeded with url: /pkgs/main/linux-64/repodata.json.bz2 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc2a3f56860>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))",),)


Traceback (most recent call last):
File "pre_script.py", line 13, in <module>
raise Exception("Error installing h5py")
Exception: Error installing h5py
08:49:09 (1252): $PROJECT_DIR/miniconda/bin/python exited; CPU time 0.469942
08:49:09 (1252): app exit status: 0x1
08:49:09 (1252): called boinc_finish(195)

Hi, we need more CPUs on Linux to run QM simulations. Anybody can help?

Traceback (most recent call last):
File "pre_script.py", line 13, in <module>
raise Exception("Error installing h5py")
Exception: Error installing h5py
08:49:09 (1252): $PROJECT_DIR/miniconda/bin/python exited; CPU time 0.469942
08:49:09 (1252): app exit status: 0x1
08:49:09 (1252): called boinc_finish(195)

One of my CPUs is crunching linux jobs, I will add two more next week.

I have added three. Athlon 5350, I3 3240, I3 6100. Not the best ones but doing their job. I can add more but I would like to know how many WUs can we expect for the Linux QM app?

BTW ATM just 92 users are crunching QM, that's sad :(

I have added another machine, and now have four on it (2 i7-3770, 1 i7-4790 and 1 Ryzen 1700), with two to four cores per machine allocated via the resource share. The main problem in running them is that when two or more start up at the same time, they error out. That happens mainly during reboots, but otherwise they never start up at the same time. I leave my machines running 24/7, so I don't reboot very often.

And to minimize the problem, you can run with the default 4 cores per work unit and only 4 cores (or less) per machine on average, so that they usually don't start more than one work unit at a time anyway. In that way, it is a manageable problem for me, though it would be best if they fix it. I am sure more people would then be willing to run it.

Also a Windows version would help of course, and for that they had better be seriously thinking about VirtualBox.

Jim 1348 said:

Also a Windows version would help of course, and for that they had better be seriously thinking about VirtualBox.

I have added three. Athlon 5350, I3 3240, I3 6100. Not the best ones but doing their job. I can add more but I would like to know how many WUs can we expect for the Linux QM app?

BTW ATM just 92 users are crunching QM, that's sad :(

Lucky me (not even a single problem on my end)

The main reason why I came here was to put my GPU's to work, my CPU cores are all very busy with CPDN.

Lucky me (not even a single problem on my end)

I understand that. I'm using only 4C or 2c/4t CPUs so I can't start two at once. Probably that's why i don't have any issues :)

Jim 1348 said:

Also a Windows version would help of course, and for that they had better be seriously thinking about VirtualBox.

If you want to go the virtualbox route, you can create your own virtualbox instance, install your favorite flavor of Linux (I chose Ubuntu), make sure that gcc is installed, install BOINC and start running the Linux version of the Quantum Chemistry tasks.

The linux QM app runs fine but it requires some packages to be installed. People should expect infinite number of workunits...

We will run this for ever.

Could someone who knows how, make a description of exactly which dependencies are needed to make the QC app run flawlessly, in the FAQ section? I think it is a good place for it to be described.

I understand that. I'm using only 4C or 2c/4t CPUs so I can't start two at once. Probably that's why i don't have any issues :)

And to minimize the problem, you can run with the default 4 cores per work unit and only 4 cores (or less) per machine on average, so that they usually don't start more than one work unit at a time anyway. In that way, it is a manageable problem for me, though it would be best if they fix it. I am sure more people would then be willing to run it.

JoergF

Try installing gcc and see if that helps.

In a terminal session

JoergF

Try installing gcc and see if that helps.

In a terminal session

sudo apt-get install gcc

JoergF said:

However I am not able to test it as there seems to be a daily quota of 2 tasks per computer and I have to wait for the next day

Thank you.. seems to work now :)
____________
I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

People should expect infinite number of workunits...
We will run this for ever.

Oh, well.
So we dream for a opencl client (or an sse/avx cpu optimization)

As you probably know, the FMA version of TN-Grid is faster than the AVX version. At least that was my result comparing a Ryzen 1700 (FMA) to an i7-4770 (AVX), both on Ubuntu.

The linux QM app runs fine but it requires some packages to be installed. People should expect infinite number of workunits...

We will run this for ever.

The linux QM app runs fine but it requires some packages to be installed. People should expect infinite number of workunits...

We will run this for ever.

I still think, the main obstacle to gain a wider LINUX contributor base is to solve the start-up error when two WUs start at the same time. In my view, this hinders the implementation of the app on newer computers with more than 4 threads/cores, as the other available computer threads/cores are not loaded by other BOINC projects.

You can sort of learn to live with its idiosyncrasies after a while. They are more an annoyance at first. But I wonder if a non multi-core version would fix the start-up problems? It would be worth looking into.

May I touch upon this matter again after 2,5-3 weeks... at the risk of being a pain in the neck... is there any progress regarding concurrent QC tasks? I would really like to use a 8-16 core CPU (instead of my i3) and run several jobs at the same time. Hope that the admins can take some time to follow up, in view of the many jobs we still have to crunch.

Thanks.
____________
I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Hey,

What are the recommended PC specs you recommend for these Linux job units? (minimal CPU and ram?) Thanks
____________
Cruncher/Learner in progress.

I have five QC running at the moment on two machines, and they are taking from 230 MB to 260 MB. I would plan on at least 300 MB to be safe.

I now have one running at 1016 MB for a few minutes, but now down to 932 MB. It looks like the upper limit is a bit elastic.

I now have one running at 1016 MB for a few minutes, but now down to 932 MB. It looks like the upper limit is a bit elastic.

I have five QC running at the moment on two machines, and they are taking from 230 MB to 260 MB. I would plan on at least 300 MB to be safe.

I have five QC running at the moment on two machines, and they are taking from 230 MB to 260 MB. I would plan on at least 300 MB to be safe.

pardon me for jumping in, does that mean it is possible now to run several QC tasks at the same time? For example, 4 Jobs on the Ryzen 1700?

I now have one running at 1016 MB for a few minutes, but now down to 932 MB. It looks like the upper limit is a bit elastic.

Just to confirm, that's 1GB per work unit?

It is possible to run as many as you want concurrently. A bug unfortunately prevents simultaneous starts.

Requirements are in some other thread; they are rather mild (only thing you need to have the gcc package installed).

I will make my question a little more simple... would a core i3 work fine with this project, and if so, would a gen 1 be fine, gen 2, or newer? My budget for another PC dedicated to cpu work is about 100 USD. I do not mind for a small desktop either without a big gpu slot. Thank you.

I will make my question a little more simple... would a core i3 work fine with this project, and if so, would a gen 1 be fine, gen 2, or newer? My budget for another PC dedicated to cpu work is about 100 USD. I do not mind for a small desktop either without a big gpu slot. Thank you.

For questions like this, wuprop is a fantastic resource. Check the link and you can see things like time to complete for various CPUs and other requirements like memory. In this case looks like you may need 776.5 MB of RAM and an i3 should do just fine.

It is possible to run as many as you want concurrently. A bug unfortunately prevents simultaneous starts. I am investigating possible workarounds but no timeline yet, sorry.

...You may also stop all tasks

I am having a lot of CPU Quantum Chemistry WUs error out as soon as they start on my Ubuntu machine. Some work but most error out. Is this inherent with the CPU app or is it my machine?

Below are the machine's tasks:
http://www.gpugrid.net/results.php?hostid=424454

Me too:

http://www.gpugrid.net/result.php?resultid=17510462

(SORRY, double post)

I am having a lot of CPU Quantum Chemistry WUs error out as soon as they start on my Ubuntu machine. Some work but most error out. Is this inherent with the CPU app or is it my machine?

So I understand why I receive "error while computing" with almost 0 seconds of compute time (multiple WUs starting at once) but I don't understand the fairly high number of failed WUs with multiple thousand second or even over ten thousand second run times. Linked below are my error rates:

http://www.gpugrid.net/results.php?hostid=424454&offset=0&show_names=0&state=5&appid=

Does anyone think they can explain why the non WUs starting at once errors are occurring?

Did you stop the computer at any point, and let them all RE-start in unison - from whatever point they'd reached?

Did you stop the computer at any point, and let them all RE-start in unison - from whatever point they'd reached?

We are losing CPU Volunteers, can anyone help?

We are losing CPU Volunteers, can anyone help?

We are losing CPU Volunteers, can anyone help?

It's up to the scientists to sort. They will need a Windowa version to have any hope of getting a reasonable throughput.

Since you are using the wrapper from LHC@home why don't you use VirtualBox? This would eliminate the need for a Windows version. All Windows user of LHC@home can run LHC@home tasks, written in Scientific Linux, using Virtual Box.
Tullio

changed my desktop settings to include cpu tasks again. (im in the pool so it wont show on my account). hope my contribution, small as it is, helps!

Since you are using the wrapper from LHC@home why don't you use VirtualBox?

Since you are using the wrapper from LHC@home why don't you use VirtualBox?

No, please.
Now i'm using a Linux vm with Virtual Box for this project and it's a nightmare.

The LHC@home performance using Virtualbox vs direct from linux is a ridiculous loss in efficiency and performance, not to mention substantial ram usage. If we can avoid virtualbox outright I would consider that a win.

We talked with the devs. The idea is to collaborate over summer for a Windows version. So I hope by the end of summer we should have a new release.

All CPU tasks fail on my SuSE Linux Leap 42.3. All GPU tasks complete and validate on my GTX 750 Ti giving me huge credits, more than Einstein@home and SETI@home GPU tasks.
Tullio

All CPU tasks fail on my SuSE Linux Leap 42.3. All GPU tasks complete and validate on my GTX 750 Ti giving me huge credits, more than Einstein@home and SETI@home GPU tasks.
Tullio

All CPU tasks fail on my SuSE Linux Leap 42.3. All GPU tasks complete and validate on my GTX 750 Ti giving me huge credits, more than Einstein@home and SETI@home GPU tasks.
Tullio

Hi, Credits cannot be compared from project to project. And even though GPU tasks give so much credit here at GPUGrid there is still substantial scientific weight and benefit to GPUGrid's CPU Work Units even though they don't give as much credit. Please keep this in mind.

Hi, Credits cannot be compared from project to project. And even though GPU tasks give so much credit here at GPUGrid there is still substantial scientific weight and benefit to GPUGrid's CPU Work Units even though they don't give as much credit. Please keep this in mind.

We are losing CPU Volunteers, can anyone help?

We are losing CPU Volunteers, can anyone help?

If admins want CPU support they'll make an app w/o bugs. No effort by them, no effort from us.

I would put up with the bugs if I could. But I get only crashes on QC now, so I am out of business.

I hope they make a big announcement when it is fixed, since I won't know about it otherwise. Maybe they are spending their time on the Windows version?

Maybe they are more interested to the results of the CRUNCHATHLON competition. You can not compete with a dead horse.
Tullio

You can not compete with a dead horse.
Tullio

Well, I gave QM a try, but I really didn't like it, for a few reasons.

First, the setup doesn't work when running more than one WU at a time. You need a "lock file" to ensure only one thread does the setup. If that thread gets aborted you might have problems, but it's better than the current situation.

Second, you know what I hate? I hate BOINC apps that download more data themselves. (Such as LHC@Home Atlas.) All necessary data should be coming from your BOINC server. At least your app only seems to do that downloading once.

Third, you know what else I hate? Bloated apps. Your "miniconda" includes such things as TK (not needed unless there's a screen saver?) and man pages. Maybe if you streamlined it you could fit whatever extra data it downloads in the initial download, and then you wouldn't need the networking libraries either.

But, I finally did get QM working. What made me give up on it was the credit. It started around 600 credits/WU, but it seemed to get cut in half every few sets of WUs. It was down around 50 when I gave up.

But, I finally did get QM working. What made me give up on it was the credit. It started around 600 credits/WU, but it seemed to get cut in half every few sets of WUs. It was down around 50 when I gave up.

But, I finally did get QM working. What made me give up on it was the credit. It started around 600 credits/WU, but it seemed to get cut in half every few sets of WUs. It was down around 50 when I gave up.

Stefan, Can you reduce free disk-space requirement of 4768.37 MB to something like 4000MB or less? Your QM WUs do not fit on my USB 16 GB Stick anymore! (After Lubuntu Up-Grade from 17.10 to 18.04)

@Jim the WUs that I send contain varying molecules of different number of atoms. The ones I sent yesterday had very few atoms so they completed super fast. But "every molecule is sacred" as per Monty Python. I guess I could mix all molecules together but it would become an organizational chaos for me to keep track of what I have already calculated, so for now I will continue submitting them with increasing molecule size.

@Stefan can you quickly describe for us what the Quantum Chemistry Work Units are doing and what you are learning from these work units?

When can we expect some info about scientific results created with this app?

Months away, we have just started.

@Stefan can you quickly describe for us what the Quantum Chemistry Work Units are doing and what you are learning from these work units?

+ another 1. I have 7+7+3 cores 100% dedicated to QC and 4+4+4 cores 50% dedicated to QC and WCG, all 24/7. Along with 3 GTX 1060's, makes for a very warm office, especially now in summer. Would be interesting to find out what the project goals are :).

@Stefan can you quickly describe for us what the Quantum Chemistry Work Units are doing and what you are learning from these work units?

@Stefan can you quickly describe for us what the Quantum Chemistry Work Units are doing and what you are learning from these work units?

See the "New Student and QMML Project" thread for a clue.

Very interesting, thank you :)

Thank you!!

Thank you for sharing more info Stefan!

Yes, thank you, much appreciated.

Practically we are trying to teach a neural network to calculate molecular energies and forces.

OK, that gives me a better idea of how we fit into the overall scheme of things. I am glad we can do that work for you.