Posts by Michael H.W. Weber

1) Message boards : Number crunching : Task ran fine, but timed out on Threadripper 9000 after approx. 2,5 days: rb_04_04_702801_692873_ab_t000__robetta_cstwt_5.0_FT_IGNORE_THE_REST_09_10_3023291_43_0 (Message 113541) Posted 14 Apr 2026 by Michael H.W. Weber Post: The other thing I notice is that User is using Boinc Manager 7.24.1 when the current version is 8.2.9 I run that older BOINC client (the latest v7 version) on purpose because I figured that the entire v8 BOINC client batch has severe scheduling issues - especially in conjunction with using BAM! and communicating with Primegrid (over BAM!). Just check out other BOINC forums where people complain about not receiving tasks - it always seems connected to BOINC v8 clients. Michael.
2) Message boards : Number crunching : Task ran fine, but timed out on Threadripper 9000 after approx. 2,5 days: rb_04_04_702801_692873_ab_t000__robetta_cstwt_5.0_FT_IGNORE_THE_REST_09_10_3023291_43_0 (Message 113526) Posted 8 Apr 2026 by Michael H.W. Weber Post: So, I got a task which ran unusually long (I did not set ANY preference regarding desired run time) and was timed out after the return deadline was reached. Note that this machine does not bunker tasks, so it started right after download and did not finish within time. This is the work packet: https://boinc.bakerlab.org/rosetta/workunit.php?wuid=1447140176 This is the task (no log): https://boinc.bakerlab.org/rosetta/result.php?resultid=1626758790 WU name is: rb_04_04_702801_692873_ab_t000__robetta_cstwt_5.0_FT_IGNORE_THE_REST_09_10_3023291_43_0 I checked the screensaver after around 2 days, 14 hrs and it looked just fine. Apparently, this WU type does not "converge" (if this applys here) and some scientist might want to take a closer look at this packet. Michael.
3) Message boards : Number crunching : Chi angle error (Message 113503) Posted 30 Mar 2026 by Michael H.W. Weber Post: ...depending on the computer (all Windows 11 Pro) this error rate is between 30% to 50% of all tasks computed and therefore unnecessarily contributes to a significant CO2 footprint. Michael.
4) Message boards : Number crunching : Chi angle error (Message 113502) Posted 29 Mar 2026 by Michael H.W. Weber Post: It's been an issue ever since they released the application. Instead of exiting gracefully, it crashes ...well, it seems it always happens in an alpha helix at amino acid residue 306. That is something systematically faulty, which these guys should take a closer look at. To me, it doesn't look like a true computational error (hence, one could grant credits for this - although this is not the reason for why I am reportig this). Michael.
5) Message boards : Number crunching : Chi angle error (Message 113496) Posted 28 Mar 2026 by Michael H.W. Weber Post: Of 67 task which one of my machines completed recently, 12 show the same error and all my wingmen either did not complete the task in the deadline time window or produced the same error: Task example: https://boinc.bakerlab.org/rosetta/result.php?resultid=1626699271 Error log: <core_client_version>7.24.1</core_client_version> <![CDATA[ <message> Unzul�ssige Funktion. (0x1) - exit code 1 (0x1)</message> <stderr_txt> command: projects/boinc.bakerlab.org_rosetta/rosetta_4.20_windows_x86_64.exe @rb_03_26_702597_692734_ab_t000__robetta_FLAGS -in::file::fasta t000_.fasta -jumps:pairing_file t000_.fasta.bbcontacts.jumps -jumps:random_sheets 2 -constraints::cst_file t000_.fasta.CB.cst -constraints:cst_weight 5.0 -constraints::cst_fa_file t000_.fasta.MIN.cst -constraints:cst_fa_weight 5.0 -in:file:boinc_wu_zip rb_03_26_702597_692734_ab_t000__robetta.zip -frag3 rb_03_26_702597_692734_ab_t000__robetta.200.3mers.index.gz -fragA rb_03_26_702597_692734_ab_t000__robetta.200.6mers.index.gz -fragB rb_03_26_702597_692734_ab_t000__robetta.200.8mers.index.gz -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -mute all -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 3187034 Using database: database_357d5d93529_n_methylminirosetta_database [ ERROR ]: Caught exception: File: C:cygwin64homeboinc4.17Rosettamainsourcesrccore/pack/dunbrack/SingleResidueDunbrackLibrary.hh:306 chi angle must be between -180 and 180: -nan(ind) ------------------------ Begin developer's backtrace ------------------------- BACKTRACE: ------------------------- End developer's backtrace -------------------------- AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS. </stderr_txt> ]]> I believe it is a faulty setting in the input files. Quite annoying after running for 28,547.45 seconds on a Threadripper 9000 Pro... Michael.
6) Message boards : Number crunching : 0 new tasks, Rosetta? (Message 97605) Posted 25 Jun 2020 by Michael H.W. Weber Post: Far from being increasingly unreliable the project has worked wonders keeping the flow going as well as it has. I beg to differ. I can't see a wonder in having no WUs in the field of computational chemistry where it is known that the scientific problems awaiting solutions are larger than what could ever be achieved in a lifetime - even with the entire's planet compute power running 24/7 on these. Michael. P.S.: At least, the issue of the order of deadlines of WUs handed out to the client machines appears to be resolved now - which is VERY good.
7) Message boards : Number crunching : 0 new tasks, Rosetta? (Message 97596) Posted 25 Jun 2020 by Michael H.W. Weber Post: My machines are idle since days. No need for compute power anymore? Unfortunately, regarding fluent delivery of work this project has become increasingly unreliable, lately. Michael.
8) Message boards : Number crunching : Large proteins (Message 95049) Posted 21 Apr 2020 by Michael H.W. Weber Post: Just a short note on large RAM requiring tasks: I consider it mandatory that in order to distribute such tasks there needs to be a new, separate RAM threshold setting in the project's preference section that requires manual activiation before such tasks are going to be send to the corresponding machines. While it appears to work that systems not meeting the PHYSICAL RAM requirements of a project do indeed not get such tasks, it is similarly known that the determination of REMAINING RAM (while other tasks are already progressing) lacks reliability in the BOINC ecosystem (to say the least). A lot of people run BOINC on unattended machines and are not checking these for days or even weeks and I am not sure whether to date a majority of these even has (the small) amount of 16 GB of RAM. You may say "there will be only few of these". I am sure, I will get them all at once on the same machine. ;-) Michael. P.S.: Rosetta already has an EXTREMELY annoying issue with RAM management due to the sending of new WUs with deadlines dating BEFORE those of RAH tasks already running on the same system: the tasks in progress go on hold and the newly loaded ones bloat the RAM.
9) Message boards : Number crunching : Please bring deadlines of sent tasks to order, server-wise (Message 93955) Posted 9 Apr 2020 by Michael H.W. Weber Post: What happens since years with Rosetta@home and what is absolutely unacceptable is that Rosetta servers ROUTINELY send out tasks with shorter deadlines than those already running on the same machines. As a result, the tasks already being worked on are COLLECTIVELY put on hold and the new ones are loaded into RAM to be processed. This not only might lead to RAM issues but causes massive fails in meeting the deadlines. This is especially a problem since with COVID19 you have more and more tasks which require 1.5 days of full computation. But there are many machines which do not run 24/7 including laptops and then there is only a 3 days deadline as demonstrated in this example. Please correct this problem ASAP - it is easy: Just never hand out tasks with a deadline shorter than that of the previously handed out WU and the problem is solved. Michael.
10) Message boards : Number crunching : Valid WUs not meeting deadline are flagged incorrectly (Message 93953) Posted 9 Apr 2020 by Michael H.W. Weber Post: When checking my returned tasks today, I found two which were flagged as "Berechnungsfehler", meaning "computation invalid". However, that is not the case as follows: When looking into the details, both tasks were validated against an Apple Darwin machine which generated a faulty result, too. So how can something be validated against something faulty? Checking the sending date of the tasks, the deadline and the return time it quickly appeared that my tasks were simply returned to the server too late. This by the way is no wonder when tasks requiring 1.5 days for completion are given a deadline of only three days on machines which do not run 24/7 and where newly loaded tasks are having a deadline that is SHORTER than tasks already running (which means that BOINC switches tasks). You should re-validate these tasks and make sure that future error classification is working correctly. I actually suspect a general issue with validation between Windows 10 x64 Intel machines and the Apple stuff. Michael. P.S.: Another two of my tasks will forseeably not meet the deadline on this same Alienware laptop of mine. I will let them run and you should consider implementing a grace period of a few days for tasks NOT returned within the deadline. Many distributed computing projects have implemented this including our own (Yoyo@home, RNA World).
11) Message boards : Rosetta@home Science : Rosetta@home no longer mentioned in papers? (Message 81254) Posted 2 Mar 2017 by Michael H.W. Weber Post: OK. Good to hear that, at least in 2017, this practice of properly acknowledging scientific contributions has been resumed. To the best of my knowledge, according to international science journal standards, any publication which does not acknowledge the Rosetta@home DC community although results from that community's efforts were used for that particular scientific work, would require the writing of an appropriate corrigendum. David Bakers Rosetta@home undoubtedly is one of the top-notch DC projects in the world. Therefore, it serves a key example for what is possible with scientific computing on a volunteer community basis. If that community is not mentioned, however, nobody will ever know about its wonderful possibilities and interest might soon fade away. Michael.
12) Message boards : Rosetta@home Science : Rosetta@home no longer mentioned in papers? (Message 81235) Posted 26 Feb 2017 by Michael H.W. Weber Post: Taking a look at the scientific publications, it appeared to me that, since a while, the Rosetta@home distributed computing community is no longer acknowledged in the papers. Did I overlook something here? Michael.
13) Message boards : Number crunching : Minirosetta 3.73-3.78 (Message 79555) Posted 16 Feb 2016 by Michael H.W. Weber Post: On my systems and those of other team members, all WUs carrying the phrase "backrub" are breaking down with computation errors. Often after having consumed quite some CPU time. @Baker Lab: Please take a look at this WU series. Thanks. Michael.
14) Message boards : Rosetta@home Science : Top predictions hall of fame (Message 79278) Posted 22 Dec 2015 by Michael H.W. Weber Post: The 'hall of fame' for Rosetta@home top predictions apparently ends in 2007: https://boinc.bakerlab.org/rosetta/rah_top_predictions.php When is it going to be updated? Michael.
15) Message boards : Rosetta@home Science : DISCUSSION of Rosetta@home Journal (5) (Message 79277) Posted 22 Dec 2015 by Michael H.W. Weber Post: Is David Baker's Rosetta@home Journal continued at all? The last post is more than a year old. Michael.
16) Message boards : Number crunching : Granted Credit taking forever.... (Message 63361) Posted 15 Sep 2009 by Michael H.W. Weber Post: Could someone please check these issues: (1) No credits - for what reason? Seems I am the only one who reported this WU: http://boinc.bakerlab.org/rosetta/workunit.php?wuid=255385811 (2) A number of validate errors: http://boinc.bakerlab.org/rosetta/workunit.php?wuid=255112983 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=255132989 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=255098797 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=255085551 Where are the data I sent to the server? Michael.
17) Message boards : Number crunching : Granted Credit taking forever.... (Message 63358) Posted 15 Sep 2009 by Michael H.W. Weber Post: Just to say it clearly once more. It is not about the credits why I posted above. It is a new machine I have set up a few days ago and I was wondering whether something is wrong with it or with the Rosetta@home servers. Michael.
18) Message boards : Number crunching : Granted Credit taking forever.... (Message 63312) Posted 13 Sep 2009 by Michael H.W. Weber Post: Hello all, The Wu's with validate state: Workunit error - check skipped; now have credit granted. Claimed credit = Granted credit. ... Path7. Not for me. I hooked up my new AMD 955 BE (4x 3,2 Ghz) to Rosetta@home on 9th of September. Since that time, I have returned 220 WUs, the machine is processing 24/7 for your project. So far, only 18 (!!!) jobs have been handled by the server - the rest is set to "pending". For an additional 4 jobs, credit was set to ZERO for no obvious reason. Those 4 tasks are: http://boinc.bakerlab.org/rosetta/result.php?resultid=279920775 http://boinc.bakerlab.org/rosetta/result.php?resultid=279914807 http://boinc.bakerlab.org/rosetta/result.php?resultid=279861161 http://boinc.bakerlab.org/rosetta/result.php?resultid=279861159 None of these was cancelled on my side. I would really like to know what is going on here. I was wondering whether it might have something to do with the operating system which I use (it is Win XP Pro x64)? Are there more strict homogenous redundancy validation checks enabled such that these WUs are only validated correctly when processed by another 64 bit Win XP? That might cause significant slow down during the validation process. If you cannot solve this problem quickly, please let me know ASAP because in that case I will have to move my systems to a more productive project due to limited electricity funds. Unlike other DC projects you have RALPH as a good testing environment to make sure no such problems occur in the productive Rosetta@home environment. In the future, please make better use of that. If you do not have enough processing power with RALPH, please also let me know such that I can put some systems on that project (then at least I know I have to expect issues). Michael.