while crunching the result named FRA_2rio_CASP7_hom001_1_2rio_1_1a06__IGNORE_THE_REST_232_1281_3_0, when i showed the graphics, the rosetta application stopped responding
the version was 5.32 on a windows system

each thread (science and graphics) each took up all the cycles on 2 of my CPUs (i have a multiCPU machine)

stopping/exiting boinc closed the app without a problem, and it was working again when boinc was restarted

it was working fine before i viewed the graphics too, no problems at all since 5.32 was released

I was gonna mention 2rio is a very large protein and uses a lot of meory, but that is clearly not a problem for your computer:-) Some users have reported similiar problem before, and we hope we can reproduce it reliably on our local computers in order to debug.

My run-time pref was "not selected" and I noticed the first of my latest batch of Ralph wu's put in 5 hrs with, it claimed, about 3 to go. I just changed my pref to 2 hours and it finished, as I'd expect given the desciptions of behavior when changing the prefs mid-wu.

I read somewhere that Rosetta will use 8 hours for the default, so my question is are the tests set for production defaults now, else what happened to the 1 hr test default?

holding down the left-mouse-button and moving the mouse around you can rotate the 3D "native" protein and with the right-mouse-button held down and moving, you can zoom-in-out.

And with middle mousebutton or mousewheel pressed you can move it around (even out of the borders)

If so, then are the people getting the "1% bug" ever getting past model 1?

This is the correct scenario, and you're right, I don't know how to trigger BOINC to issue a message like that either. Could be a client side bug, or even server side.

Well, even if the message board never displayed a change in prefs, my host #66 is now taking two hours to do a wu. I even rechecked the log and it's NOT there. At no time from when I change the website until it actually crunched the WU did the messages tab display that an updated pref was found.

Have I understood this discussion correctly? If I download WUs as before they will run a prediction and then end after a varaiable amount of time and return the results.

If I set the CPU run time preference it will run sufficient predictions on the same WU to process up to that amount of time (Einstein runs different calculations on the same data, but does not have a time limit)

If so what happens to the partial result? I.e. if I set it to 2 hours then I assume the work that is cut off at 2 hours will only be a partial result. Is this prediction ignored?

I.e. should we all set such a CPU limit?

just noticed the native structure rotates around its center now and does not look flat when you rotate it away from its default view anymore, you can even zoom now, nice work. (was working like that with my last 2 WUs, now i got none left anymore too :/)

Another screensaver issue for the to-do list:
If the screen is an odd shape the graphic is in the upper left corner rather than centered in the available space.

when you say odd shape do you mean unusual resolutions?

some examples if you would be so kind :)

I also have this question. What do you mean by odd shape? Most screens are either 4:5 or 16:9 aspect ratio. Is yours different?

Another screensaver issue for the to-do list:
If the screen is an odd shape the graphic is in the upper left corner rather than centered in the available space.

well, i assume that people who want each workunit to run for a long time, will only get workunits that would have otherwise been short.

also if they need more results for a structure, then they'll issue more workunits, if there's enough, then they'll stop issueing WUs for that sturcture

this is only a guess, and i could be completely wrong
but in a project such as this (or any really), having more results is always good

We are going to update the code to remove the 99 limit. For most work units 99 would take too long. We would prefer lower run times so that results are returned quicker.

Well, the only problem I am seeing with this, is the accurracy of the 1 hour workunits, versus the 8 hour workunits.

Surely this isn't my issue as a LOWLY tester :) , but it helps to understand the under-workings of it all. Here's how I currently understand it :

Workunit [insert workunit name].001 gets sent out to (hypothetically) 5 people.

User 1 processes it for an hour, and returns 6 structures.
User 2 processes it for 2 hours, and returns 15 structures.
User 3 goes for 4 hours and returns 45 structures.
User 4 does the full 8 hours, and returns the max of 99 structures, but ends early at 7 hours 30 minutes.

(again, hypothetical figures)
#1 claims 60 credit
#2 claims 120 credit
#3 claims 480 credit
#4 claims 900 credit

so... then you've got 4 seperate results for 1 workunit? How is credit canonical for User #3, or 4?

Assuming even if selecting your processing time preference will limit you to workunits that are only sent to like-setting machines, (I.E. once a workunit gets tagged as 4 hour processing times, only people with this preference can d/l them.. etc) Then at what point does the extra time become redundant?

Uhm.. ok.. first :) I just got here.. but I'm also not a -complete- idiot..

However, I must now seem like one, because I was hoping you could explain this in much more detail, and explain some of the effects of doing such with various workunits, and what we should expect credit-wise, science-wise.. etc..