Posts by kevin

Message boards : Number crunching : Bug Report - Random Reboots

( Message 5313 )
Posted 2919 days ago by

There seem to be some bug(s) that may be causing my computer to randomly reboot.

This is the situation:

I have been running S@H on my Q6600 for about a year. During this time I have not seen any random reboots.

Recently, I upgraded the NVidia video driver in order to support the optimized CUDA app from S@H.

Subsequently, I started to notice some occasional random reboots about 3-4 times per week.

I decided that it was probably some issue with the new NVidia video driver, but was not bothered enough by it to do something about it yet.

Then, for reasons having to do with improving the through-put of this computer by letting it use mostly optimized apps, I set D@H to "No new Tasks" on this computer.

Eventually, it ran out of D@H tasks to do and was running only S@H for a several days.

Today I temporarily set D@H to allow new tasks, so that there would be a few in the queue for the times when S@H is having problems servicing their client computers.

I got 6 D@H tasks, and 3 of them started running immediately.

The computer immediately had another random reboot, which I had not seen while there were no D@H tasks to be run.

Now I have set D@H to "No new Tasks" once again, and suspended those tasks that were downloaded.

We shall see if there are any more random reboots while D@H is not running.

I wonder if there are any switches that I can set that will cause the D@H apps to write more debugging info to the log so that the cause of the random reboots can be determined.

This is very odd. We haven't seen behaviour like this before, and would be interested to know if you can indeed find a direct correlation to our project and the reboots. Please keep us updated on your testing.

Message boards : Docking@Home Science : Error - No Work Available

( Message 5312 )
Posted 2919 days ago by

kevin

I am receiving NO WORK. My processor is idle, and nothing is being sent to me. It is happening on only 1 out of 3 computers I am using. Can anyone suggest what I should/can do?

You should first try resetting the project. If that doesn't work, detach and then reattach to the project. Let us know if this helps.

Kevin

Message boards : Windows : Crash in Show Graphics... Debug Assertion Failed dbddel.cpp line 52

( Message 5293 )
Posted 2925 days ago by

kevin

hey mike, did your client update to the newest version that we released yesterday? i was wondering if the graphics are working for you in this build. i've tested on vista x64 with an ati card and it works great for me. let me know if you have any problems.

Message boards : Windows : Crash in Show Graphics... Debug Assertion Failed dbddel.cpp line 52

( Message 5265 )
Posted 2929 days ago by

kevin

this is a very odd occurance. we've been running this version of the screensaver for quite some time without issue. my advice to you would be to reset the project, to see if you can force it to redownload the executable and then try running it again. if that doesn't work, then I'll also say that we are releasing a new version very soon, which will hopefully fix your issue as well as others small bugs. also, if you are overclocking your ram you might have problems, so trying everything at stock voltages and frequencies may also help you out. we'll let everyone know when the new version is out and we'd love to hear if it solves your problem. honestly I have a very similar setup to your own and it the screensaver works fine for me.

one other far fetched possiblity is that you are running out of ram. if the code is allocating memory and you don't have any, and then it goes to access that unallocated memory you'll get an error like this. this isn't likely to be the problem but you can check to see how much ram is used in the taskmgr.

kevin

Message boards : Docking@Home Science : Why are the ligands INSIDE the protein?

( Message 5080 )
Posted 2980 days ago by

kevin

So as I've written above, I was going to look into this bug to figure out where the problem was. I'm writing today to confirm that my initial assumption is correct. That is, the simulation's results ARE CORRECT, the graphical portion of the application simply renders them at the incorrect position. The screensaver code calculates a center of geometry and then uses this to shift the molecules to the viewable part of the screen. Unfortunately after that point the molecule (as a set of atoms) is moved around by this calculated offset. What the screensaver needs to do is treat each atom individually, or better yet, calculate the COG of the complex (the ligand docked into the protein), treating the whole structure as one entity. The latter is the solution that I will work in implementing.

So how did I prove that this was infact the problem? Well I've been working on another program which also works with displaying proteins and ligands. So I took the OP's workunit, and regenerated it using the 1t7k complex with the same random seed the OP had. As the OP had shown, this generated what looked like steric clashes in the complex (in the graphical application). So I took the generated ligand and protein description files, which were used in the graphical app, and I loaded them into my own application. Below I show an image comparing both. Notice that the original graphical application (right) shows a gaping docking pocket with the ligand clashing inside the protein. On the left, you can see my graphical application shows that, using the same files, the ligand nestles into the docking pocket where it should be.

So once again, I'll be working on correcting this bug in our google code repository using the method described above. The scientific code has been verified as correct so users shouldn't worry wasting computation on invalid results. Just be aware that there is a benign shifting bug in the graphical application. I'd also like to thank our vigilant users, particularly the OP anthonmg. We'll keep you posted on the fix. Thanks again for all your help.

Message boards : Docking@Home Science : Why are the ligands INSIDE the protein?

( Message 5062 )
Posted 2988 days ago by

kevin

We may have stumbled onto an explination for this behavior. I did some work on the screensaver and I am currently working on a project that is closely related to (works in conjunction with) it. At any rate while coding my own graphical application using the data files which represent the ligand protein structures I noticed that the world coordinates given (for the atoms) are not centered about the world origin. For example, the 1tng ligand is pretty close to the origin although slightly tilted away from it. The 1ohr ligand is shifted about 5 whole units away from the origin.

