Hello, I noticed the task is run under mpirun, which means, it could run on multiple threads.
How to configure the task to run on multiple threads?

Dear Tomas,

NWChem that is used here for the calculations of the molecules, profit from multithreading only with bigger molecules.
We have tested 1, 2 and 4 threads and the gain was none!

Kindly,
Thomas, the chemist of the project

Interesting.
See, I am curious so I will probably try it anyway as I have found where to modify it in the script.

Interesting.
See, I am curious so I will probably try it anyway as I have found where to modify it in the script.

Tomas,

Have you noticed that when the work units start, they are 164% CPU and slowly work their way down to a lower value closer to 50% by the end?

I would interested in your mod if you would be willing to share. I find it interesting that the QC from GPUGrid was running 4 CPU threads per work unit whereas here they are just under 1.5. Please let us know if the mod significantly changes the time to complete.

Z

NWChem that is used here for the calculations of the molecules, profit from multithreading only with bigger molecules.

I don't know if NWChem supports gpu calculation (CUDA or, better, OpenCL), but this may be a great improvement...

NWchem support GPU for CCSD(T) but not for our kind of tasks (DFT)

Create an app_config.xml file for QCP:

<app_config>
<app>
    <name>nwchem</name>
</app>
<app_version>
    <app_name>nwchem</app_name>
    <plan_class>t1</plan_class>
    <avg_ncpus>2</avg_ncpus>
    <cmdline>--nthreads 2</cmdline>
</app_version>
</app_config>

Have BOINC read config files and then restart BOINC:

/etc/init.d/boinc-client restart

Works for me but I predict a single CPU thread is best. I believe these multithreaded WUs can end up with all threads but one done and they wait. With the large variability of QCP WUs this may idle too many CPUs.

---

Thanks Aurum,

I was going to play around with the app_config when I came home from work but you saved me that trouble. Thanks!

I'll give it a try here in a bit.

Z

Works for me but I predict a single CPU thread is best. I believe these multithreaded WUs can end up with all threads but one done and they wait. With the large variability of QCP WUs this may idle too many CPUs.

So I got the chance to watch these work units with varying values for number of threads. First thing I noticed was with no app_config, that the number of threads used at startup for 1 work unit is all threads. It then rapidly reduces itself down to around 300% (or 3 threads) and slowly draws down to under 1 thread until the last 10 minutes. At that point there is a rapid drop off on the CPU usage, down to around 30% (cause a red flag for amount of CPU as set by the app) then finishing up of the work unit. I'm assuming that the last 10 minutes it's wrapping up whatever it is doing and doesn't really need much CPU at that point.

With an app_config and 4 threads per work unit, I saw that each work unit was holding at 99.6% but again followed the last 10 minute drop as above. With fewer threads per work unit the value was anywhere from 70-96% CPU usage during the majority of time but again dropped off at the end. I finally settled on 2 threads for no other reason than it keeped the number of work units on my CPU to a number I wanted. I saw no change in the time to completion with varying number of threads. Review of all work units showed total percentage of cpu usage was around 96% (I'm assuming this is an average value) for all work units with varying threads.

So the only reason to keep the app_config for me is to limit total number of work units on my machine at any time and to keep any work unit from claiming all threads when it first starts up. Using the number of thread option in the app_config seems to reign in that free for all and keeps the app to a reasonable amount of threads until it can correct itself.

NWChem that is used here for the calculations of the molecules, profit from multithreading only with bigger molecules.

I don't know if NWChem supports gpu calculation (CUDA or, better, OpenCL), but this may be a great improvement...

Just ignore this user. They make the same comment at every BOINC project like GPUs are some voodoo magic.

NWChem that is used here for the calculations of the molecules, profit from multithreading only with bigger molecules.

I don't know if NWChem supports gpu calculation (CUDA or, better, OpenCL), but this may be a great improvement...

Just ignore this user. They make the same comment at every BOINC project like GPUs are some voodoo magic.

What's wrong with with GPU crunching?

Just ignore this user. They make the same comment at every BOINC project like GPUs are some voodoo magic.

There is something bad to trying to accelerate science?

Just ignore this user. They make the same comment at every BOINC project like GPUs are some voodoo magic.

I'm a long time boinc user (and team admin)
I know that gpus are not the solution for everything.
But also know that, when projects can use gpu, they have GREAT benefit.