Posts by Ananas
log in
1) Message boards : Number crunching : NO new work. (Message 2673)
Posted 21 Nov 2015 by Ananas
Do I have an RSS feed?

:D

Didn't know...

Well, you just posted to it an hour ago *g

p.s.: the firefox RSS reader is missing one file :

http://findah.ucd.ie/rss_image.gif

As other projects do not have it either, it seems not to be a BOINC thing. it probably doesn't belong to BOINC. It could be some small version of the project logo or just a GIF version of http://findah.ucd.ie/img/rss_icon.gif.
2) Message boards : Number crunching : NO new work. (Message 2669)
Posted 20 Nov 2015 by Ananas
... to let us know that there is new work. ...

Couldn't you use the RSS feed for news? That would a method that would not require an individual solution for this project, it is a BOINC-builtin so it wouldn't need to be reinstalled after a server side BOINC update.
3) Message boards : Science : Statistical methods (Message 2594)
Posted 22 Sep 2015 by Ananas
The score does not change that much when you take an other seed.
For example, it varies from -6.44XXXX to -6.45XXXX.

We are trying to find a duo ligand/receptor with a very negative value. The enormous amount of tasks came from the size of the genome we are screening.

The duo will be then tested on lab, by measuring the thermostability.

Does it make sense?

Basically yes, thanks :-)

I assumed that the result range would be much wider, which would have enforced several samples for the same pair, so no promising candidates could slip through.

But then ... if there is such a minor influence, why use a random seed at all instead of having the same seed value for all calculations? You wouldn't need to store the seed in the database if it was a constant.
4) Message boards : Science : Statistical methods (Message 2591)
Posted 19 Sep 2015 by Ananas
I have a problem understanding how why projects like RNA-World, QuantumFIRE, QMC and this one work.

This is how I understood it :

The method all these projects use is a statistical one. Statistical methods work somehow similar to swarm intelligence, a sample consisting of a single result is worth nothing, it might be anything between totally wrong and exactly right. The larger the sample becomes, the more exact will be the average(!) value of all results combined.

But :

All the mentioned BOINC projects calculate one single value using a single seed value (most random seed, RNA fixed seed for validation) for each problem, which - if my assumption is correct - would be worth nothing. Wouldn't it be required to calculate each ligand/receptor combination a lot of times with different random seeds, then combine the results and see in which numeric range the result count becomes more dense - something like the peak of a (lin or log) normal distribution?
5) Message boards : Number crunching : Old tasks not removed (Message 2590)
Posted 18 Sep 2015 by Ananas
...
2. Is it safe to remove the old ones manually ?
...

Definitely no, as they might be referenced by future workunits again.

It would be better to turn off work fetch, let the cache run empty, reset the project and then enable work fetch again.

p.s.: another advantage of a reset now and then is that the request XML files become much smaller for quite a while, until those files pile up again (this saves web traffic)

If you wish you can backup the file vina_1.1_arm-unknown-linux-gnueabihf before you reset and move the backup copy back to the project folder before you re-enable download. If you have one with a higher version number (vina_1.2_... or so), backup that one instead.
6) Message boards : Number crunching : Upload data amounts (Message 2588)
Posted 17 Sep 2015 by Ananas
...
But the difference is quite huge, and I don't really know why...

My guess would be sched_request_findah.ucd.ie.xml

If you do not reset the project now and then, this file becomes huge, as it contains the file list of the undeleted receptor files that are still available for future ligand runs.
7) Message boards : Number crunching : 64 bit systems now using 32 bit application for Linux (Message 2561)
Posted 25 Aug 2015 by Ananas
Under Win XP x64 it seems to be a bit random, wether it uses x64 or x86 version.

It started to use x64 some time ago (it might even have happened on the same date when the behaviour of your boxes changed) - but under Windows it doesn't make any difference, the two binaries differ only in the name but other than that they are exactly identical.
8) Message boards : Number crunching : Errors again. (Message 2549)
Posted 20 Aug 2015 by Ananas
... Still, it would be nice if these could be filtered out before they get distributed. ...

According to Ben this cannot be done so easily because the ligand files are not in the file system but in the database.
9) Message boards : News : Project down this weekend (Message 2545)
Posted 16 Aug 2015 by Ananas
[error] Error reported by file upload server: can't open log file '../log_findah/file_upload_handler.log' (errno: 9)

p.s.: maybe you started something with the wrong login account?
10) Message boards : Science : Future possibilities (Message 2530)
Posted 8 Aug 2015 by Ananas
Could be this?
http://www.ur.se/Produkter/170138-UR-Samtiden-Miljo-och-framtidstro-Klimatet-och-halsan ...