So, why is this a problem, you may ask. Well in opengl, there is of course a world coordinate space, however it's nice to group certian pieces of geometry together (atoms and bonds for instance) into their own local coordinate space. That way when you perform a translation or rotation all of these objects (atoms and bonds) move together as if they are attached. The problem is, that if you load all of the objects into their own coordinate space, and they aren't centered around the origin, but are in fact offset, then where ever you translate them to, they will be just as offset as they were before you moved them.

It's like the solar system. The solar system moves through space right, but the planets still stay offset from the sun (the origin of our solar system's local coordinate system). But to the programmer, we only have control of moving that center point, we can tell the sun where to move, but the planets will just follow it. So you can immagine that if we think the ligand is close to it's origin but it's really offset, it might look offset from where we calculated it should be.

At any rate, I will personally look into this problem. We have looked at results from the docking algorithm and have shown that the results are valid. Specifically we've loaded the world coordinate positions of the atoms of the ligand and protein and confirmed that the results of the algorithm are correct (ligand docked in the correct pocket). I am confident that there is a graphical bug related to above mentioned phenomenon. I'll be looking into providing a fix for this in the near future.

Rest assured that the bug that you are seeing is purely cosmetic and in no way relects the quality of the computation being performed. Sorry for the inconvenience.

Message boards : Number crunching : Work Units That Never Want To End

( Message 4990 )
Posted 3019 days ago by

kevin

Yes my 1hsgs did complete once they got over the hump of showing no progress for a while. I've finished both those I was concerned about. Just needed to be patient and wait a little longer. It takes my old Pentium 4 3GHz a good deal more time to complete than you mention so maybe it feels the increase a bit more than the more current CPUs.

your logic seems right. for example, i'm running a core2duo 3.0ghz with 4gigs of ram. the newest complex, the 1htf, is taking me about 3 hours to complete. hang in there on those long tasks. :o)

Message boards : Unix/Linux : Ubuntu & Graphics.

( Message 4571 )
Posted 3199 days ago by

kevin

Hi all.

Just a question, are the graphics suppose to work

because they don't on mine. The button in the manager

is usable but does nothing.

pete.

So the first question is, what type of graphics card are you using and what version of ubuntu are you using. I can tell you that I encountered the exact same problem on ubuntu 8.10 x64 using an nvidia graphics card. The problem is that the graphics program needs to find the 32 bit static opengl libraries (libgl.so.1 i think). Anyway I was able to fix this by installing the graphics drivers from nvidia's website. Actually the first time I installed them they still didn't work because they were complaining about not being able to replace the opengl files, but the installer does ask to put 32 bit opengl libraries on the computer.

Basically you need to download the installer script from nvidia. You need to drop to shell with ctrl-alt-f3. Then you need to stop gdm by doing /etc/init.d/gdm stop. Then you need to do sh nvidia_graphics_driver.sh. Say yes to all the options. If it complains about a problem and assuming a successful install with the opengl 32bit libraries then run the installer again and it shouldn't complain. Once the installer updates the xorg.conf you can restart gdm by /etc/init.d/gdm start.

Once I did that I was able to get the graphics working on ubuntu x64. Good luck.

Kevin

Message boards : Cafe Docking : Great screen saver

( Message 4413 )
Posted 3241 days ago by

kevin

I also attached to this project for the first time. I am interested in crunching my second biology/medical distributed computing project.

The website design is fabulous! I consider this to be one of the best of all BOINC projects.

I am amazed at the wonderful screensaver! I did not expect this alpha project to have such a great screensaver. I noticed that the movement of the graphics is slow and not smooth. Is that normal for the screensaver?

First of all thank you both for the compliments on the screen saver! We really appreciate it when the users compliment our work. Secondly, the "unsmoothness" of the graphics can be explained in a few ways. The screen saver is written using opengl. In both opengl and directx there are vertex rendering accelleration structures (display lists and vertex buffers respectively). In the current version of the screen saver display lists remain unimplemented, however after added them the speedup should be sufficient to make the movement smooth. Hopefully we can get this in there sooner than later plus a few other little pieces I'm in the process of adding to it.

Thanks again for the support!

10)

Message boards : Number crunching : Screensaver

( Message 4270 )
Posted 3282 days ago by

kevin

I can see, rotate and zoom the protein, ligand and complex on Vista, XP and SuSE 10.2 Linux. On all platforms, the resources page shows a slowly filling can denoting percentage completion, but the two X-Y plots under that are blank.

I don't normally run the graphics so do not know if this is correct, or if I need to leave it active for longer.

Yes, this is known behavior. The current strategy for loading the graph and the percent progress bar come from a single file which is updated every so often called percentdone.txt. The problem with this is that it doesn't contain a history of the status and only has the last value. So the Min Energy and RMSD shown in the graph are only the current ones found in the file. Since there is only one value no line can be drawn and you won't see anything in the graph.

Right now we're looking into a way to make this look a little nicer. I'll keep you posted.

Kevin

Next 10 posts