Posts by dgnuff

1) Message boards : Number crunching : Remaining time for tasks is incorrect (Message 94047) Posted 10 Apr 2020 by dgnuff Post: Yeah, I suspect that's what happened. I finally reset the project, and straightaway, it started showing 24 hours for the expected run times, and downloading an appropriate number of WU. Glad to have it all sorted out now. Onward, with crunching for Rosetta and COVID-19.
2) Message boards : Number crunching : Remaining time for tasks is incorrect (Message 93937) Posted 9 Apr 2020 by dgnuff Post: I have my project preferences set to run tasks for 24 hours, in an attempt to reduce the load on the servers. WU do generally run for the full 24 hours, but just after they've been downloaded, the remaining time shows as a much shorter time: I have some showing as low as 2H 22M. The problem this leads to is that the scheduler WAY overcommits and downloads far more WU tghan I can actually get done. Tis leads to either missed deadlines, or me having abort significan't numbers of tasks. Any suggestions for how I can fix this? Taking it to Boinc's website is an option, but I figured I'd ask here first, since it is a Rosetta specific setting not being respected that's at the heart of the problem. TIA for any help.
3) Message boards : Number crunching : GPU WU's (Message 93365) Posted 4 Apr 2020 by dgnuff Post: Here's a very different argument to try and explain why Rosetta doesn't have GPU WU. To quote Spock from the original Star Trek show: "You're proceeding from a false assumption." That assumption is that any program can be converted to run on a GPU and will go faster if that happens. OK, lets assume that's correct. If it were, Intel and AMD would go out of business tomorrow, because we wouldn't need them any more. We'd just stop using conventional CPUs and run everything on the GPU instead: OS, Browser, the whole lot. But we don't do that, do we. Why not? Because there are some things that GPUs just don't do well at. Read this Q & A from the Computer Science Stack Exchange website: https://cs.stackexchange.com/questions/121080/what-are-gpus-bad-at It does a really really good job of explaining what GPUs are good at, and what they are bad at. And it just so happens that while Seti, Folding and others can be made efficient on a GPU, Rosetta can't. So next time you're asking why Rosetta isn't on your GPU, ask yourself why your browser doesn't run on your GPU. The answer to both those questions is about the same.
4) Message boards : Rosetta@home Science : New paper in Science Magazine argues that computational models are worsening (Message 81061) Posted 18 Jan 2017 by dgnuff Post: The counterpoint to this is the consistently good results that Rosetta achieves in CASP. Since some of the CASP targets have been solved by methods such as X-ray crystallography, this means that they are correct, in the sense that they represent the true structure of the protein. It then follows from this that if a "simulation" such as Rosetta is able to match the real structure accurately, it implies that it is not subject to the inaccuracies cited in those two articles.
5) Message boards : Rosetta@home Science : MAJOR UPDATES to the Rosetta@home website (Message 80877) Posted 29 Nov 2016 by dgnuff Post: I definitely like the new look that's planned here, but I do have one suggestion to make. Keep contrast in mind when choosing your color scheme. In particular, you have a medium blue background for text on the various pages. In order to keep the text readable, it needs to be light in color; the white and powder blue being used work very well. However at the bottom of the FAQ page there are a couple of items in a dark gray color. My eyesight is not as good as all that, not at my age, and for me these items are almost unreadable against the blue background. If you want to draw attention to these, keep them light in color, but alter the hue, so making them either pale green or yellow would get you where you want to be.
6) Message boards : Number crunching : Only using 3 out of 4 available cores. (Message 75565) Posted 4 May 2013 by dgnuff Post: Weird. No idea at all. I used Process Explorer to kill boinc and its children, and then restarted from the shortcut in programsstartup. All 4 cores are now active.
7) Message boards : Number crunching : Only using 3 out of 4 available cores. (Message 75564) Posted 4 May 2013 by dgnuff Post: This system of mine: http://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=1088056 is a quad core Intel Q8200. I was checking on it this morning, and found that it's only running three Rosetta processes, and nothing else. Meaning one core is idle. I've checked the local preferences here which say to use at most 16 cores, and I've set the local preferences to use 100% of the CPU. Any ideas?
8) Message boards : Number crunching : Dragging my machine down (Message 70990) Posted 9 Aug 2011 by dgnuff Post: I'd have to agree with the OP, Rosetta is getting to be more and more of a load on my system. The following screen cap from Sysinternals Process Explorer shows clearly what the problem is: http://imageshack.us/photo/my-images/828/boinc.png/ Take note of the Virtual size, CPU time, Page fault total and Page fault delta. I'm seeing about 10,000 page faults PER SECOND from Rosetta, i.e. it's thrashng. If I ran all six cores of this system, that'd be something in the region of 60,000 page faults per second. Note how the virtual size is north of 500 megs, that's a lot of the cause of the problem: Rosetta is getting to be too much of a memory hog, to the point that only really high end systems can run it without noticing the load. TL;DR you guys need to reduce the memory footprint back to what it was a year or two ago, i.e. no bigger than 300 to 400 megs. Minirosetta isn't so mini any more.
9) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 70879) Posted 3 Aug 2011 by dgnuff Post: Wanders in, pokes the Bakerlab people in the hope of getting an official comment on this, and wanders out again. I'm hit as hard as others, maybe worse. I reset Rosetta on three of my systems in response to a comment on the BOINC console that recommended doing so. Something to do with an error that I now don't remember, but it explicitly said to reset if the error happens a lot. Which it was. So I've got three machines that are dead in the water atm. I know that the BOINC devs themselves (i.e. the folks at Berkeley) don't read these boards, but you know what I'd like to see in the project scheduling / priority section, is an option like this. Get WU for project X 100% of the time, unless project X has no work, in which case get WU for project Y, but only until Project X comes back. That way I could set Rosetta to be there 100% of the time when it's up, but fall back gracefully to something else if I have to cover an outage. I used to try this by setting Rosetta to 99% and something else to 1%, but that wide disparity in work percentages appeared to cook the mind of the scheduler, and it really didn't work the way I wanted.
10) Message boards : Number crunching : Too slow to run? (Message 70739) Posted 18 Jul 2011 by dgnuff Post: Now I have a new problem. My computer locks up after I let it sit for a while and the Screen saver comes on. Isn't, the screensaver coming up, standard behaviour if you don't use your computer? It's the default behavior for an "out of the box" Windows installation. You can, however, disable the screensaver and just turn off the monitor manually, which is what I do. You're running XP on it, just right click on the desktop, select "Properties" from the context menu, select the screensaver tab in the window that pops up, and then select "(None)" from the dropdown list where you choose the screensaver. -- Edit -- And just to confirm what was said, 2GB RAM and 2GB disk should be plenty. I have a bunch of quad core crunchers in my farm, they all run four copies at the same time in 2GB am for the lot - I assume 500 megs / core is enough, and it seems to work fine. Looking at my current desktop box that I'm typing this on, it's a hex core AMD, I've given 2GB to Boinc which is only running Rosetta, and it's filled about 910 MB of the available space. Bottom line, you ought to be just fine on that system.
11) Message boards : Number crunching : Minirosetta 3.14 (Message 70726) Posted 15 Jul 2011 by dgnuff Post: Like several people in here, I'm getting the occasional hang with the new 3.14 client. Hopefully I'll be able to come back and edit this to add further crashed WU's, since I get about one a day from the farm I have here. To get things started ... ilv_fgf2_all_boinc_1n4kA_124.nonlocal.pctid_0.19.tmscore_0.62808._nonlocal_tex_IGNORE_THE_REST_27534_15684_0 -- Edit -- missed a period in the WU name.
12) Message boards : Rosetta@home Science : WiFi and Cellphone radiation effects (Message 70468) Posted 31 May 2011 by dgnuff Post: But since some serious size of administration begins to act on "right" side the fallacy accuser campaign need to develop better ways to stay alive. Yet another fallacy here. Argument from authority. http://en.wikipedia.org/wiki/Argument_from_authority You cited that article from Europe, however it ends with the following quote: Fears have been raised that electromagnetic radiation emitted by wireless devices can cause cancers and affect the developing brain. The findings were seized on by campaigners who oppose the spread of wireless devices. Fears being raised do not constitute proof. If there was something in that article that stated that "Scientists have proven that radiation causes autism and cancer", then you'd have something. The fact that a large number of campaigners and lawmakers agree with this proves nothing, because these people are not experts in the field. This is nothing more than a perfect example of the argument from authority fallacy. A is an authority. True, these lawmakers do speak with authority in certain matters. A says B is true. This is also happening, since they are pushing for this legislation. Thus the fallacious conclusion that B must be true. Show a web page that actually proves something. Without that, you have nothing. -- Edit -- In addition, that article cites the following page: http://www.who.int/mediacentre/factsheets/fs304/en/index.html Which includes the following: In fact, due to their lower frequency, at similar RF exposure levels, the body absorbs up to five times more of the signal from FM radio and television than from base stations. This is because the frequencies used in FM radio (around 100 MHz) and in TV broadcasting (around 300 to 400 MHz) are lower than those employed in mobile telephony (900 MHz and 1800 MHz) and because a person's height makes the body an efficient receiving antenna. Further, radio and television broadcast stations have been in operation for the past 50 or more years without any adverse health consequence being established. Which constitutes some pretty serious scientific evidence debunking the argument against cellphones. What this says in laymans terms is that you ought to be far more worried about FM radio, since your body is a far better antenna for that section of the radio spectrum than the extremely short wavelengths used by cellphones and microwaves.
13) Message boards : Rosetta@home Science : WiFi and Cellphone radiation effects (Message 70401) Posted 27 May 2011 by dgnuff Post: In the absence of a firm scientific proof that cellphones cause Autism, the argument being made here is a fallacy. In particular, if you visit Wikipedia's page that lists various types of fallacies: http://en.wikipedia.org/wiki/List_of_fallacies#Informal_fallacies The seventh bullet item in the list of Informal Fallacies is the entry for "Correlation does not imply causation". That is precisely the fallacy being presented here. Certainly, there may be a correlation between the increase of Autism and the increase in cell phone usage, but that does not, in and of itself, imply any causal relationship.
14) Message boards : Number crunching : When will cuda support be ready ? (Message 70400) Posted 27 May 2011 by dgnuff Post: I believe the answer is that is has been looked at and the current spec of GPU's does not make it worthwhile. In short there is no advantage to using a GPU due to its limitations. I am sure when those limitations are surpassed the GPU will again be considered as a resource to be exploited. The devil is always in the details and the reason we have a cpu and a gpu is because they each do things differently. The cpu can be very precise while the gpu does not have to be, while Scientific Research MUST be very precise at times. I used my GTX 295 on the FAH Project at Stanford for a while, and it greatly outperformed my two CPUs. All four processors would be running simultaneously, and the video card would finish its work units much more rapidly than the two CPUs. Perhaps they were smaller WUs, but my scores started to increase at a much higher rate, so the contribution must have been significant. If GPUs can be made useful and valuable by FAH at Stanford, why can't it be made usable and valuable by Rosetta? Aren't both projects studying proteins? deesy I can't talk about the GPU port of FAH, but as it happens, I worked in Sony's R&D department at the time a team there ported FAH to run on the Cell processor in the PS3. Their first run at it was simply dividing up the workload among the SPU's, "Throwing a compiler switch" (as others have put it) and trying it out. The PC version when ported in this manner to the SPU's, ran at about ONE TENTH the speed it did on a PC. The team sat down, looked at what was going on, and realized that the PC version was a complete waste of time on the SPU's. The reason for this was that, very briefly, FAH computes forces between adjacent atoms, and did a huge amount of filtering to remove computations if the atoms were too far apart. This filtering simply crippled the program when running on the SPU's. So the team took a rather simpler approach. They looked at the workload, and decided to compute the force for every pair of atoms, filtering be damned. They then very carefully figured out how to divide this workload up between the SPUs to maximize the throughput they could get, and thus was created the version you now see running on PS3's. Which is about ten times FASTER than the PC version was at that time. Overall this rearchitecture of the program resulted in about a hundredfold throughput of the program on the Cell, but trying to run the PS3 version on a PC would probably have caused a massive slowdown - remember how the PC version filters to be able to get things done in a reasonable timeframe? Do you now understand why this is not a trivial problem? Some projects (Seti for example) lend themselves very well to SPU / GPU architectures because AFAIK, Seti isn't doing much more than a boat load of FFT's on the data, an operation that lends itself extremely well to a GPU type system. RAH is a whole different can of worms, I don't know for certain, but I'd guess it's somewhat similar to FAH, meaning that without a total rearchitect and rewrite of the program, it's going to run so slowly on a GPU as to be worthless. Please people, don't assume this is easy - my comments above about FAH should illustrate that it's anything but easy. If you can find a skilled team of GPU engineers with three or four months to burn, then by all means, have a go at porting the problem. Otherwise don't tell people that it should be easy, because you really don't know what you're talking about.
15) Message boards : Number crunching : minirosetta 2.14 (Message 66153) Posted 16 May 2010 by dgnuff Post: There's also another aside with increasing complexity on a task, which depending on people's machines might/might not effect them. The bigger the dataset, the more complex something is, the more RAM it can use. The current task I'm working on is using 511 MB of RAM to itself. Unless it gets to the point where the processes start thrashing, this isn't much of an issue. Modern OS's have very effective virtual memory systems which simply page out less used portions of the working set to disk. Looking at the four rosetta tasks running on my system now, they all have a virtual size on the 400 to 450 mb range. However they all only have a working set size in the 250 mb to 300 mb range, and hardly any page faults happening. Therefore Windows is doing a first class job of figuring which parts of the process aren't immediately necessary this instant, and paging them out. And I suspect that as the workload on my system increases, the working set size of Rosetta task will decrease.
16) Message boards : Cafe Rosetta : Where is everyone (Message 63730) Posted 17 Oct 2009 by dgnuff Post: Hi there! Nice to see a yet another soul interested in actual scientific progress of this great, shared effort we call Rosetta@Home (and BOINC, and distributed computing in general). Happy Crunching Everyone, and keep pushing for the science! :) There was a study done and it found that less than 10% of the people that crunch use the forums! I think that is just terrible, people crunch and miss the sense of community involved in that crunching. The same problem exists in other areas. I play an MMO, and it's been noted time and time again by the community managers for that game that only about 10% of the active playerbase are even registered on the forums. Some people just don't do the forum thing, I guess.
17) Message boards : Rosetta@home Science : DISCUSSION of Rosetta@home Journal (4) (Message 63431) Posted 23 Sep 2009 by dgnuff Post: Without any knowledge of previous headings on Twitter, I'm going to suggest the following: "Fine tuning Rosetta's energy function"
18) Message boards : Number crunching : Discussion on increasing the default run time (Message 63073) Posted 29 Aug 2009 by dgnuff Post: Snip ... In another thread, I suggested increasing the maximum number of decoys from 100 to something higher, but that idea was rejected. I still find the reason for staying with the 100 decoy max totally counter-intuitive, and in fact I'm not at all sure the reasoning given is correct. That said, I'll make the suggestion again to increase the max decoys to 200 (or even higher), and see where the suggestion goes. For those of us with fast machines, willing to do long run times it will reduce the load on the servers. I admit it will change the "shape" of the uploaded data, but it will not change the amount - this last point is the one where I think people haven't thought the problem through correctly. "Maximum number of decoys" at 99 was introduced some months ago when Rosetta@home was in "debug mode" (I think around v1.50, no new features only bugs solved). It was used as the easy way to solve some bugs that arose with large uploads (if I remember correctly, they didn't even investigate if the problem was in BOINC or somewhere in their code, because this trick solved easily the bug). I don't think that, atm, it's so important to solve drastically this problem; anyway, it should be interesting to know if they have any problem with server load now... Interesting. If anyone is looking for fairly reliable repro steps on getting uploads to fail, try the following. Set up a machine, and adjust the maximum upload rate to 2 kbytes/sec on the advanced preferences page. Grab yourself a task like this one: 276073593 let it complete, and then try to upload it. The key section of the name appears to be the "ddg_predictions" string. I've seen a few of these guys going by, they seem to produce very large result files. I've had two that are in excess of 7 Mb and one that was over 11 Mb. It's worth noting that if I temporarily adjust the upload speed to something over my connection's max (384 kbits/sec, i.e. ~ 40 kbytes/sec), the transfer will then go through without problems. However it's a bit of a pain doing this, I'm about to the point that if I find another of these WU that's stuck uploading, I'm going to force that upload through, and then abort any of these jobs that I see in the queue.
19) Message boards : Number crunching : Discussion on increasing the default run time (Message 63069) Posted 28 Aug 2009 by dgnuff Post: I have noticed that on my faster machine, the limit of 99 decoys is usually reached before the 12-hour expected runtime I've requested. You might want to check the report visible on the Rosetta@home of how well the workunit succeeded to see if your workunits also often stop at the 99 decoys limit instead of near the requested run time. The workunits ending before the selected run-time get to a stop at 100 decoys, whereas the one recent workunit which made it to the selected 16 hours stopped at 88 decoys. Is there anything I can do to adjust this or is it a lucky-dip? I've noticed this too. As far as I can tell, it's a "lucky-dip" as you so accurately describe it. Also known as a crap-shoot in other parts of the world. ;) In another thread, I suggested increasing the maximum number of decoys from 100 to something higher, but that idea was rejected. I still find the reason for staying with the 100 decoy max totally counter-intuitive, and in fact I'm not at all sure the reasoning given is correct. That said, I'll make the suggestion again to increase the max decoys to 200 (or even higher), and see where the suggestion goes. For those of us with fast machines, willing to do long run times it will reduce the load on the servers. I admit it will change the "shape" of the uploaded data, but it will not change the amount - this last point is the one where I think people haven't thought the problem through correctly.
20) Message boards : Rosetta@home Science : DISCUSSION of Rosetta@home Journal (4) (Message 62989) Posted 21 Aug 2009 by dgnuff Post: Dr. Baker, I read with some interest your post from Aug 15 that talks about molecules binding to proteins. Am I correct in thinking this is exactly the task that Keith Davis was doing with the Find-A-Drug project? The reason i ask is that I was working on F.A.D. prior to coming here to Rosetta, and I'm still interested in finding out whatever I can about the science of that project. I also remember that at the end of the distributed computing portion of F.A.D. Keith Davis explained that we'd pretty much exhausted all combinations of drug / protein interaction possible. He was then planning to take our results and do further research in an effort to identify viable drugs. Presumably this is required because of what you mention in your post where a theoretical bind from a computer simulation doesn't always lead to a good bind in practice.

Next 20