minirosetta v1.55 bug thread

Message boards : RALPH@home bug list : minirosetta v1.55 bug thread

To post messages, you must log in.

Previous · 1 · 2 · 3 · Next

AuthorMessage
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4628 - Posted: 1 Feb 2009, 0:47:02 UTC - in response to Message 4627.  

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x005124B3 write attempt to address 0x3FF00000


Yea! Two of us with the same address!

Maybe it is not random after all .... :)
ID: 4628 · Report as offensive    Reply Quote
Tonno

Send message
Joined: 23 Nov 06
Posts: 16
Credit: 49,841
RAC: 0
Message 4630 - Posted: 1 Feb 2009, 7:45:55 UTC - in response to Message 4628.  

The 1.57 version doesn't show the protein in the searching box.
ID: 4630 · Report as offensive    Reply Quote
Profile cenit

Send message
Joined: 26 Apr 08
Posts: 5
Credit: 25,392
RAC: 0
Message 4632 - Posted: 1 Feb 2009, 9:34:11 UTC - in response to Message 4630.  

The 1.57 version doesn't show the protein in the searching box.

same here
ID: 4632 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4634 - Posted: 1 Feb 2009, 13:38:16 UTC

In this workunit running under 1.56:

https://ralph.bakerlab.org/workunit.php?wuid=1138646

The graphics works, but whenever it switches to the stick figure display, the Low Energy and Native sections of the graphics window get rather dim.

Also, it's a candidate for long-running models - at 4 hours 52 minutes into the requested 6 hours CPU time, it's still on model 2, step 81002, stage MoverBase-Minimization.

I already have some 1.57 workunits in the queue, so when they start, I'll try to check if they give similar results.

ID: 4634 · Report as offensive    Reply Quote
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4635 - Posted: 1 Feb 2009, 14:31:55 UTC

The searching box has the image in OS-x, but not in Windows XP in version 1.57 ... but at least the window comes up ...
ID: 4635 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4636 - Posted: 1 Feb 2009, 14:51:58 UTC - in response to Message 4634.  

In this workunit running under 1.56:

https://ralph.bakerlab.org/workunit.php?wuid=1138646

The graphics works, but whenever it switches to the stick figure display, the Low Energy and Native sections of the graphics window get rather dim.

Also, it's a candidate for long-running models - at 4 hours 52 minutes into the requested 6 hours CPU time, it's still on model 2, step 81002, stage MoverBase-Minimization.

I already have some 1.57 workunits in the queue, so when they start, I'll try to check if they give similar results.



This workunit is now finished, and sucessful. However when shutting down the graphics, I thought I noticed a significant discrepancy between progress reported by the graphics window and progress reported by the BOINC manager for this workunit. The above progress figures are those from the graphics window.
ID: 4636 · Report as offensive    Reply Quote
Aegis Maelstrom

Send message
Joined: 19 Jan 09
Posts: 12
Credit: 4,751
RAC: 0
Message 4637 - Posted: 1 Feb 2009, 16:06:24 UTC - in response to Message 4628.  
Last modified: 1 Feb 2009, 16:10:30 UTC

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x005124B3 write attempt to address 0x3FF00000


Yea! Two of us with the same address!

Maybe it is not random after all .... :)


The same here - lr6_D_score12_rlbn_1bm8_IGNORE_THE_REST_NATIVE_7059_5_1.

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x005124B3 write attempt to address 0x3FF00000


The same as well had Manuel Lupotto above.
Both of us had MiniRosetta ver. 1.56.
ID: 4637 · Report as offensive    Reply Quote
Evan

Send message
Joined: 23 Dec 07
Posts: 75
Credit: 69,584
RAC: 0
Message 4638 - Posted: 1 Feb 2009, 20:04:04 UTC - in response to Message 4632.  

The 1.57 version doesn't show the protein in the searching box.


In addition the Accepted Energy and RMSD graphs take a long time to develop each time you turn on the graphics.
ID: 4638 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4639 - Posted: 1 Feb 2009, 20:16:00 UTC - in response to Message 4636.  

I already have some 1.57 workunits in the queue, so when they start, I'll try to check if they give similar results.


In this workunit, 1.57 under Vista SP1:

https://ralph.bakerlab.org/result.php?resultid=1292982

The graphics works, but whenever it switches to the stick figure display, the Low Energy and Native sections of the graphics window get rather dim. Also, the Searching section is solid black. Already up to model 5, though.

75% complete in the graphics, and in the BOINC manager.

I've switched from 100% CPU time to 98% CPU time to see if that helps test the lock file problem.

HMM... It's still running at 100%. Looks like I'd better check if any of the following are true:

1. I have to leave it set below 100% longer for 1.57 to notice.

2. There's another setting that overrides this.

3. I have to set it even lower, such as 90%, before it will stop rounding the value to 100%.

