Give it try, if you like.

Something similar to this, was done in the past for oversize output files. It worked.

thanks for the hints.
I remember a similar procedure for LHC/ATLAS tasks sometime last year, when some of them had a "exit_disk_limit_exceeded" problem.
however, to get this done was somehow tricky; from what I remember, one had to do something like stopping the task, even shutting down BOINC, and then increasing the figure (by quite an amount).

However, at this point I cannot try anything, since no betas are available.

Give it try, if you like.

Something similar to this, was done in the past for oversize output files. It worked.

I don't like to use tricks. I prefer a bugfixed version of the app.

I prefer a bugfixed version of the app.

me, too !

Approx. 30% of the WUs are outside the disk limits as it was noted. I will raise the limit for the next batch. For the time being, just let them fail.

I will raise the limit for the next batch ...

Toni, any rough idea when the next batch will be sent out?

half an hour ago, I got a few tasks downloaded. So let's see whether they will succeed this time, or fail again.

However, what I notice is although my settings in the app_config.xml are for 2-core (which is shown in brackets in the BOINC manager), the Windows task-manager shows that only 1 core is being used by Python. Any explanation for this discrepancy?

the first task from today got finished successfully after some 4.250 secs, which is very nice :-)
http://gpugrid.net/result.php?resultid=20386975

Right thereafter, the next one got started, and again, although it should be 2-core, only one core is used.

Does anyone else make the same experience?

Toni wrote

Approx. 30% of the WUs are outside the disk limits as it was noted. I will raise the limit for the next batch. For the time being, just let them fail.

1 of 4 tasks which I downloaded and crunched this afternoon showed the
"196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED" error
again. How come?

http://gpugrid.net/result.php?resultid=20388212

Toni wrote

Approx. 30% of the WUs are outside the disk limits as it was noted. I will raise the limit for the next batch. For the time being, just let them fail.

1 of 4 tasks which I downloaded and crunched this afternoon showed the
"196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED" error
again. How come?

http://gpugrid.net/result.php?resultid=20388212

That's because the WUs are from the current batch, not the next batch. You lucked out and got 3 good ones.

Toni wrote

Approx. 30% of the WUs are outside the disk limits as it was noted. I will raise the limit for the next batch. For the time being, just let them fail.

1 of 4 tasks which I downloaded and crunched this afternoon showed the
"196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED" error
again. How come?

http://gpugrid.net/result.php?resultid=20388212

That's because the WUs are from the current batch, not the next batch. You lucked out and got 3 good ones.

yesterday, another 3 tasks were downloaded, all of them failed. Total wasted CPU time about 20.000 secs.
Obviously, all these tasks are still from the current faulty batch.

Question for Toni: Why are these tasks not withdrawn? And when will the next batch with the increased disk limit be sent out?
I hate to waste that much of my CPU work.

Toni wrote

Approx. 30% of the WUs are outside the disk limits as it was noted. I will raise the limit for the next batch. For the time being, just let them fail.

1 of 4 tasks which I downloaded and crunched this afternoon showed the
"196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED" error
again. How come?

http://gpugrid.net/result.php?resultid=20388212

That's because the WUs are from the current batch, not the next batch. You lucked out and got 3 good ones.

yesterday, another 3 tasks were downloaded, all of them failed. Total wasted CPU time about 20.000 secs.
Obviously, all these tasks are still from the current faulty batch.

Question for Toni: Why are these tasks not withdrawn? And when will the next batch with the increased disk limit be sent out?
I hate to waste that much of my CPU work.

Actual, it is better not to cancel this batch, and let it run its course, until the WUs all become "Too many errors (may have bug)" WUs, because they will in time disappear from being posted. If you cancel them before that, the WUs will stay posted forever. It is a fault in the system. You may have noticed errors from years ago, still posted.

okay, I understand.

So, the question (for me) now is: how many more WUs are in the current batch?
Will they be sent out during one more week, one more month ... ?

And when will the new batch be launched?

As said before: I do understand that this is beta, and WUs can fail.
But knowing that due to the too law disk limit setting in the current batch most of the WUs are bound to fail, it doesn't make a whole lot of sense to me to download them and waste quite some CPU time.

Although no "unsent" tasks were shown in the Project Status Page this morning, my PC downloaded 3 WUs.
Again, all 3 failed from the disk limit error, after a total runtime of about 19.000 secs.
Failure rate: 100% :-(((

Hence, it would really be great to know for how much longer these faulty WUs from the "old" batch will be sent out, and when the new batch will be published.

a few minutes ago, the fourth WU within short time failed.
I am giving up now and switched them off in the settings. It's a waste of CPU time.

Perhaps Toni or someone else from the GPUGRID team could post a short message when the new batch which is supposed not to contain this disk limit error will be available.

Perhaps Toni or someone else from the GPUGRID team could post a short message when the new batch which is supposed not to contain this disk limit error will be available.

It seems there is no hurry...

Perhaps Toni or someone else from the GPUGRID team could post a short message when the new batch which is supposed not to contain this disk limit error will be available.

It seems there is no hurry...

I find it a pity that the GPUGRID people obviously don't invest more efforts in developping a well functioning Windows app for QC.
By this, they forego huge computational power.

A look at the project status page shows well what I talk about:
presently, there are some 175.000 unsent tasks for which only 100 Linux users are taking care of.
From what can be seen when when enough GPU tasks available, there are about 1000 users crunching them, mostly Windows of course.
I imagine that crunching CPU tasks on Windows would attract even more people, perhaps the double number or even more (even if the number would be only 1000, this would mean a 10-fold of what it is now under Linux).

So, instead of having 100 users crunching QC on Linux, there would maybe 2000 people crunching QC on Windows.

Hence, I repeat my statement from above: they forego huge computational power. Why so?

We have stated this in the past but I'll explain it here again. GPUGRID is related to the lab. In the lab we don't have a C++ developer, they are all chemists, biologists and statisticians. Best bet would be me as a computer scientist but I've been busy with many other things recently. So the development of the Windows app has fallen on Raimondas who is very nice to do this as he works in a company (Acellera) which obviously has clients to take care of and does not have an immediate gain from making this work on GPUGRID and Toni who tests it out of personal interest. The current paper we are working on takes priority so once it is finished which is supposed to be this week Raimondas and Toni might finish up the app. According to their latest news the app works mostly fine now except lacking some optimization so it should not be too far off.
Patience please, we will make it.

... Raimondas and Toni might finish up the app. According to their latest news the app works mostly fine now except lacking some optimization so it should not be too far off.
Patience please, we will make it.

thanks for the thorough information, this helps us to understand what's going on.
So we'll keep our fingers crossed that at QC app for Windows will be available soon :-)
My guess is that many crunchers will use it.

My guess is that many crunchers will use it.

Please, see if you can run their servers dry. Then I can put my Linux machine on something else. I like to use them where they are needed most.

I think the Quantum Chem app should be a subproject and then there should be badges. If you offer badges, they will come.