Posts by m.somers

21) Message boards : : Number crunching : Server in trouble
Posted 1021 days ago by m.somers

this was due to network related issues (a local firewall of the IT dep failed on us on the 5th and 6th of august).


22) Questions and answers : General issues : Wish list : Eliminate work unit deadlines
Posted 1132 days ago by m.somers
I'm sorry to read that deadlines are a nuisance to you. Perhaps BOINC is not the best way of volunteering your extra cycles?

As a project admin, I think a 4 day dead-line for an 8h job is more that fair as a longer dead line will result in a higher load on the server and scheduler. That in turn will result in not being able to hand out work swiftly again.


23) Message boards : : Number crunching : Cuda 6 -> Easy GPU support for Leiden ?
Posted 1132 days ago by m.somers
Despite the success of GPUs, some codes are not easily ported / sped up by using GPUs. Our Classical code is such a code.


24) Message boards : : Number crunching : Too short crunching time, less and unequal credit
Posted 1153 days ago by m.somers

I'm sorry you have issues with the short dead-lines and the way BOINC grants credit.

The way I understand credit granting works in BOINC is that when two workunits are sent out (homogeneous redundancy) and computed by slightly different but binary compatible hosts, both hosts request a certain amount of credit based on a whetstone benchmark performed by the BOINC client during install (the server also specifies a certain amount of FLOPS to a workunit indep of the hosts involved, but this is only used in scheduling algorithms on the client). The BOINC server then grants the lowest amount of credit these hosts report to BOTH hosts. So statistically this averages out again. Sometimes you are shot, sometimes you are lucky and get more.

In your particular case I think that your A6 did the whetstone benchmark and somehow was 'graded' much slower; despite the Classical code performing not that much worse compared to the FX. We conclude thus (again) that a whetstone benchmark is perhaps not the most representative measure for the actual scientific codes people run?

None the less; this is something embedded deep in the architecture of the BOINC client and therefore as a simple project admin, somewhat out of my reach to change. Fixing the amount of credit is also not an option as some calculations are submitted by students and we cannot know how much time / credit you need to associate with them a priory. We estimate the FLOPS and use the whetstone benchmark mechanism as best as we can.

25) Message boards : : Current research : Projects
Posted 1180 days ago by m.somers
Dear philippe,

this project is not a single research project with one goal; in this project we can have several smaller (student) projects throughout the year. As it happens this week we will have some students running argon simulations on BOINC.

When a bigger research project is started and BOINC is used, it will be mentioned here. As it happens, it is not that easy to simply use BOINC for all our research, BOINC is just one of the many computational resources we have available. Also because BOINC (application) development is not for the faint harted, we tend to use the BOINC applications we already have running.

Currently we use BOINC for two things; one in teaching students; they run any type of classical trajectory they want whenever they want. As it happens this feature is open to the public too. Just look in your account on this project and see that you have a private 'queue' to submit Classical calculations into.

The other long term on going (pet) project of mine is investigating (rare) events in a specific water model. This project is a 'gather statistics and wait and see if the even happens' type of project; many many many runs are needed and the chances of any event happening are slim. To this end we continuously feed tasks into BOINC using the same input file over and over. Now due to a special trick we implemented in our application code, a random number generator seed is set and based on the work unit name. This will make sure that each individual run (although the input seems exactly the same) is an individual run. Once enough statistics are obtained we can conclude if this specific water model does feature rare events. If it doesn't, or it does wrongly so, we need to change the water model again and obviously start all over again. Now because this is a pet project me and the chances are slim to get any scientific publication in the sort-run about this, the work for this project is used as a feed when other sub project of Leiden Classical are not using BOINC.

Apart from all that, you do also need to know that this Leiden Classical thing is a sort of one man show; in our group I need to maintain and run this project on my own and I do have other stuff to do as well :-).

Hope to have informed you a bit.

If you want some more info you can have a look at

26) Message boards : : Number crunching : Work unit claimed 22.12 credits, granted 0.00 "Too many total results"
Posted 1213 days ago by m.somers
Yes, this is possible, to only allow a single work unit of a set to a single host. However, we did run into some problems with that in the past making this project shift to the 'only a single workunit of the set in time on a host' method. The thing that happened was that due to the detailed homogeneous redundancy we use, it was possible (and it actually happened too) that only a single host was available of a specific type of CPU and OS (BSD hosts are rare). With the default option you suggest, the database got filled with results that were waiting to be matched, but obviously couldn't.

27) Message boards : : Number crunching : Work unit claimed 22.12 credits, granted 0.00 "Too many total results"
Posted 1216 days ago by m.somers

no this is not so 'odd'; it should happen often, but it is possible. Let me explain; because we do classical trajectories, that are very sensitive to the precise starting conditions and floating point capabilities of CPUs, we use a thing called homogeneous redundancy. This means that work is send out and the workunit to check is afterwards send to any computer with the same CPU. This could be the same computer though if there is only one computer with a very special OS (BSD i.e.) running a less often used CPU. If that computer fails; all these workunits will fail on that computer. This project has a limit of 16 attempts before it stops. That's exactly what you have seen.


28) Message boards : : Number crunching : Valid WUs claim 0 credits
Posted 1223 days ago by m.somers
H'mmm, I have no explanation for this yet; usually the client 'claims' a certain amount of credit and this amount together with the result is compared to another run. If they both match, you are granted the credit. So that seems to indicate that if your client somehow asks '0' credit, yet the output is just fine, there is something with the BOINC client code?

Having had a look at the results of this computer in the DB; you do get the credits you claim somehow?


29) Message boards : : Leiden Classical : Bad Glitch in Mac Version
Posted 1319 days ago by m.somers

at the moment I do not have access to Mac Power / Mac Intel hardware to recompile the code without any graphics. I have ported the code already recently to not use graphics, and successfully compiled it for Linux, BSD and Windows, but not for Macs.

So in short only one option left as a fix; abandon the Mac (and BSD due to other maintenance issues) support and introduce the 'anonymous' platform. In this way Mac users and BSD users can compile the code themselves and support LC. This is not so ideal I realize, if not only because of the use of Homogeneous Redundancy of this project.

The alternative is accepting the issue for some Mac users for the time being and hoping that at some point *soon* I am able to access (at least) Mac Intel hardware to compile the code without graphics.


30) Message boards : : Leiden Classical : Computation Error
Posted 1329 days ago by m.somers

have you made sure all graphical libs are available?


Next 10 posts

Return to Leiden Classical main page

Copyright © 2017 Leiden University - Leiden Institute of Chemistry - Theoretical Chemistry Department