In case it makes a difference, I tried switching the Rosetta@home setting to 98% first, but it made no difference in the starting value for the Ralph@home setting, so I set that one to 98% also.
ID: 4639 · Report as offensive    Reply Quote
svincent

Send message
Joined: 4 Apr 08
Posts: 34
Credit: 51,768
RAC: 0
Message 4640 - Posted: 1 Feb 2009, 22:33:24 UTC

I'm seeing the same quirk in progress times that robertmiles and others have already reported. I've got a bunch of tasks with names of the form csttest_1_8_nativecst_harm*, all of which, under Mac OS X 10.4.11, are supposed to take 1 hour approximately to complete. What I'm seeing is that, after say 45 minutes, progress is apparently only 15% complete and there is 1:20:00 left. It's stepping very slowly at this point in a stage called MoverBase+Minimization. Nevertheless the tasks complete in about one hour as they're supposed to.

ID: 4640 · Report as offensive    Reply Quote
mtyka
Volunteer moderator
Project developer
Project scientist

Send message
Joined: 19 Mar 08
Posts: 79
Credit: 0
RAC: 0
Message 4641 - Posted: 1 Feb 2009, 23:23:09 UTC - in response to Message 4640.  

I'm seeing the same quirk in progress times that robertmiles and others have already reported. I've got a bunch of tasks with names of the form csttest_1_8_nativecst_harm*, all of which, under Mac OS X 10.4.11, are supposed to take 1 hour approximately to complete. What I'm seeing is that, after say 45 minutes, progress is apparently only 15% complete and there is 1:20:00 left. It's stepping very slowly at this point in a stage called MoverBase+Minimization. Nevertheless the tasks complete in about one hour as they're supposed to.



You have to remember that the percentage bar is merely a cosmetic feature - it's not a "real" percentage bar. Its just a really crude estimate of the time left. Now: there is NO way of knowing how long the job will take before you've finished the first decoy .
I've recently changed this estimate to be much more conservative. We estimate it as percentage=100*time_spent/max_time.
where maxtime is USERTIME+4hrs, not USERTIME. because the WU cannot run longer then an excess of 4 hrs over the user time (due to the watchdog).
After the first decoy is completed the program can make a slightly more educated guess about how long it's going to actually take, so the percentages get more accurate as more decoys are produced.
So i'f you're 45 minutes in on the first decoy 15% is about correct. (since your max runtime is 300minutes. 45/300 = 0.15

I'm sorry there's no better way to do this, but rosetta goes through many different stages in making a decyo and its simply impossible to know how long it's going to take.

Mike



ID: 4641 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4643 - Posted: 1 Feb 2009, 23:45:04 UTC - in response to Message 4639.  

I found the World Community Grid Device Profile setting and changed it from 100% CPU time to 98% also; still running at 100%, though. I suspended BOINC for the weekly backup and disk cleanup session:

Back Up Files
Disk Cleanup
Disk Defragmenter
Vista update
reboot

Restarted running BOINC; still running at 100% CPU time.

Waited a few minutes; then got these messages:

2/1/2009 5:05:01 PM|World Community Grid|Task mf189_00038_13 exited with zero status but no 'finished' file
2/1/2009 5:05:01 PM|World Community Grid|If this happens repeatedly you may need to reset the project.
2/1/2009 5:05:01 PM|ralph@home|Task csttest_1_8_nativecst_harm_cenfa_0.1_hb_t373__IGNORE_THE_REST_1S3JA_4_7372_1_0 exited with zero status but no 'finished' file
2/1/2009 5:05:01 PM|ralph@home|If this happens repeatedly you may need to reset the project.
2/1/2009 5:05:01 PM|World Community Grid|Restarting task mf189_00038_13 using hpf2 version 603
2/1/2009 5:05:01 PM|ralph@home|Restarting task csttest_1_8_nativecst_harm_cenfa_0.1_hb_t373__IGNORE_THE_REST_1S3JA_4_7372_1_0 using minirosetta version 157

Waited a few minutes; then told BOINC Manager to read the config file and the local prefs file; no change.

2/1/2009 5:19:11 PM||General prefs: from World Community Grid (last modified 01-Feb-2009 16:35:52)
2/1/2009 5:19:11 PM||Computer location: home
2/1/2009 5:19:11 PM||General prefs: using separate prefs for home
2/1/2009 5:19:11 PM||Reading preferences override file
2/1/2009 5:19:11 PM||Preferences limit memory usage when active to 1438.32MB
2/1/2009 5:19:11 PM||Preferences limit memory usage when idle to 1725.99MB
2/1/2009 5:19:11 PM||Preferences limit disk usage to 27.94GB
2/1/2009 5:19:21 PM||General prefs: from World Community Grid (last modified 01-Feb-2009 16:35:52)
2/1/2009 5:19:21 PM||Computer location: home
2/1/2009 5:19:21 PM||General prefs: using separate prefs for home
2/1/2009 5:19:21 PM||Reading preferences override file
2/1/2009 5:19:21 PM||Preferences limit memory usage when active to 1438.32MB
2/1/2009 5:19:21 PM||Preferences limit memory usage when idle to 1725.99MB
2/1/2009 5:19:21 PM||Preferences limit disk usage to 27.94GB

I haven't checked if the POEM@home project or the boincsimap project have any similar options for lowering the percentage of CPU time, but will do that next.
No other projects expected to provide any workunits for the next day or so. Any other ideas about how to get such a lowering?

ID: 4643 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4645 - Posted: 2 Feb 2009, 0:28:16 UTC - in response to Message 4643.  

boincsimap recognized one of the previous CPU percentage changes from 100% to 98%, so I made no changes there.

POEM@home didn't, so I made the change there also.

Still running at 100% CPU time, though. Could the changes affect only workunits downloaded after the changes?

Looks like time to try even lower values.

Can 1.58 read the current CPU percentage value, and return it along with the results? Can it do the same with the Leave In Memory option, and perhaps a few other values affecting whether the lock file needs to be used?
ID: 4645 · Report as offensive    Reply Quote
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4646 - Posted: 2 Feb 2009, 5:46:05 UTC

Robert,

I had the lock file problem with a setting ot 99% ... but it is INTERMITTENT ... I only had it on about 40% of the tasks .... which of course failed.

As far as the setting propagating. You set it here at Ralph, update Ralph on your computer ... get the setting downloaded (you can check in the preferences pane) then do updates to the other projects on the target system and it should propagate up ...

Note that if you hit Ok on the preferenece pane you are now running locally and I am not sure if the changed Ralph settings will then propagate up ...

I only had the problem with Rosetta, primarily on my i7 computer ...

@Mtyka,

The graphics in 1.58 seems to work on XP Pro again ... time for 1.59 to break them again ... :)
ID: 4646 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 4647 - Posted: 2 Feb 2009, 6:14:03 UTC - in response to Message 4646.  
Last modified: 2 Feb 2009, 6:18:51 UTC