Yes this is the one, thanks :-)
11) Message boards : Number crunching : NO new work. (Message 2497)
Posted 20 Jul 2015 by Ananas
empty again
12) Message boards : Number crunching : Unable to reset password on another account (Message 2493)
Posted 13 Jul 2015 by Ananas
If you still have a file "account_findah.ucd.ie.xml" on one of the computers that you're using with that other account, you can use the authenticator from that file to login to the account and then change the password without knowing the old one.

Just switch to "login with authenticator" on the login page, paste that hex number there and you're in on the account connected to the authenticator.
13) Message boards : Number crunching : Upload Error: File Xfer Error (Message 2488)
Posted 10 Jul 2015 by Ananas
When a whole series of results gets resent, they usually have an invalid atom definition in the ligand file. As this is one of the first checks, those run only for seconds so besides the downloads, not many ressources are wasted.
14) Message boards : Number crunching : Upload Error: File Xfer Error (Message 2485)
Posted 8 Jul 2015 by Ananas
The host that received the two crashed workunits on your computer after the crashes crunched them without problems.

You computer finished all other results from the same ligand series without problems.

So there is nothing symptomatic to recognize, that would help to trace and narrow down a potential problem.

Hard to tell why they crashed on your box, maybe CPU overheating caused by some fluff on the CPU cooler on a hot day?
15) Message boards : Number crunching : Wu last 3 hours instead of 14 min. (Message 2477)
Posted 30 Jun 2015 by Ananas
I found the bug in my runtime/credits formula.

The first thing I had noticed is that only the square root of the receptor atom count is a relevant factor for the runtime - but ... the runtime does not grow by the factor of 2 when the receptor grows by 4, the runtime shrinks by the factor of 2 when the receptor grows by 4.

So it wouldn't have to be multiplied with sqrt(nReceptorAtoms) but divided by that expression. I didn't expect that a higher count might calculate faster so I didn't spend a thought on the type of influence :-/

If this would be adjusted now, the multiplication factors for credits and fpops_est would have to be re-evaluated, requiring another test series. That's why I think it is better to leave it as it is for now, especially considering that Ben has important non-BOINC stuff to do at the moment.
16) Message boards : News : server_status updated (Message 2471)
Posted 29 Jun 2015 by Ananas
... I forgot to backup my code for the progress bar....

If it was inline code, archive.org might have done that (partially) for you, at least the client side code should be there.
17) Message boards : Number crunching : Had 168 work units error out (Message 2462)
Posted 25 Jun 2015 by Ananas
Score = max double, this must be a calculation error, probably an uncaught over-/underflow problem in Vina
18) Message boards : Number crunching : Wu last 3 hours instead of 14 min. (Message 2461)
Posted 25 Jun 2015 by Ananas
This is how a WCG Vina job looked like (2 months ago) and what gave me the idea, it might be checkpoints between separate Vina calls :
0 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05207036.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 677572976 1 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05207482.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 384459551 2 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05207752.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 1366296944 3 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05207903.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 1693372795 4 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05208075.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 367930709 5 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05208398.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 32182934 6 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05214261.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 1399895556 7 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05215023.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 2095529556 8 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05220585.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 2096032468 9 -receptor x4J54_B_PRAS.pdbqt -ligand ./ZINC05220607.pdbqt -center_x 0.00 -center_y 5.50 -center_z 0.00 -size_x 30 -size_y 22 -size_z 25 -exhaustiveness 4 -seed 2047155193

Of course this might have changed since then.
19) Message boards : Number crunching : Wu last 3 hours instead of 14 min. (Message 2458)
Posted 25 Jun 2015 by Ananas
... that WCG now have a version of Vina which checkpoints eight times during the run (every 12.5%) ...


I'm not so sure about that. From what I could see, a single WCG WU consists of several (could be 8) separate Vina runs, working on a small ligand file each. The ligand files are taken from a common .zip archive.

In this case, it would not be Vina itself that has the checkpoints but there is a checkpoint between those separate Vina calls.
20) Message boards : Number crunching : Wu last 3 hours instead of 14 min. (Message 2455)
Posted 21 Jun 2015 by Ananas
...
Thus the %progress indicator was not accurate.
...

The progress indicator shows the percentage of time elapsed from the calculated estimated runtime, it is not derived from the real progress.

The calculation of the estimated total runtime is far from perfect, especially after you had a batch of really short workunits (which influence a correction factor) it can become quite unexact.

I tried to bring the estimation formula close to the known runtime of those (few) sample values that I had, calculated from some basic workunit features.

Overall it seems not to be really bad, at least better than what we had before. The work buffer management on client side now works fairly well and the relation between runtime and credits is fairly constant over a wide range of very different workunits. The longer running series are usually weighted slightly higher, which compensates the higher risk of running them without checkpoints.

As the progress indicator cannot be better than the estimated runtime, don't give up on a result too early when it doesn't increase as expected. Crunchers who have been here for a while sure will remember that there are workunits running 8 hours and more, even on fast computers.


Next 20

Main page · Your account · Message boards


Copyright © 2017 Dr Anthony Chubb