I did that step to download the new setting before expecting it to have any effect. However, I've only had the end of one workunit from RALPH@home and the first part of another run since the change - not enough to test very well for an intermittent problem.
ID: 4647 · Report as offensive    Reply Quote
Profile Conan
Avatar

Send message
Joined: 16 Feb 06
Posts: 364
Credit: 1,368,421
RAC: 0
Message 4649 - Posted: 2 Feb 2009, 10:38:02 UTC

Got this 1.56 result , with "Process exited with error code 193".

Other than that one the others seem to work ok on this run.
ID: 4649 · Report as offensive    Reply Quote
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4650 - Posted: 2 Feb 2009, 10:52:25 UTC - in response to Message 4647.  

I did that step to download the new setting before expecting it to have any effect. However, I've only had the end of one workunit from RALPH@home and the first part of another run since the change - not enough to test very well for an intermittent problem.

I think out of 20 tasks I ran I had 8 or 9 with that problem others with other failures.

I think it is a combination problem... with something else being involved. Not sure what it is exactly as I usually use a switch interval of 720 min so that most tasks are run end to end with no switching. Leave in memory is checked and I only turn off the systems when power goes out ...

All I can positively report is that since I went back to 100% usage and the later application I now have tasks running on that same system with no failures ...
ID: 4650 · Report as offensive    Reply Quote
ramostol

Send message
Joined: 29 Mar 07
Posts: 24
Credit: 31,121
RAC: 0
Message 4651 - Posted: 2 Feb 2009, 11:46:11 UTC - in response to Message 4601.  


Ramostol, this is relevant for you too, i think that's the same bug.
You two, could you set your settings back to restrict to specific days and see if it works now ? It did here :)

At last I managed to grab some 1.57 wus. I had time to observe that at least the first two succeeded, my first miniRosetta successes for a month. In a few hours we shall see if the rest survived the night and the network settings. Then, no news = good news.
Cheers!
ID: 4651 · Report as offensive    Reply Quote
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4652 - Posted: 2 Feb 2009, 12:34:21 UTC

Well, almost 80 tasks run on all my systems and no failures since the access failure reported below...
ID: 4652 · Report as offensive    Reply Quote
Profile Paul D. Buck

Send message
Joined: 14 Jan 09
Posts: 62
Credit: 33,293
RAC: 0
Message 4660 - Posted: 4 Feb 2009, 15:32:57 UTC

We seem to have broken the server ... work generation is stopped ...

Hard to test with no test cases ... :)
ID: 4660 · Report as offensive    Reply Quote
Previous · 1 · 2 · 3 · Next

Message boards : RALPH@home bug list : minirosetta v1.55 bug thread



©2024 University of Washington
http://www.bakerlab.org